US20230418918A1 - User information gathering and distribution system - Google Patents

Abstract

Systems and methods relating to alerting users as to user information to be exchanged during transactions. A user information system (UIS) information circuit and an associated user information database populates an account with user information received from at least one of the user and a plurality of entities. A user information request relating to a transaction is received from an entity computing system associated with an entity over a network via a network interface circuit. A security circuit sends an alert comprising an approval request containing an identification of user information requested in the user information request to a user computing device associated with the user over the network. The security circuit receives an approval of the approval request from the user computing device, and the UIS information circuit provides the approved information to the entity to complete the transaction.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of U.S. patent application Ser. No. 17/079,095, entitled “USER INFORMATION GATHERING AND DISTRIBUTION SYSTEM,” filed Oct. 23, 2020, which is a continuation of U.S. patent application Ser. No. 15/385,035, entitled “USER INFORMATION GATHERING AND DISTRIBUTION SYSTEM,” filed Dec. 20, 2016, issued as U.S. Pat. No. 10,817,593 on Oct. 27, 2020, which itself claims priority to U.S. Provisional Patent Application No. 62/272,422 entitled “USER INFORMATION GATHERING AND DISTRIBUTION SYSTEM,” filed Dec. 29, 2015, each of which are incorporated in their entireties and for all purposes.
BACKGROUND
• Individuals often have a plurality of information associated with the individual that is shared with a plurality of entities. The information may include basic information associated with the individual such as first name, last name, email address, phone number, birthday, home address and so on. The information may also include information confidential to the individual such as social security number, health information, credit information, insurance information and so on. Often, individuals store this information in a variety of places (e.g., financial institution, safe, government agency, etc.). Individuals may also be asked to provide pieces of this information to many different entities during a transaction. For example, when an individual is getting approved for a mortgage, buying a new car, or visiting the hospital, the individual may be asked to provide a variety of information. However, the individual may not know what information is needed, or the individual may not have the information needed readily available. If the individual does not know what information is needed for certain transactions, the individual may provide too much or too little information to the entity. Providing too much information to an entity may be dangerous for the individual as the information may be used fraudulently by the entity or be available to others whom may use the information fraudulently.
SUMMARY
• One embodiment of the invention relates to a method of alerting a user of user information to be sent to an entity during a transaction, the method being performed by a user information service (UIS) computing system associated with an information service. The method includes populating, by a UIS information circuit and an associated user database, an account with user information received from at least one of the user and a plurality of entities. The method further includes receiving, by the UIS information circuit over a network via a network interface circuit, a user information request relating to a transaction from an entity computing system associated with the entity. The method includes sending, by a security circuit of the UIS information circuit, an alert including an approval request to a user computing device associated with the user over the network, wherein the approval request contains an identification of user information requested in the user information request. The method further includes receiving, by the security circuit, an approval of the approval request from the user computing device. The method includes providing, by the UIS information circuit and the user information database, the approved information to the entity to complete the transaction.
• Another embodiment relates to a non-transitory computer readable media having computer-executable instructions embodied therein that, when executed by a computing system associated with a second party to an agreement causes the second party computing system to perform operations for demonstrating consensus agreement. The operations include populating, by an associated user database, an account with user information received from at least one of the user and a plurality of entities. The operations further include receiving a user information request relating to a transaction from an entity computing system associated with the entity, sending an alert including an approval request to a user computing device associated with the user over the network, wherein the approval request contains an identification of user information requested in the user information request. The operations further include receiving an approval of the approval request from the user computing device and providing, by the user information database, the approved information to the entity to complete the transaction.
• Yet another embodiment of the invention relates to a user information service (UIS) computing device. The device includes a network interface circuit configured to communicate with a user computing device associated with a user and an entity computing system. The method further includes at least one processor operatively coupled to a non-transient memory to form a UIS information circuit. The circuit is structured to populate, in a user information database, an account with user information. The circuit is further structured to receive, via a network interface circuit, a user information request from an entity computing system over a network. The circuit is structured to send, via a security circuit, an alert including an approval request indicating the user information requested in the user information request to the user computing device over the network. The circuit is further structured to receive a response to the approval request from the user computing device. The circuit is structured to provide user information corresponding to the user information request and the response to the approval request to the entity computing system.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG.1 is a diagram of a data exchanging system, according to an example embodiment.
• FIG.2 is a diagram of information and data flows of the data exchanging system ofFIG.1, according to an example embodiment.
• FIG.3 is a flow diagram of a method of populating user information for a user account, according to an example embodiment.
• FIG.4 is a flow diagram of a method of providing user information to an entity, according to an example embodiment.
• FIG.5 is a flow diagram of a method of comparing a user information request from an entity, according to an example embodiment.
• FIG.6 is a flow diagram of a method of preparing user information for a predicted transaction, according to an example embodiment.
• FIG.7 is a flow diagram of a method of determining if a user has user information ready for a potential transaction, according to an example embodiment.
DETAILED DESCRIPTION
• Referring to the figures generally, user information gathering and distribution systems and methods are described. The user information systems and methods are structured to receive a plurality of user information types (e.g., social security number, insurance information, etc.) associated with a user and to enable the user to manage and distribute the information in a secure, convenient, efficient, and time-saving manner. The user information system may be accessed with at least one user device (e.g., a mobile device, a smart watch, etc.). In some arrangements, the user information system is structured to receive an information request from an entity (e.g., bank, car dealer, etc.) based on a transaction type (e.g., mortgage approval, buying a car, etc.), compare the information request to information requests from similar entities for similar transactions, and to provide the user information to the entity. The user information functions allow the user to add, manage, and distribute the user information. The user information system also predicts and verifies the user information needed for a given transaction to protect the user from risks of giving too much or incorrect information to an entity.
• Referring now toFIG.1, a diagram of adata exchange system100 is shown according to an example embodiment. Thecomputing system100 includes auser102, a plurality ofentities108, auser information service120, and anetwork140. Thenetwork140 may include any of various types of data exchanging networks. For example, thenetwork140 may include wireless networks (e.g., 802.11X, ZigBee′, Bluetooth, Internet, etc.), wired networks (e.g., Ethernet), or any combination thereof. Thenetwork140 is structured to permit the exchange of data, values, instructions, messages, etc. between and among the user computing device104, theentity computing system110, and the user informationservice computing system122.
• Theuser102 may include individuals, business representatives, large and small business owners, other entities, and so on. Theuser102 is associated with a user computing device104. The user computing device104 may be, but is not limited to, a mobile computing device (e.g., a smartphone, tablet computer, laptop computer, person digital assistant, etc.), a desktop computing device, a wearable computing device, etc. Wearable computing devices refer to any type of computing device that auser102 wears including, but not limited to, a watch, glasses, bracelet, etc.
• The user computing device104 includes a user information circuit106. The user information circuit106 is structured to allow theuser102 to communicate with theuser information service120. For example, the user information circuit106 may be structured to provide a user interface (e.g., a graphical user interface) that permits theuser102 to provide information (e.g., user information) that is communicated to a user informationservice computing system122 associated with theuser information service120. In this regard, the user information circuit106 may be communicably coupled to a processor, non-transient memory, and network interface enabling the user computing device104 to exchange data over thenetwork140.
• In addition, the user information circuit106 communicates data to and from the user informationservice computing system122 vianetwork140. In some arrangements, theuser102 may download a user information application (e.g., a software “app”) prior to use, which may be used to set up and configure the user information circuit106. In another arrangement, the user information circuit106 is hard coded into the memory of the user computing device104. In further arrangements, the user information circuit106 is a web-based interface application accessed via the Internet on a web browser executed on the user computing device104. In such arrangements, the user information circuit106 is executed and maintained remotely (e.g., on the user information service computing system110). In this instance, theuser102 logs onto or accesses the web-based interface to access the user information circuit106. In some arrangements, the user information circuit106 is supported by a separate computing system comprising one or more servers, processors, network interface circuits, etc. that transmit the applications for use to the user computing device104. In certain embodiments, the user information circuit106 may include an application programming interface (API) and/or a software development kit (SDK) that facilitates the integration of other applications with the user information circuit106.
• Each of theentities108 provide services to a plurality of users, including theuser102. Examples of theentities108 include financial institutions, merchants, insurance companies, utility companies, social media networks, e-mail systems, health care providers, etc. Each of the plurality ofentities108 operates and/or is associated with a respectiveentity computing system110. Eachentity computing system110 includes aprocessor112,memory114, anetwork interface circuit116 and auser information database118. Thenetwork interface circuit116 facilitates the sending and receiving of data, commands, instructions, values, etc. over the network140 (e.g., to and from the user informationservice computing system120, etc.). Eachentity computing system110 is communicably coupled to the user informationservice computing system122 and/or the user computing device104 via thenetwork140.
• Theentity computing system110 also includes auser information database118 that stores user information relating to theuser102. Theentity computing system110 may maintain information about one or more of theentities108, information regarding user102 (e.g., accounts associated with theuser102 and a respective one of theentities108, etc.) and so on in theuser information database118. In this regard and as mentioned above, more than oneentity108 with an associatedentity computing system110 may be communicably coupled to the components ofFIG.1 over thenetwork140 to accommodate user information associated theuser102 at a plurality ofentities108. For example, if theentity108 is a financial institution, the user information database may store user account information including account numbers, balances, credit limits, and so on.
• In some arrangements, theuser information service120 is affiliated with a given entity108 (e.g., a financial institution). In other arrangements, theuser information service120 is not directly affiliated with a givenentity108. Theuser information service120 includes a user informationservice computing system122. The user informationservice computing system120 includes aprocessor124,memory126, anetwork interface circuit128, and a user information service (“UIS”)information circuit130. Thenetwork interface circuit128 facilitates the sending and receiving of data, commands, instructions, values, etc. over the network140 (e.g., to and from the user computing device104, to and from theentity computing system110, etc.). The user informationservice computing system122 is structured to provide storage of user information associated with theuser102 and distribution of user information associated with theuser102 to one or more of theentities108.
• TheUIS information circuit130 of the user informationservice computing system122 provides storage and distribution of user information to theuser102 via the user information circuit106. The operation of the user informationservice computing system122 and theUIS information circuit130 are described in further detail with respect toFIGS.2 through7.
• Now referring toFIG.2, a diagram of information and data flows to and from the user informationservice computing system122 ofFIG.1 is shown in greater detail, according to an example embodiment. TheUIS information circuit130 at the user informationservice computing system122 communicates data to and from the user information circuit106 and theentity computing system110 via thenetwork140, and includes auser information database132, atransaction type database134, asecurity circuit136, and aprediction circuit138. Theuser information database132 includes storage media or access thereto structured to retrievably store user information flowing into theUIS computing system122. Thetransaction type database134 retrievably stores information relating to a plurality of different transaction types, including types of user information relevant to each of the plurality of different transaction types. In some arrangements, the information in theuser information database132 is shared with thetransaction type database134. Thesecurity circuit136 is structured to maintain and apply various security protocols relating to information stored in theuser information database132, as well as information requested from theuser102. Theprediction circuit138 is structured to predict future transactions based on information flowing to the UIS computing system122 (e.g., information from the user information circuit106) and information stored at theuser information database132 and thetransaction type database134. Various example operations of the UIS information circuit are discussed in more detail below.
• The user informationservice computing system122 receives a plurality of inputs, including, but not limited to,incoming user information202,information request204,potential transaction206,user input208 from at least the user information circuit106 and theentity computing system110.
• Incoming user information202 may be any type of information relating to theuser102. For example, theincoming user information202 may be personal information (e.g., social security number, birthday, home address, name, etc.), financial information (e.g., credit score, bank account balances, etc.), health information (e.g., allergies, vaccinations, family medical history, etc.) and so on. Theincoming user information202 may be received by the user informationservice computing system122 from the user computing device104. Alternatively, theincoming user information202 may be received from theentity computing system110. For example, the userinformation computing system122 may receive health care information (incoming user information202) associated with theuser102 from a computing system associated with a health care provider.
• Information request204 may be a request from theentity computing system110 for user information associated with theuser102 sent to the user informationservice computing system122. Theinformation request204 may include a list of specific user information that is being requested. Theinformation request204 may also include theentity108 that is requesting the user information. In addition, theinformation request204 may indicate a type of transaction for which theentity computing system110 is requesting the user information.
• Potential transaction206 is a transaction, indicated by theuser102 via the user information circuit106, that theuser102 may complete in the future. For example, if theuser102 is planning on purchasing a car, but not for a few months theuser102 may send the user information service computing system122 apotential transaction206. In this case, theuser102 may want to plan ahead to gather additional user information that may be needed for thepotential transaction206. Thepotential transaction206 is received by the user informationservice computing system122 from the user information circuit106.
• User input208 refers to input received from theuser102 at the user information circuit106. Theuser input208 may include user responses toapproval request212, flaggedrequest214, alert216, and/or predictedtransaction218, discussed below. In some arrangements,user input208 also includes setting and preferences associated with a user account for theuser102 with theuser information service120.
• TheUIS information circuit130 at the user informationservice computing system122 is also structured to provide information, requests, and alerts216 to theentity computing system110 and the user information circuit106. An alert216 is a notification to be received at the user computing device104, and may specify a type of pending request, an requested response from theuser102, a notification, and so on. The user information circuit106 may receive the alert216 over thenetwork140 and use any of a variety of output devices at the user computing device104 to bring the alert216 to the attention of theuser102. The alert216 may be associated with any of the outgoing types of data from the UIS computing system122 (e.g., anapproval request212, a flaggedrequest214, a predictedtransaction218, etc.). The alert216 may be sent via email, text message, push notification, etc. Theuser102 may set up and configurealerts216 and alert preferences when setting up the user account.
• The user informationservice computing system122 may provideoutgoing user information210 to one or more of the plurality ofentities108.Outgoing user information210 may be substantially similar toincoming user information202 in thatoutgoing user information210 may include any of various types of information relating to a given user. However,outgoing user information210 is a set of user information that will be provided to theentity computing system110. For example, in one arrangement, while the user information collectively received by the user informationservice computing system122 includes all the user information types described above, theoutgoing user information210 sent to theentity computing system110 may only include name, address, and credit score.
• Thesecurity circuit136 may provide anapproval request212 and acorresponding alert216 to the user information circuit106 to notify theuser102 of information relating to aninformation request204 received from one or more of the plurality ofentities108. As another example, thesecurity circuit136 may provide the user information circuit106 with all the user information that was requested in theinformation request204, as well as information relating to the type of transaction for which the user information is being requested, and theentity108 that is requesting the user information in theapproval request212. Thesecurity circuit136 may receive, from theuser102 via the user information circuit106,user input208 indicating an approval of the user information ofapproval request212.
• A flaggedrequest214 and acorresponding alert216 may be provided to the user information circuit106 by thesecurity circuit136 to notify theuser102 of information relating to aninformation request204 received from one or more of the plurality ofentities108 when a piece of user information requested is unusual (e.g., medical information requested when getting a car loan).
• Theprediction circuit138 is structured to predict a potential future transaction theuser102 may be making based on activity by theuser102 on the user computing device104. When theprediction circuit138 identifies a potential future transaction, the prediction circuit may provide a predictedtransaction218 and acorresponding alert216 to the user information circuit106, which in turn may provide the predictedtransaction218 to theUIS information circuit130.
• TheUIS information circuit130 may providetransaction information220 to the user information circuit106 from thetransaction type database134 to inform theuser102 about a transaction that is presently occurring or is actually set to occur.
• In operation, theincoming user information202 may be transmitted to the user informationservice computing system122 via the user information circuit106 of the user computing device104. The first time theuser102 sendsincoming user information202 to the user informationservice computing system122, theUIS information circuit130 may treat theincoming user information202 as a request to create an account with theuser information service120. The user account containsincoming user information202 received from theuser102, and all of theincoming user information202 may be stored inuser information database132. Theuser information database132 is configured to store and manageincoming user information202 associated withuser102 at the user informationservice computing system122. TheUIS information circuit130 may also receiveincoming user information202 from one ormore entities108 associated with user102 (e.g., social media, health care provider, etc.). In addition to storing and managingincoming user information202, theuser information database132 maintains user account settings and preferences.
• In operation, theinformation request204 is transmitted to the userinformation computing system122 from theentity computing system110. Theinformation request204 may specify theentity108 requesting the user information, the type of transaction occurring, and the user information being requested. As used herein, the term “transaction” may refer to financial and non-financial transactions. An example of a non-financial transaction may be providingoutgoing user information210 to an entity. Accordingly, the term “transaction” may refer to any operation or interaction executed by theuser102 with an entity108 (e.g., visiting the doctor, making a flight reservation using frequent flier miles, financial transactions, buying a car, getting approved for a loan, etc.).
• TheUIS information circuit130 may compare theinformation request204 to other requests of similar transaction types using thetransaction type database134. Information relating to different types of transactions and user information commonly requested for these types of transactions is stored intransaction type database134. Thetransaction type database134 may be constantly updating theoutgoing user information210 requested for certain transactions. In this regard, thetransaction type database134 may be dynamic and adaptive to learn what user information is commonly requested for a transaction. Thetransaction type database134 may be updated manually by personnel (e.g., employees, etc.) associated with theuser information service120, or may use prior transactions of all users with accounts at theuser information service120, includinguser102.
• Thesecurity circuit136 is structured to determine if information requested by the entity is consistent with information normally requested by a similar entity for a similar transaction type. Thesecurity circuit136 may also be structured to flag inconsistent information and send the user102 a flaggedrequest214 and acorresponding alert216. When theUIS information circuit130 compares theinformation request204 to similar information requests of the same or similar type that are maintained in thetransaction type database134, user information that is requested ininformation request204 that is not consistent with information requests of the same or similar type may be flagged by thesecurity circuit136. Thesecurity circuit136 may have different levels or criteria for flagging requested user information. The flagging levels may be preset or determined by theuser102 when the user account is created. The flagging levels may also be based on more than one type of criteria (e.g., frequency of request, level of security of information, etc.). Thesecurity circuit136 is also structured to determine the level of security for each piece of information theuser102 provides, and maintain security protocol for sharing information with a certain security level. For example, thesecurity circuit136 may require theuser102 to provide a password before theUIS information circuit130 can share the social security number of theuser102 with one of theentities108.
• TheUIS information circuit130 may provide theuser102 with an alert216 via the user information circuit106 when certain user information is requested. TheUIS information circuit130 may provide theuser102 withalert216 via the user information circuit106 when user information is requested that theuser102 does not have linked or stored in theuser information database132.Alert216 may also be provided to theuser102 via the user information circuit106 to remind theuser102 to provide the user informationservice computing system122 with user information that will be needed for a future transaction theuser102 has indicated (e.g., potential transaction206).
• TheUIS information circuit130 may receive apotential transaction206 generated and transmitted from the user information circuit106. Theuser102 may be planning on completing a transaction (e.g., getting a loan, qualifying for a mortgage, buying a car, etc.) and use the user information circuit106 to transmit a correspondingpotential transaction206 to the user informationservice computing system122. TheUIS information circuit130 may search thetransaction type database134 to determine the user information that may be needed to complete thepotential transaction206. In view of the information returned from thetransaction type database134, theuser102 may have time to gather additional user information that is needed and check to see if the user information is accurate before completing a transaction with any one ormore entity108. Alternatively, theUIS information circuit130 may receive thepotential transaction206 fromentity computing system110. Theuser102 may visit one or more of theentities108 looking for information regarding a transaction. In this regard, theentity computing system110 may send apotential transaction206 to the user informationservice computing system122 indicating thatuser102 may complete a transaction withentity108. Theentity computing system110 may also indicate what user information would be needed to complete the transaction. Again, theuser102 would have time to gather additional user information that may be needed and check to see if the user information is accurate before completing a transaction withentity108.
• TheUIS information circuit130 may cooperate with theprediction circuit138 to provide predictedtransactions218 to theuser102. A predictedtransaction218 is information relating to an anticipated transaction based on the past behavior of theuser102. The user informationservice computing system122 may monitor other applications on the user computing device104 and/or monitor website activity on the user computing device104 to predict apotential transaction218 of theuser102. Theprediction circuit138 may be set with different transactions that could be completed and information that may be indicative of the transaction. For example, if theuser102 is looking up homes or properties, theprediction circuit138 may predict theuser102 will be purchasing a home. TheUIS information circuit130 may notify (e.g., via alert216) theuser102 of the predictedtransaction218 via the user information circuit106. Theuser102 may transmituser input208 to the user informationservice computing system122 indicating if the predictedtransaction218 is accurate. TheUIS information circuit130 may use thetransaction type database134 to provide theuser102 withoutgoing user information210 corresponding to user information that would likely be needed for the predictedtransaction218.
• When theuser102 is ready to complete a transaction (e.g., send outgoing user information210) with one or more of theentities108, theuser102 may provideuser input208 to the user informationservice computing system122 via the user information circuit106. Where theuser input208 is an approval, the approval may include each piece of user information that is approved byuser102 to be sent to theentity computing system110. Thesecurity circuit136 may require theuser102 to provide authorization with theuser input208 indicating an approval. In some embodiments, thesecurity circuit136 may also require the entity108 (e.g., an employee associated with entity108) to provide authorization or authentication beforeoutgoing user information210 is provided. For example, theentity108 may have to provide thesecurity circuit136 with a password (e.g., phrase, number, alphanumeric sequence, etc.), a biometric (e.g., fingerprint, retina, etc.), etc. Alternatively, theuser input208 may include a selection of one ormore entity108 when theuser102 has already approved all theoutgoing user information210 to be sent to one or more entity108 (e.g.,potential transaction206, predictedtransaction218, etc.). The user informationservice computing system122 transmits the approvedoutgoing user information210 toentity computing system110.
• Now referring toFIG.3, a flow diagram of amethod300 of populating user information for a user account with the user informationservice computing system122 is shown, according to an example embodiment. Themethod300 registers theuser102 with theuser information service120 and gathers user information associated with theuser102.
• A user account is created at302. The user account created may be initiated byuser102 transmittingincoming user information202 to the user informationservice computing system122 via the user information circuit106. Theuser102 may provide additional information that is optional for theuser102 to include for registration. For example, theuser102 may have the option to add a phone number, set preferences for the user account, and change the password associated with the user account. The user account may also include system preferences theuser102 defines. The system preferences may include security preferences, usage preferences, alert preferences, and so on. The security preference may define the requirements needed by thesecurity circuit136 before accessing the user informationservice computing system122 via the user information circuit106. For example, a security preference may require theuser102 to provide a password (e.g., word, phrase, alphanumeric value, etc.), a biometric scan (e.g., a fingerprint scan, a retina scan, a voice sample, etc.), a semi-random number (e.g., as generated by a changing security token device), or a combination thereof to thesecurity circuit136 before theuser102 may access the user informationservice computing system122. Thesecurity circuit136 may also allow theuser102 to define user information (e.g., social security number, etc.) that require a second passcode to authorize transmission toentity computing system110. Alert preferences may include when alert216 is sent to the user information circuit106 (e.g.,information request204 received, social security number requested, etc.), a form of alert216 (e.g., text message, email, notification, etc.) and information included in alert216 (e.g., user information requested, transaction type,entity108 requesting the information, etc.).
• Incoming user information202 is added to the user account by theUIS information circuit130 at304. Theuser102 may manually enter the user information via input devices associated with the user computing device104. In some arrangements, the user information circuit106 provides a graphical user interface with labeled spaces for theuser102 to enter specified information. For example, theuser102 may fill in the home address ofuser102 in a box labeled “Home Address.” Theuser102 may also include information about one or more of theentities108 that may provide additionalincoming user information202. For example, theuser102 may provide information regarding a health care provider or financial institution associated with theuser102 to the user informationservice computing system122 via the user information circuit. Alternatively, theuser102 may link the user information circuit106 to other applications used by theuser102 that include user information (e.g., mobile banking application, social media application, etc.).
• The user informationservice computing system122 may request user information from theentity computing system110, at306. For example, theUIS information circuit130 may request healthcare information associated withuser102 from the health care provider indicated by theuser102 at304. Additionally, the user informationservice computing system122 may request user information from theuser102 via the user information circuit106. If theUIS information circuit130 has a set of user information (e.g., name, email, phone number, address, etc.) that is required for all users, includinguser102, theUIS information circuit130 may send alert216 to theuser102 via the user information circuit106 indicating that user information is missing and/or incomplete.
• TheUIS information circuit130 of the user informationservice computing system122 receivesincoming user information202 at308. Theincoming user information202 received at308 may be the user information requested at306, or additional information provided to theUIS information circuit130 via the user information circuit106 or theentity computing system110. If the information requested is information that remains constant (e.g., social security number, birthday, etc.), or relatively constant (e.g., home address, last name, insurance information, healthcare information, etc.), theuser information database132 may receive a copy of the user information. Alternatively, if the user information changes frequently (e.g., balance of financial accounts, credit score, etc.) theUIS information circuit130 may receive access to the user information instead of receiving copy of the user information. Theincoming user information202 received at308 may be compared to the user information currently associated with the user account and/or otherincoming user information202 being received by theuser information database132. TheUIS information circuit130 may send the alert216 to theuser102 via the user information circuit106 when a discrepancy is determined between pieces of user information. For example, if the home address associated with theuser102 received from oneentity108 is listed as “Pin Oak” and the home addressed associated with theuser102 at adifferent entity108 is listed as “Pine Oak,” theuser102 may senduser input208 to the user informationservice computing system122 indicating the information that is correct and should be stored in theuser information database132. In some embodiments, the user informationservice computing system122 may ask theuser102 viaalert216 to the user information circuit106 to verify the user information received from the variousentity computing systems110 even if no discrepancies are found for the piece of user information.
• TheUIS information circuit130 of the user informationservice computing system122 stores, manages, and distributes the user information at310. The user information that is constant or relatively constant may be stored by the userinformation computing system122. However, the user information may still be modified byuser102 via the user information circuit106, but may require manual updating of the user information. User information that is relatively fluid, or changes frequently, may be managed by theuser information database132. This information may be updated frequently asentities108 associated with the user information (e.g., a financial institution associated with a financial account of user102) update the user information. Additionally, some user information may be managed on a set cycle or by user input. For example, theuser102 may indicate that theuser102 visits the eye doctor once a year, generally in March. The user informationservice computing system122 may only request updated user information relating to the eye doctor (e.g., vision prescription, etc.) at the end of March, or may periodically check for user information updates during the month of March. If theuser102 instead visits the eye doctor in February, theuser102 may indicate via the user information circuit106, that the user information associated with the eye doctor has been updated. The user informationservice computing system122 may request user information from a computing system (e.g., entity computing system110) associated with the eye doctor (e.g., entity108) based on theuser input208 indication received from user information circuit106. User information may then be selectively distributed toentity computing system110 by the user informationservice computing system122. Additional methods for managing and distributing user information are explained in further detail below with respect toFIGS.4-7.
• Referring now toFIG.4, a flow diagram of amethod400 of providing user information to an entity using the user informationservice computing system122 is shown, according to an example embodiment. Themethod400 provides user information tocomputing system122 based on a transaction occurring between theuser102 and one or more of theentities108. Themethod400 may be initiated in two ways, by theuser102, or by one or more of theentities108.
• The user informationservice computing system122 receives aninformation request204 from theentity computing system110 at402. Theinformation request204 may include a list of all the user information (e.g., name, address, credit score, financial institution, etc.) being requested for theuser102 by theentity108 for a transaction. Theinformation request204 may also include the type of transaction that is taking place (e.g., mortgage approval, etc.) and/or information relating to theentity108. Theentity108 may have to register (e.g., create an entity account, etc.) with the user informationservice computing system122 before theinformation request204 can be received from theentity computing system110. Alternatively, theentity108 may not have to register with the user information service before the user informationservice computing system122 can receive aninformation request204 from theentity computing system110.
• Theentity computing system110 may have to provide at least basic user information (e.g., first and last name, phone number, etc.) to the user informationservice computing system122 to identify the account associated with theuser102 at theuser information service120. In some embodiments, thesecurity circuit136 may require theentity computing system110 to provide a form of authentication to ensure theentity computing system110 is not trying to obtain user information for fraudulent purposes. For example, theentity108 may have to register an entity account and provide a password (e.g., phrase, number, alphanumeric sequence, etc.), a biometric (e.g., fingerprint, retina, etc.), etc. to thesecurity circuit136 before the user informationservice computing system122 responds to theinformation request204.
• Theentity108 may have an entity number to associate theentity108 with the user informationservice computing system122. The entity number may be associated with auser information service120 account held by the user informationservice computing system122 for theentity108. The entity account may contain information relating to transactions common for theentity108 stored in thetransaction type database134. For example, a car dealership may have car loan and car purchase transactions associated with the entity account stored in thetransaction type database134. Thetransaction type database134 may also contain information commonly requested for the transactions associated with theentity108. The user informationservice computing system122 can use this information to determine if theentity computing system108 is requesting information consistent withinformation requests204 made in the past. For example, if the car dealership has a defined set of user information that is requested from theuser102 when theuser102 is getting a car loan, but aninformation request204 contains more information than normally requested, thesecurity circuit136 may suspect fraudulent activity relating to theentity computing system110. Inconsistent user information requests will be described in greater detail with respect toFIG.5.
• The user informationservice computing system122 may send anapproval request212 and acorresponding alert216 to theuser102 via thesecurity circuit136 of the user information circuit106 at404. Theapproval request212 may present the user information in a way that indicates the type of user information without revealing the user information. For example, theapproval request212 may indicate that the home address ofuser102 was requested, without actually providing the home address of theuser102. Alternatively, theuser102 may be notified by the user informationservice computing system122 via the user information circuit106 of theapproval request212 and have to log in to the userinformation computing system122 to see theapproval request212. For example, theuser102 may receive a notification saying “Someone has requested user information, please login to approve this request,” etc. The approval request may also include information identifying theentity108 that sent theinformation request204. By identifying theentity108, theuser102 can provide the correctoutgoing user information210 to theentity108. Theapproval request212 may also include thetransaction information220. For example, theapproval request212 sent be the user informationservice computing system122 may indicate that the user information is being requested to complete a car loan. By providing thetransaction information202 to theuser102 via the user information circuit106, theuser102 can verify theentity108 requested the user information for the correct transaction. Theapproval request212 may also indicate to theuser102 if any user information was requested that is not associated with theuser information database132.
• The user informationservice computing system122 receives a response to the approval request from theuser102 viauser input208 from the user information circuit106 at406. The response to the approval request indicates which user information has been approved by theuser102 to share with theentity108 that sentinformation request204. Theuser102 may approve all, part or none of the user information in theuser input208. If theuser102 does not approve any of the user information sought in theuser information request204, themethod400 may terminate.
• If theuser102 approves part or all of the user information,outgoing user information210 is provided to theentity computing system110 of theentity108 that sent theinformation request204 at414. If theuser102 has multiple pieces of the same type of user information (e.g., multiple accounts, two home addresses, etc.) the response may indicate which user information is to be shared (e.g., checking account, one of the home addresses, etc.) with theentity computing system110 for a given type of user information. Alternatively, theuser102 may choose to approve all pieces of the same type of user information with theuser input208. Theuser102 may approve the user information by checking a box next to the user information using a graphical user interface associated with the user information circuit106. Theuser102 may have to provide authorization to thesecurity circuit136 in order to approve a piece of user information with high security. For example, if theuser102 is approving the social security number associated with theuser102, the user may have to provide authorization to thesecurity circuit136. For example, theuser102 may have to provide a password (e.g., phrase, number, alphanumeric sequence, etc.), a biometric (e.g., fingerprint, retina, etc.), etc. to the security circuit before theoutgoing user information210 is authorized to be sent to theentity computing system110. In some embodiments, all user information requires authorization, while higher level security information requires secondary authorization from thesecurity circuit136. Other methods of selecting and approving information for approval are intended to fall within the scope of the present disclosure.
• Instead of receiving aninformation request204 fromentity108, the user informationservice computing system122 may receive apotential transaction206 fromuser102 via the user information circuit106 at408. Alternatively, the user informationservice computing system122 may receive the potential transaction from theentity computing system110. Thepotential transaction206 received from theentity computing system110 by the user informationservice computing system122 may contain information consistent with theinformation request204 received at402. However, in this case, theentity computing system110 is not requesting any user information, theentity computing system110 is simply providing the user informationservice computing system122, and theuser102, with an indication of what user information would be requested.
• The user informationservice computing system122 receives selected user information from theuser102 viauser input208 from the user information circuit106 at410. If thepotential transaction206 was received by the user informationservice computing system122 from the user information circuit106, thetransaction type database134 may provide suggestions to theuser102 of what user information may be involved in thepotential transaction206. Theuser102 can select relevant user information from the user information stored and managed by theuser information database132, or add additional user information relevant to the potential transaction. Alternatively, if the potential transaction was sent by theentity computing system110, theuser102 may approve the user information, much like was done at406. The selected user information may be stored in theuser information database132 so the user information is accessible when theuser102 is ready to complete a transaction.
• When theuser102 is ready to complete thepotential transaction206, the user informationservice computing system122 receives an entity selection at412 fromuser input208 from the user information circuit106. Since thepotential transaction206 may have been initiated by theuser102 at408, theentity108 involved in the actual transaction may not be theentity108 associated with thepotential transaction206. If the potential transaction was initiated by theentity computing system110, theentity108 may be saved in theuser information database132 with the user information for thepotential transaction206. Theuser102 may choose if theentity108 that initiated the transaction should be saved with thepotential transaction206 by provinguser input208 via the user information circuit106. If theentity108 was saved with thepotential transaction206, theuser102 can selectentity108 using the user information circuit106. If no entity was saved with the potential transaction, theuser102 may select an entity to complete the potential transaction by providinguser input208 via the user information circuit106. Theuser102 may select an entity by providing the user informationservice computing system122 with information about the entity (e.g., name, address, phone number, etc.) via the user information circuit106. Alternatively, theuser102 may select an entity by using a drop down list ofentities108 associated with the user informationservice computing system122 on a graphical user interface associated with the user information circuit106. In another embodiment, theuser102 may enter an entity identification number associated with theentity108 and the user informationservice computing system122 via the graphical user interface associated with the user information circuit106. Theuser102 may receive the entity identification number from theentity108, or from a list provided to theuser102 via the user information circuit106 from the user informationservice computing system122. Alternatively, theuser102 may use the user computing device104 to scan a barcode, QR code, or other symbol at theentity108 to indicate theentity108 selected to the user informationservice computing system122. A more detailed method with regard to potential transactions can be seen with reference toFIG.6.
• The user informationservice computing system122 provides the approvedoutgoing user information210 to theentity computing system110 of the selectedentity108 at414. Theoutgoing user information210 may be provided to theentity computing system110 in a number of ways. The user informationservice computing system122 may provide theoutgoing user information210 in an email to the entity computing system110 (e.g., in a PDF document, etc.). Alternatively, the user informationservice computing system122 may populate a form associated with theentity computing system110 to provideoutgoing user information210. In another embodiment, the user informationservice computing system122 populates a database associated with the entity computing system110 (e.g., user information database118) to provideoutgoing user information210. In some embodiments, theentity108 may determine how user information is sent based on setting associated with an entity account with theuser information service120. In other embodiments, the user informationservice computing system122 determines how theoutgoing user information210 is sent toentity computing system110. In another embodiment, theoutgoing user information210 is sent to theentity computing system110 in different forms based on the level of security of theoutgoing user information210 determined by thesecurity circuit136.
• The user informationservice computing system122 updates theoutgoing user information210 for the transaction type at416. The user informationservice computing system122 may update thetransaction type database134. Thetransaction type database134 may maintain alloutgoing user information210 requested for a plurality of transaction types. Thetransaction type database134 may keep a single set of user information requested210 for a given transaction type. Alternatively, thetransaction type database134 keeps all user information requested for a given transaction type for all users associated with the user informationservice computing system122. In this regard, thetransaction type database134 may be adaptive and learn what user information is commonly requested for a given transaction type. This information may be used when determining if theinformation request204 includes information not commonly requested, which will be described in greater detail with regard toFIG.5.
• Referring now toFIG.5, a flow diagram of amethod500 of comparing a user information request from an entity is shown, according to an example embodiment. Themethod500 is performed by the user informationservice computing system122. Themethod500 receives aninformation request204 fromentity computing system110 at502, which may be substantially similar to process402 ofmethod400, compares theinformation request204 to user information requests for the same transaction type and provides theentity computing system110 with theoutgoing user information210.
• The user informationservice computing system122 compares theinformation request204 to user information requests of similar transaction types at504. The information stored in thetransaction type database134 may also include the geographical location of theinformation request204, in case different geographical locations (e.g., different states, etc.) have different protocols for user information requested for certain transactions. Additionally, thetransaction type database134 may determine trends in the user information requested based on the dates of the information requests204. The user informationservice computing system122 may compare theinformation request204 received at502 to individual user information requests stored in thetransaction type database134. Alternatively, the user informationservice computing system122 may compare theinformation request204 received at502 to aninformation request204 that is representative of all of the information requests204 stored in thetransaction type database134.
• The user informationservice computing system122 determines if theinformation request204 received at502 is similar to other user information requests for similar transaction types at506. The comparison may take into account the frequency of the user information requested. For example, if some type user information is always requested for the transaction type, and some type information is usually requested, these may both indicate a similar request and not cause thesecurity circuit136 to flag theinformation request204. However, if a particular type of user information is rarely or never requested for the transaction type, but appears in theinformation request204 received at502, theinformation request204 may not be considered similar. If the user information requested is similar to the user information frequently requested for the transaction type,approval request212 and acorresponding alert216 is sent to the user information circuit106 at508.Process508 may be substantially similar to process404 ofmethod400. If there are user information types that are not similar to the user information types frequently requested for the transaction type, processes510-512 occurs.
• The user informationservice computing system122 flags non-similar user information types in theinformation request204 at510. The user informationservice computing system122 may use thesecurity circuit136 to determine how to flag the user information that was determined inconsistent with frequently requested user information when compared with other user information requests for similar entity types using thetransaction type database134. Thesecurity circuit136 may have different levels of comparison that would cause user information to be flagged. For example, if a piece of information is sometimes requested, a first flag may be applied (e.g., a yellow flag, etc.). If a piece of information is rarely requested, a second flag may be applied (e.g., an orange flag, etc.). If a piece of information is never, or should never, be requested a third flag may be applied (e.g., a red flag, etc.). Alternatively, the information may be flagged based on a level of security associated with the user information. For example, the name ofuser102 may have a low security level and therefore have one flag associated with the name, while the social security number of theuser102 may have a high security level and therefore have a different flag associated with the social security number. In that regard, the user information requested that is inconsistent with the user information commonly requested may be flagged with a first, second, third, etc. flag based on the level of security of the user information. In some embodiments, a piece of user information may receive multiple sets of flags based on different criteria (e.g., frequency of request and level of security, etc.).
• The user informationservice computing system122 sends a flaggedrequest214 and acorresponding alert216 to theuser102 via the user information circuit106 at512. The flaggedrequest214 indicates any information that was flagged by thesecurity circuit136 at510. The flaggedrequest214 may also include information consistent with theapproval request212 ofprocess404 ofmethod400, such astransaction information220 and information indicating theentity108 that sent theinformation request204, in addition to the flagged user information.
• The user informationservice computing system122 receives the user response to the request at514 viauser input208 from the user information circuit106 regardless of whether or not theinformation request204 received at502 was similar to information requests of similar transaction types. The user informationservice computing system122 sends the approvedoutgoing user information210 to theentity computing system110 at516. Process514-516 may be substantially similar toprocesses406 and414 ofmethod400, respectively.
• Referring now toFIG.6, a flow diagram of amethod600 of preparing user information for a predictedtransaction218 is shown according to an example embodiment. Themethod600 is performed by user informationservice computing system122. Themethod600 predicts a transaction based on activity of theuser102 and provides recommendation to theuser102 based on the predictedtransaction218.
• The user informationservice computing system122 predicts a transaction of theuser102 at602. The user informationservice computing system122 may monitor other software applications on the user computing device104 and/or monitor website activity on the user computing device104 to predict a potential transaction of theuser102. Theprediction circuit138 may be set with different transactions that could be completed and information that may be indicative of future transactions based on activity on the user computing device104. For example, if theuser102 is looking up homes or properties, theprediction circuit138 may predict theuser102 will be purchasing a home. Theprediction circuit138 of the user informationservice computing system122 may be set to only predict a transaction after a given set of activity is monitored. For example, theuser102 may have to look at home and property listings multiple times in a given period of time before theprediction circuit138 predicts the transaction to minimize the number of predictedtransactions218 generated.
• The user informationservice computing system122 sends the predicted transaction and acorresponding alert216 to theuser102 via the user information circuit106 at604. The user informationservice computing system122 may send the predicted transaction to the user information circuit106 as analert216. The alert216 may include the predictedtransaction218 as well as information indicating how the user informationservice computing system122 predicted the transaction. For example, the alert may say “We noticed you have been viewing houses for sale frequently, are you planning on purchasing a home?” Theuser102 may respond to the alert viauser input208 to the user information circuit106.
• The user informationservice computing system122 determines if theuser102 confirmed the predictedtransaction218 or not at606. If theuser102 indicates that the predictedtransaction218 is not a transaction theuser102 is planning on completing, the user informationservice computing system122 may delete the predictedtransaction218 at608. Theprediction circuit138 may also make note of the fact that theuser102 is not planning on making the predictedtransaction218 so as to minimize the chance of sending theuser102 another alert216 relating to a predictedtransaction218 that is the same as a previously predicted transaction. If theuser102 confirms viauser input108 to the user information circuit106 that the predictedtransaction218 is a transaction theuser102 plans on completing in the future, processes610-614 may occur.
• The user informationservice computing system122 analyzes the user information at610. Analyzing the user information may include determining the user information that is likely to be needed for a given transaction type by thetransaction type database134. Thetransaction type database134 may determine different levels of user information. For example, thetransaction type database134 may determine user information that will most likely be needed for the identified transaction type. Thetransaction type database134 may also determine user information that may be needed, depending on theentity108 that theuser102 will be using to complete the transaction. Thetransaction type database134 may use methods similar to those used when comparing the user information request to similar user information requests as described with respect toFIG.5, specifically process504 of themethod500. Analyzing the user information may also include comparing the user information needed for the transaction with the user information stored at theuser information database132. The user informationservice computing system122 may compare the user information determined at610 to theuser information database132 to determine if theuser information database132 has all the user information needed for the predictedtransaction218. Analyzing the user information may also include analyzing the content of the user information (e.g., financial information, etc.). Analyzing the content of the user information may provide the user informationservice computing system122 with information regarding the likelihood of a successful transaction. For example, if the predictedtransaction218 is buying a car, but theuser102 does not have enough money saved for a down payment, analyzing the user information may indicate that theuser102 should be saving more money.
• The user informationservice computing system122 sends a predicted transaction recommendation and acorresponding alert216 to theuser102 via the user information circuit106 at612. The predicted transaction recommendation is a recommendation to theuser102 based on the analysis of the user information at610. The predicted transaction recommendation may include information relating to user information that is needed for the predicted transaction that theuser102 currently does not have associated with the user informationservice computing system122. Alternatively, or in addition, the predicted transaction recommendation may provide theuser102 with information regarding improvements that could be made to the user information to increase the likelihood of a successful transaction. The user informationservice computing system122 may provide theuser102 with the alert216 via the user information circuit106 indicating the predicted transaction recommendation.Alert216 may also be provided to theuser102 via the user information circuit106 by theuser information database132 to remind theuser102 to provide the user informationservice computing system122 with user information that will be needed for the potential transaction if theuser102 has not provided the user information needed in a set amount of time. The predicted transaction recommendation may also include recommendations for changes in the activity of theuser102 in order to have a successful transaction when theuser102 is ready to complete the predictedtransaction218. For example, if the predicted transaction is buying a car, the predicted transaction recommendation may include financial recommendations to increase the likelihood that theuser102 will be able to make car payments, information on the credit score of theuser102 and how to improve the credit score to get better car loans, etc.
• The user informationservice computing system122 sets the predicted transaction as a potential transaction at614. Since theuser102 has confirmed the predicted transaction is a transaction theuser102 is thinking about completing, the user informationservice computing system122, it is no longer a predicted transaction.
• Referring now toFIG.7, a flow diagram of amethod700 of determining if theuser102 has the user information ready for apotential transaction206 is shown, according to an example embodiment. Themethod700 is performed by the user informationservice computing system122. Themethod700 receives apotential transaction206, determines if theuser102 has the user information that will likely be need for thepotential transaction206, and provides theentity computing system110 with the approvedoutgoing user information210. Alternatively, thepotential transaction206 is received as a product ofmethod600.Process702 may be substantially similar to process408 ofmethod400.
• The user informationservice computing system122 determines the user information needed for the transaction at704, much likeprocess610 ofmethod600 when thetransaction type database134 analyzes the transaction type to determine the type of user information that will likely be needed for thepotential transaction206. However, unlikeprocess610 ofmethod600, the content of the user information is not analyzed to provide recommendations on changes in behavior.
• The user informationservice computing system122 determines if theuser102 has the user information determined at704 for thepotential transaction206 received at702 at706. Thetransaction type database134 may compare the user information determined at704 to information in theuser information database132 to determine if theuser information database132 has the user information that will likely be needed for thepotential transaction206. If the user information that will likely be needed is in theuser information database132, themethod700 may proceed directly toprocess712. If user information is needed and is not in theuser information database132, processes708-710 occur.
• The user informationservice computing system122 alerts theuser102 of the missing user information at708. The user informationservice computing system122 may provide theuser102 with the alert216 much likeprocess612. The alert216 is received by theuser102 via the user information circuit106 and indicates user information that was determined to be missing at706.
• The user informationservice computing system122 receivesincoming user information202 at710. Theincoming user information202 is received from theuser102 via the user information circuit106 in response to the alert216 notifying theuser102 of user information that is missing.Process710 may be substantially similar toprocess304 and308 ofmethod300.
• The user informationservice computing system122 receives theuser102 entity selection at712. Theuser102 entity selection is sent from the user information circuit106 and indicates whichentity108 theuser102 has selected to complete thepotential transaction206.Process712 may be substantially similar to process412 ofmethod400.
• The user informationservice computing system122 provides the approvedoutgoing user information210 to theentity computing system110 at714. Theentity computing system110 that receives the approvedoutgoing user information210 is theentity computing system110 associated with the entity selected at712.Process714 may be substantially similar to process414 ofmethod400.
• By using the user information service to store and manage user information, individuals gain ease of access to user information. In addition, with all the user information stored in a single location, information is protected, accessible and easy to distribute. Oftentimes, when individuals are asked for user information, the individual must get the information from a variety of places. The individual may have some information stored at home in a safe, while other information is stored electronically. The individual may also have to reach out to other entities to get the information needed. This can be cumbersome for the individual, and cause delays in transactions the user would like to complete. In addition, once the individual obtains all the information, it has to be shared with the entity the individual is completing the transaction with. This process can be tedious and the individual may makes mistakes when providing large amount of information. By using the user information service, individuals can easily provide all the needed information to an entity to quickly, and accurately, complete a transaction.
• The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.
• It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”
• As used herein, the term “circuit” may include hardware structured to execute the functions described herein. In some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, etc.), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on).
• The “circuit” may also include one or more processors communicatively coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. In some embodiments, the one or more processors may be embodied in various ways. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory). Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be implemented as one or more general-purpose processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor, etc.), microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given circuit or components thereof may be disposed locally (e.g., as part of a local server, a local computing system, etc.) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, a “circuit” as described herein may include components that are distributed across one or more locations.
• An exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. Each memory device may include non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, 3D NOR, etc.), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. Each respective memory device may be operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, script components, etc.), in accordance with the example embodiments described herein.
• It should also be noted that the term “input devices,” as described herein, may include any type of input device including, but not limited to, a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. Comparatively, the term “output device,” as described herein, may include any type of output device including, but not limited to, a computer monitor, printer, facsimile machine, or other output devices performing a similar function.
• Any foregoing references to currency or funds are intended to include fiat currencies, non-fiat currencies (e.g., precious metals), and math-based currencies (often referred to as cryptocurrencies). Examples of math-based currencies include Bitcoin, Litecoin, Dogecoin, and the like.
• It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.
• The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.

Claims (20)

What is claimed is:

1. A method, comprising:

determining, by a User Information Service (UIS) system, that a user of a user computing device is predicted to engage in a potential transaction based on monitoring software applications executed on the user computing device and website activities on the user computing device;

determining, by the UIS system based on a transaction type of the potential transaction and an entity of the potential transaction, first user information corresponding to the potential transaction by comparing the potential transaction to a plurality of prior transactions of the same transaction type;

determining, by the UIS system, second user information of the user stored in a user information database;

determining, by the UIS system, whether the second user information is sufficient for the potential transaction by comparing the first user information and the second user information;

in response to determining that the second user information is not sufficient for the potential transaction, sending, by the UIS system to the user computing device, an alert indicating third user information different from the second user information;

receiving, by the UIS system from the user computing device, the third user information; and

providing, by the UIS system to an entity computing system of the entity, the second user information and the third user information.

2. The method ofclaim 1, further comprising:

determining the type of transactions based on monitoring the software applications and the web site activities; and

determining that the software applications and the website activities comprise multiple instances of the type of transactions over a period of time.

3. The method ofclaim 1, further comprising:

sending, by the UIS system to the user computing device, an alert indicative of the potential transaction; and

determining, by the UIS system from the user computing device, whether the user computing device confirms the potential transaction.

4. The method ofclaim 3, further comprising in response to determining that the user computing device rejects the potential transaction, deleting, by the UIS system, the potential transaction.

5. The method ofclaim 1, further comprising populating, by the UIS system in the user information database, an account of the user with the second user information received from at least one of the user computing system and a plurality of entity computing systems.

6. The method ofclaim 1, further comprising analyzing, by the UIS system, a likelihood that the potential transaction is successful by comparing a first value corresponding to the transaction type to a second value comprised in the second user information.

7. The method ofclaim 1, wherein the user information database is adaptive, constantly updates user information requested for certain types of transactions, and learns what user information requests to compare based on a given transaction type of prior user information requests

8. At least one non-transitory computer readable medium having computer-executable instructions embodied therein that, when executed by at least one processor, causes the at least one processor to:

determine that a user of a user computing device is predicted to engage in a potential transaction based on monitoring software applications executed on the user computing device and website activities on the user computing device;

determine based on a transaction type of the potential transaction and an entity of the potential transaction, first user information corresponding to the potential transaction by comparing the potential transaction to a plurality of prior transactions of the same transaction type;

determine second user information of the user stored in a user information database;

determine whether the second user information is sufficient for the potential transaction by comparing the first user information and the second user information;

in response to determining that the second user information is not sufficient for the potential transaction, send, to the user computing device, an alert indicating third user information different from the second user information;

receive from the user computing device, the third user information; and

provide, to an entity computing system of the entity, the second user information and the third user information.

9. The non-transitory computer readable medium ofclaim 8, wherein the at least one processor is further caused to:

determine the type of transactions based on monitoring the software applications and the website activities; and

determine that the software applications and the website activities comprise multiple instances of the type of transactions over a period of time.

10. The non-transitory computer readable medium ofclaim 8, wherein the at least one processor is further caused to:

send, to the user computing device, an alert indicative of the potential transaction; and

determine, from the user computing device, whether the user computing device confirms the potential transaction.

11. The non-transitory computer readable medium ofclaim 10, wherein the at least one processor is further caused to: in response to determining that the user computing device rejects the potential transaction, deleting, by the UIS system, the potential transaction.

12. The non-transitory computer readable medium ofclaim 8, wherein the at least one processor is further caused to populate in the user information database an account of the user with the second user information received from at least one of the user computing system and a plurality of entity computing systems.

13. The non-transitory computer readable medium ofclaim 8, wherein the at least one processor is further caused to analyze a likelihood that the potential transaction is successful by comparing a first value corresponding to the transaction type to a second value comprised in the second user information.

14. The non-transitory computer readable medium ofclaim 8, wherein the user information database is adaptive, constantly updates user information requested for certain types of transactions, and learns what user information requests to compare based on a given transaction type of prior user information requests

15. A system, comprising at least one processor configured to:

determine that a user of a user computing device is predicted to engage in a potential transaction based on monitoring software applications executed on the user computing device and website activities on the user computing device;

determine based on a transaction type of the potential transaction and an entity of the potential transaction, first user information corresponding to the potential transaction by comparing the potential transaction to a plurality of prior transactions of the same transaction type;

determine second user information of the user stored in a user information database;

determine whether the second user information is sufficient for the potential transaction by comparing the first user information and the second user information;

in response to determining that the second user information is not sufficient for the potential transaction, send, to the user computing device, an alert indicating third user information different from the second user information;

receive from the user computing device, the third user information; and

provide, to an entity computing system of the entity, the second user information and the third user information.

16. The system ofclaim 15, wherein the at least one processor is further configured to:

determine the type of transactions based on monitoring the software applications and the website activities; and

determine that the software applications and the website activities comprise multiple instances of the type of transactions over a period of time.

17. The system ofclaim 15, wherein the at least one processor is further configured to:

send, to the user computing device, an alert indicative of the potential transaction; and

determine, from the user computing device, whether the user computing device confirms the potential transaction.

18. The system ofclaim 10, wherein the at least one processor is further configured to: in response to determining that the user computing device rejects the potential transaction, deleting, by the UIS system, the potential transaction.

19. The system ofclaim 8, wherein the at least one processor is further configured to populate in the user information database an account of the user with the second user information received from at least one of the user computing system and a plurality of entity computing systems.

20. The system ofclaim 8, wherein the at least one processor is further configured to analyze a likelihood that the potential transaction is successful by comparing a first value corresponding to the transaction type to a second value comprised in the second user information.

Images