US20190057198A1 - Matching Accounts Identified in Two Different Sources of Account Data - Google Patents

Abstract

Among other things, first and second sets of authentication credentials are used to access respectively data about a first set of one or more accounts from a first source and data about the one or more of the second accounts from the a second source. The data are analyzed to identify (a) one account of the first set of one or more accounts and (b) the one of the one or more of the second accounts as possibly a single account. After information is presented to a user an indication is received from the user that they are a single account. For a computation that requires data about the single account, data from the first source or data from the second source or data from both are used, based on a predefined computational rule.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation application of and claims priority to U.S. application Ser. No. 15/681,482, filed on Aug. 21, 2017 and is incorporated here by reference.
• This description is related to a description contained in U.S. patent application Ser. No. 15/593,870, filed May 12, 2017, and incorporated here by reference.
BACKGROUND
• This description relates to matching accounts identified in two different sources of account data.
• As shown inFIG. 1, typicaldata processing systems10 produceoutputs12 by applyingspecified processes14 tointernal data values16 that representinternal data concepts18 havingparticular meanings20. At least some of the internal data values can be derived frominput data values22 provided by one ormore data sources24 usingmappings26 that address the fact that input data values available from the sources representinput data concepts28 that havemeanings30 that may not directly match the meanings of the internal data concepts intended by the developer of the system. The mappings are predefined when the system is built—based on the characteristics of the data sources and the data values that they provide—and remain unchanged to assure that, for example, numerical outputs generated by the system conform to the intentions of the designer of the system.
• For example, a system may be designed to use an internal data concept of “annual percentage rate (APR) of interest on a credit card debt.” The system may use that internal data concept in a computational process that generates an output representing an “annualized cost of the interest based on the current balance” by multiplying internal data values for an “APR” internal data concept by internal data values for an “outstanding-balance” internal data concept. For this purpose, the system needs to determine the internal data values based on input data values.
• In this example, suppose that there are two sources (source A and source B) of input data values related to the APR internal data concept and that neither of the sources may be expected always to provide input data values that square exactly with the developer's intended meaning of the APR internal data concept although one or the other of both of them may provide useful information related to that internal data concept. Based on characteristics of sources A and B and the data values that they provide, the developer may decide to attribute to the APR internal data concept the meaning “the higher of the APRs provided by source A and source B.” The designer in typical known systems would then specify a corresponding, unchanging mapping from the data values provided by sources A and B to the data values for APR to be used by the system in producing the output.
• Input data values related to an internal data concept can be obtained from sources external to the system, such as a data vendor, or internal to the system, such as a company's own databases of enterprise resource planning information, financial information, or customer relationship management information, among others.
SUMMARY
• In general, in an aspect, a first set of authentication credentials is received for access to a first source of data about a first set of one or more accounts of a user. The first set of authentication credentials is used to access data about the first set of one or more accounts from the first source. A second set of authentication credentials is received for access to a second source of data about one or more second accounts. The second set of authentication credentials is used to access data about the one or more of the second accounts from the second source. The data about the first set of one or more accounts and the data about the one or more of the second accounts are analyzed to identify (a) one account of the first set of one or more accounts and (b) one of the one or more of the second accounts as possibly a single account. Information is presented to the user identifying the one account of the first set of one or more accounts and the one of the one or more of the second accounts. An indication is received from the user that the one account of the first set of one or more accounts and one of the one or more second accounts are a single account. For a computation that requires data about the single account, data from the first source or data from the second source or data from both are used, based on a predefined computational rule.
• Implementations may include one or a combination of two or more of the following features. The data accessed from the first source of data includes a credit report. The second source of data includes a financial institution. The first set of one or more accounts includes credit accounts.
• One or more of the second accounts includes a credit account. The first set of authentication credentials are received by interaction with the user through a user interface. The second set of authentication credentials are received by interaction with the user through a user interface. The computer maintains an ontology of data concepts. The data about the one account of the first set of one or more accounts and the data about the one of the one or more of the second accounts are associated with respective data concepts of the ontology. The predefined computational rule has inputs that include a data concept associated with data about the one account of the first set of one or more accounts and a data concept associated with data about one or more of the second accounts. The output of the predefined computational rule includes data associated with the single account. The data about the first set of one or more accounts and the data about the one or more second accounts is analyzed to identify (a) one or more additional accounts of the first set of one or more accounts and (b) corresponding one or more additional second accounts as possibly single accounts.
• These and other aspects, features, and implementations can be expressed as methods, apparatus, systems, components, program products, methods of doing business, means or steps for performing a function, and in other ways.
• These and other aspects, features, and implementations will become apparent from the following descriptions, including the claims.
DESCRIPTION
• FIGS. 1, 2, 3, 5, and 8 are block diagrams.
• FIG. 4 is a diagram of ontologies.
• FIG. 6 is a data concept list.
• FIG. 7 is a user interface display.
• FIG. 9 is a sequence diagram.
• FIGS. 10 through 23 are screens of a mobile device.
• As shown inFIG. 2, here we describetechnology40 that enablesmeanings41 that will be attributed to internal data concepts42 (and the correspondingmappings44 from input data values46 to internal data values48 that correspond to the internal data concepts) to be determined at any time, including after thetechnology40 or thesystem50 of which it is part has been developed and built and even as late as run-time, when thetechnology40 is generating internal data values or thesystem50 is generatingoutputs52 based on the data input values and internal data values using processes49. In some implementations, one or more of the internal data concepts are associated with accounts such as credit card accounts of an end user. The internal data concepts can include, for example, the account identifiers, unpaid balances, interest rates, and other attributes of such accounts. Input data values can include values of such attributes expressed in accordance with input data concepts of the source of the data values. Internal data values can include such attributes expressed in accordance with internal data concepts. There may be mappings between such input data values for such accounts and corresponding internal data values for the accounts. In order to produceuseful outputs52, e.g.,guidance72, about such accounts, it is desirable for the system to include in its internal data concepts information about as many (usefully all) of the user's accounts as possible, and to be able to treat duplicate internal data concepts for a given account as a single account so that the treatment of the internal data concepts is complete and the use of corresponding internal data values is non-duplicative.
• We sometimes refer to three stages in the operation of the system50 (and its technology40) and to three categories of people who participate in those stages: development time, configuration time, and run time. During development time, the system is being designed and built by developers. During configuration time,administrators54 typically employed by business users of the system can work through an interactive graphical user interface56 (or in other ways) to configure the technology, for example, by defining computational recipes (discussed later),meanings58,41 to be attributed to inputdata concepts60 andinternal data concepts42, andconcept mappings45 of meanings among input data concepts and internal data concepts, among other things. Run time is when, typically,end users62 are interacting with thesystem50 through auser interface64 that is presented by a browser or a mobile app, for example. During runtime, input data values and internal data values are being processed to generate premises and outputs for the end users, among other activities. In general, the three stages may overlap in time and in function, and the same people may be developers and administrators or administrators and end users. For example, configuration time and run time may overlap in that administrators can be altering the definitions, meanings, recipes, and mappings in real time as the end users are interacting with the system. Administrators need not be specially trained in computer or software technologies, but only need be able to deal with and express the meanings of data concepts and how they are to be mapped from and to other data concepts.
• We use the term “mapping” broadly to include, for example, any translation, transformation, computation, combination, or other conversion from one or more inputs to one or more outputs, such as a mapping from one or more data concepts to one or more other data concepts. A mapping of concepts (which we sometimes refer to as a concept mapping) can be applied to data values during run time. We sometimes refer to a mapping applied to data values as a value mapping.
• We use the term “meaning” broadly to include, for example, any definition, connotation semantic, explanation, understanding, or interpretation, or combinations of them of a subject, such as a data concept or a data value, to name two.
• We use the term “internal data concept” broadly to include, for example, any notion, view, thought, or conception about data and that is of use (among other places) internally to thetechnology40 or to thesystem50.
• We use the term “input data concept” broadly to include, for example, any notion, view, thought, or conception about input data and that is of use (among other places) externally to thetechnology40 or to thesystem50.
• We use the term “recipes” broadly to include, for example, any analytical, mathematical, statistical, or logical process, or combination of them that can be applied to one or more inputs to generate one or more outputs. The inputs can include, for example, internal data values or input data values or premises, and the outputs can be premises used within a system or provided as outputs of the system.
• In some implementations, thetechnology40 receives input data values and produces internal data values using the mappings. One or more of the internal data values that it produces can then be used as inputs by other parts of thesystem50, notably theprocesses49 that use recipes to produce premises andultimate outputs52 to be provided to end users.
• The technology40 (and theoverall system50 of which it is part) is useful in contexts, among many others, in which interactions through theuser interface64 withhuman users62 extend over a period of time (e.g., days, months, years, or decades) and are used to advise or otherwise guide the users with respect to an aspect of the user's activities or behavior sometimes with the goal of improving an outcome of the activities or behavior. Thesystem50 provides guidance that is useful even though the users may at times act irrationally, ignore the guidance, or take a different course than the one suggested. The outputs of the system (the guidance) can be numerical, non-numerical, or a combination of the two, and can be expressed in a variety of ways, such as possibilities, suggestions, hypothetical scenarios, questions, or challenges, among others. The interactions may occur in sequences in which the user provides inputs70 (which can be treated as part of the input data values46), the system providesguidance72 in the form of outputs, the user provides other inputs, and the system provides other guidance, iteratively, without necessarily reaching a defined end point. In some examples, the guidance is intended to be a sequence of directionally correct pieces of advice that change over time as the context is monitored.
• In some cases, theoutputs52 are generated by statistical processes or analytical processes or combinations of them that are part ofsystem50 and are configured by administrators during configuration time or run time. The guidance to the user (represented in the outputs of the system) are based on “recipes”74 defined by the administrators. The recipes are executed byprocesses49 at run time to generate premises based on internal data values48. Theoutputs52 are based on the premises. Additional information describing examples of features ofsystem50 are included in U.S. patent application Ser. No. 14/304,633, filed Jun. 13, 2014; Ser. No. 14/989,935, Jan. 7, 2016, and Ser. No. 15/231,266, filed Aug. 8, 2016, which are incorporated here by reference.
• Thetechnology40 and theoverall system50 are especially useful in contexts that have one or more of the following characteristics:
• • a. A givendata source78 and the input data values that it provides have characteristics that affect the meaning, significance, and usefulness of the values, including one or more of: reliability, availability, currency, accuracy, consistency, and precision, among others.
  • b. The behavior of a user related to the guidance provided by the system may be unpredictable, unreliable, or unresponsive.
  • c. The guidance to the user is intended to be effective over time periods during which the context, data sources, meanings of data concepts, behavior of users, or desired outcomes, or combinations of them, among other things, will change.
• Although we describe examples of thetechnology40 andsystem50 related to financial contexts and particularly examples that involve providing guidance to end users who are consumers with respect to activities and behavior related to their financial situations, thetechnology40 and thesystem50 are applicable to a very wide variety of contexts including realms other than financial, and financial examples other than those related to consumer guidance.
• One or more of therecipes74, which are executed in theprocesses49, use internal data values48 to generate premises that are the basis of theoutputs52. For the recipes to work properly, the internal data concepts that are the basis of the internal data values used by the recipes must conform to the definedmeanings41, and the administrators and the technology must be able to rely on the defined meanings; otherwise the system will operate in a garbage in/garbage out mode. Therefore, when the administrator specifies an internal data concept, say, “APR of a credit card,” as an input data concept of a recipe, she must be confident that the corresponding internal data values will conform to the defined meaning of “APR of a credit card”, a meaning that she is aware of and understands. This meaning of “APR of a credit card” could be “A credible estimate of the annualized interest expense of carrying a balance on a specified credit card.”
• On the other hand, although theinput data sources78 may base the input data values46 that they provide on their own defined input data concepts60 (or ones that can be inferred by or interpreted by an administrator of the technology40), none of those input data concepts may match the internal meaning “APR of a credit card” as “A credible estimate of the annualized interest expense of carrying a balance on a specified credit card.” For example, one input data source may provide input data values that are accurate but not current. Another input data source may provide data values that are current but not accurate. A third input data source may provide credible current values but not provide them reliably; they may be sometimes available and sometimes not. In other words, in a variety of examples, the source meaning of an input data concept may not match the internal meaning for that data concept. Even so, a developer who is familiar with the characteristics of the sources and the meanings of their data concepts may be able to define amapping74 from the input data concepts of the data values provided by one or more sources for a given data concept to the internal data concept enabling the intended meaning of the internal data concept to be met. Then at run time, for example, the system can receive input data values for the input data concepts from those sources, transform them based on the mappings to internal data values for the internal data concept, and provide them to the premise generators.
• As an example, internal data values for the “APR of a credit card” might be obtained by a mapping that instructed the technology to accept the values of source A without modification if source A, known to be unreliable in its availability, is actually making values available; otherwise to combine the values of source B weighted 75% with the values of source C weighted 25%.
• Significantly, the mapping is applied at run time, and the mapping can be altered freely by the administrators at configuration time or run time or both. Alterations may be prompted by changes in the characteristics of the input data sources, the input data concepts and meanings, the intentions and interpretations of the administrator, and for a wide variety of other reasons and combinations of them.
• Therefore, the effect of applying a mapping is determined at the time when internal data values of the internal data concept are needed by, for example, theprocesses49 based onrecipes74 ormappings44 and may change at any time up to the moment when the mapping is applied. For example, at a first time, T1, a mapping to “APR of a credit card” may specify that data sources B and C be weighted 75% to 25%. At time T2, an administrator may determine that a more credible value will be generated by changing the mapping so that the weightings are 50% and 50%. The administrator may make the change easily by interacting with controls of theuser interface56 or in other ways (for example altering a text file). After time T2 whenever “APR of a credit card” is needed the new weightings will be applied. As a result, the manner in which input data concepts are used for formulating a corresponding internal data concept can change over time and therefore the meaning of “APR of a credit card” can change over time. That meaning is not fixed at development time nor is it fixed at configuration time.
• Although we have so far discussed input data concepts and internal data concepts and their related meanings individually, data sources typically organize categories of their data according to ontologies or the existence of such ontologies is explicit or can be inferred. The internal data concepts and related meanings of thetechnology40 also can be organized according to one or more internal ontologies. By understanding, defining, and taking advantage of ontologies of input data concepts and internal data concepts, administrators can more easily develop mappings from categories of input data concepts to categories of internal data concepts. Ontologies can be expressed in a variety of ways including database schemas, the Resource Description Framework (RDF) of the World Wide Web Consortium (W3C), and others.
• We use the term “ontology” broadly to include, for example, any organizational framework for meanings or concepts, such as a hierarchy, a tree, a classification, a ranking, a scale, an ordering, an outline, an arrangement, or combinations of them, to name a few.
• As shown inFIG. 3, thetechnology40 provides amapping facility80 that can be made available to administrators through an interactive user interface56 (or in some cases by editing of a text file) that enables mediation between existingontologies82,84 ofinput data concepts86,88 ofinput data sources90,92 andinternal ontologies91,93 ofinternal data concepts94,96. In defining the mappings, the administrators are able to express and changecomplex relationships97 that map any M input data concepts to any N internal data concepts. The complex relationships can be created and updated at any time up to and including during run time even while end user outputs are being generated. Thetechnology40 could include a comprehensivegraphical user interface102 to enable administrators to observe, understand, manipulate, alter, organize, and define data concepts, ontologies, mappings, and relationships among them. In some implementations, the information about the mappings can be stored, observed, understood, manipulated, altered, organized, and defined in a simple text file and manipulated by a user through a text editor.
• As shown inFIG. 4, for example, anontology110 of a data input source may include a hierarchy ofinput data concepts112 headed by the input data concept “total balance”114. That concept has (e.g., is the sum of) two main component data concepts: “total non-mortgage balance” and “total credit card balance”. “Total credit card balance” in turn has (e.g., is the sum of) three components: “credit card balance,” “credit card trade balance,” and “installment trade balance.” And so on. At the same time, in this example, suppose that thetechnology40 includes an internal data concept “subset of credit card balance”116 that has fiveinternal data concepts118 under it. The administrator can use the mapping facility to define mappings from one or more of the (M) input data concepts to one or more of the (N) internal data concepts.
• An example of a complete version of an ontology of internal data concepts follows:
• • Total Debt Balance
    • Total Secured Debt Balance
    • Total Unsecured Debt Balance
  • 1 Total Unsecured Debt Balance
    • Total Personal Loan Debt Balance
    • Total Credit Card Debt Balance
  • 2 Total Credit Card Debt Balance (sum of trades below)
    • Credit Card account status revolving=True (for 1 or more trades, see 2nd branch)
    • Credit Card account balance (for 1 or more trades)
  • 3 Credit Card account balance
    • Credit Card balance MX
    • Credit Card balance TU
    • Credit Card balance user
• The mappings can refer not only to input data concepts and internal data concepts as objects but also to subjects and relationships. For example, a mapping can express a relationship between input data concepts and an internal data concept as a formula to be applied to the input data concepts to obtain the internal data concept. In some cases the subject of the mapping can be the relationship and the internal data concept produced by the mapping can be the formula itself.
• FIG. 5 illustrates an example of a mapping from input data values of a data source to an internal data value. Adata source402 makesavailable debit transactions404 of a card holder. By applying an exclusion filter, the transactions that involvepurchases408 can be derived. The purchase values of those transactions can be summed410 and divided by aperiod412 represented by the transactions to generate adaily purchase average414 for that period.Items410,412,414 represent internal data values associated with internal data concepts whileitems404,406, and408 represent input data values associated with input data source concepts.
• As shown inFIG. 6,technology40 can use alist122 of uniqueinternal data concepts123 anddescriptions124 of each of them. For example, the uniquely named internal dataconcept ci.debt_to_income_ratio123 is described as having the meaning “the sum of all debt the user pays per month divided by the user's income”124.
• FIG. 7 illustrates how mappings and recipes can be used to produce internal data concepts from input data concepts and to produce premises and outputs from internal data concepts.FIG. 7 also illustrates how mappings and recipes can vary their use of input data concepts depending on a time frame under consideration; in other words, the recipes can operate dynamically (non-statically). The boxes and lines ofFIG. 7 represent input data concepts, internal data concepts, mappings, processes that use the internal data concepts and input data concepts to produce premises and outputs, and the flow of information among these elements.
• Many of the blocks in the bottom half ofFIG. 7 represent input data concepts, for example, input data concepts such as132 that begin with the characters “mx” represent input data concepts of input data values provide by an input data source MX. The remainder of the identifier of each concept specifies a unique input data concept for that input data source, in accordance with an input ontology. For example, block132 refers to an estimated annual amount for the statement interest rate.Block134 begins with the word “cinch” (which refers to a system developed by Cinch Financial, Boston, Mass.) and represents an account interest rate estimated amount.
• In the example ofFIG. 7, a premise138 (User Mispricing) is to be generated by theprocesses49 of thesystem50 when the expression shown inblock140 is true. That expression recites a mathematical relationship to be tested using twointernal data concepts142,144. (These internal data concepts are part of the internal ontology of thetechnology40 and are generated by the technology for use by theprocesses49 of thesystem50.) Theinternal data concept142 is generated by a mapping that combines aninternal data concept146 andinternal data concepts148,150, the values for which are generated by fair price models. (Additional information about how the fair price models may be implemented is described in U.S. patent application Ser. No. 14/989,935 mentioned earlier.)Internal data concept146 in turn is generated by a mapping frominternal data concepts152 and154. Amapping156 generates theinternal data concept152, for example, frominternal data concepts160,162,164,166. The pairs ofinternal data concepts160,162 and164,166 are produced bysimilar mappings168,170, and172,174 applied to input data values for two different credit cards as shown.
• Themapping168 uses aninput data concept180 from the MX source, an internalinput data concept134 derived (by a simple mapping139) frominput data concepts132 and133, and a tested input from auser182.
• Theinternal data concept162 is fed back from themapping156 as a way to check the appropriateness of one of the internal data values used in the mapping. Amapping170 tests those values against input data values from twosources190,192. If an error results from applying the mapping, then the user is asked for the correctinput data value194.
• At run time, an engine in thetechnology40 will continuously execute the mappings on the input data values according to the current versions of the mappings that result from the work of the administrator and will provide the mapped internal data values to the processes that execute other mappings to produce other internal data values. The generated data values shown inFIG. 7 then can be used as inputs to processes49 (FIG. 2) which generate premises and outputs for the end user.
• In some implementations, as illustrated inFIG. 7, there can be two styles of mappings: simple and dynamic. A simple mapping is a direct static translation from an input data concept to an internal data concept of the kind illustrated as mapping139 fromblock132 to block134 inFIG. 7.
• An example of a dynamic mapping is illustrated by the set ofblocks200 inFIG. 7. There the mapping includes amapping block168. The internal data values generated by the mapping for the internal data concept ofblock160 are not static but are only determinable at run time based in part on the comparisons of data values and on the input of the user.
• FIG. 7 also illustrates a second dynamic mapping example202 that involves applying a given mapping more than once to different sets of data values (for example associated with two different credit cards of a given end user) and then aggregating the data values.
• Therefore, mappings can be both dynamic (in the sense that a specific current version of a mapping can produce different values at run time depending on the circumstances) and configurable (in the sense that the current version of a mapping can be changed by the administrator at any time up to and including run time) or both.
• In some implementations, the mappings, ontologies, and data concepts are expressed and updated by the administrators in a source text file57 (FIG. 2) through the administrative user interface56 (which in some cases can be a simple text editor), in forms of expression that are conveniently understood by humans.
• As suggested, for example, byFIG. 7, it is desirable for the system that we are describing to have accurate current internal data concepts and internal data values for all or as many as possible of the accounts (e.g., credit card accounts) of each of the users, and to be able to treat as a single consistent account duplicate internal data concepts or duplicate internal data values for such an account. For example, if the system is to generate an internal data value representing an internal data concept for an aggregate current credit debt balance, it is important that the credit debt balance for each account be counted once and only once.
• Therefore, as part of building an internal ontology of internal data concepts for a given user, in some implementations, the system, in cooperation with the user, identifies as many accounts (credit card accounts, for example) of the user as possible, identifies two or more accounts that are duplicative in representing a single account, and then treats the two or more accounts as a single account for purposes of use corresponding internal data values for computational purposes. In some cases, the process of generating the complete set of accounts (and identifying duplicative account information) is implemented as part of an onboarding process for a new user and can be repeated from time to time with the user to assure that the set of accounts is up-to-date and treated non-duplicatively. An example of a portion of an internal ontology for a given user that identifies the unique internal data concepts for a set of credit card accounts of a user is shown below.

• “accounts”: [

  	{
  	“source”: {

  	“value”: “credit_source”,
  	“type”: “enum”,
  	“name”: “user.accounts[ ].source”

  	},
  	“number”: {

  	“value”: “X1110”,
  	“type”: “masked_string”,
  	“name”: “user.accounts[ ].number”

  	},
  	“new”: {

  	“value”: true,
  	“type”: “boolean”,
  	“name”: “user.accounts[ ].new”

  	},
  	“last_statement_month”: {

  	“value”: “2016-11”,
  	“type”: “month_date”,
  	“name”: “user.accounts[ ].last_statement_month”

  	},
  	“last_statement_balance”: {

  	“value”: 1000,
  	“type”: “usd”,
  	“name”: “user.accounts[ ].last_statement_balance”

  	},
  	“institution_name”: {

  	“value”: “CBNA”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].institution_name”

  	},
  	“id”: {

  	“value”: “17f018e0-09bc-49bb-a40a-d856f0180a29”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].id”

  	},
  	“credit_limit”: {

  	“value”: 2500,
  	“type”: “usd”,
  	“name”: “user.accounts[ ].credit_limit”

  	},
  	“balance”: {

  	“value”: 960,
  	“type”: “usd”,
  	“name”: “user.accounts[ ].balance”

  	},
  	“association_status”: {

  	“value”: “unprompted”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].association_status”

  	},
  	“associated_institution_name”: {

  	“value”: “CBNA”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].associated_institution_name”

  	},
  	“account_type”: {

  	“value”: “credit_card”,
  	“type”: “enum”,
  	“name”: “user.accounts[ ].account_type”

  	}
  	},

  {

  “source”: {

  	“value”: “transaction_source”,
  	“type”: “enum”,
  	“name”: “user.accounts[ ].source”

  	},
  	“number”: {

  	“value”: “1110”,
  	“type”: “masked_string”,
  	“name”: “user.accounts[ ].number”

  	},
  	“new”: {

  	“value”: false,
  	“type”: “boolean”,
  	“name”: “user.accounts[ ].new”

  	},
  	“institution_name”: {

  	“value”: “Cinch Financial V2”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].institution_name”

  	},
  	“id”: {

  	“value”: “c69185f3-752e-42f8-a7ba-daa876a1bc69”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].id”

  	},
  	“credit_limit”: {

  	“value”: 2600,
  	“type”: “usd”,
  	“name”: “user.accounts[ ].credit_limit”

  	},
  	“balance”: {

  	“value”: 1100,
  	“type”: “usd”,
  	“name”: “user.accounts[ ].balance”

  	},
  	“authentication_status”: {

  	“value”: “complete”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].authentication_status”

  	},
  	“association_status”: {

  	“value”: “unprompted”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].association_status”

  	},
  	“account_type”: {

  	“value”: “credit_card”,
  	“type”: “enum”,
  	“name”: “user.accounts[ ].account_type”

  	},
  	“account_site_id”: {

  	“value”: “AV0VvIKsQJP21Z5LhQtr”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].account_site_id”

  	}
  	}

  	]

• As shown inFIG. 8, operation of theruntime engine219 that is part of thetechnology40 includes aninitialization phase221 and arun time phase223. The initialization phase prepares the engine for run time and is executed when the technology is started up and when any of the input data concepts or mappings is updated by an administrator during runtime of thesystem50. During the initialization phase, acompiler220 uses the data concept, recipe, andmapping definitions222 contained in the source text file andruntime libraries224 to generate optimizedexecutable bytecode225 that is executed at run time by an ontology process226 (the engine of the technology40). Process226 runs the bytecode in effect to apply thedefinitions222 to theinput data values228 to map them tointernal data values230 which can be used by the premise generators to produce premises and outputs for delivery to the end users. Compilation of the source file is fast, and the compiled bytecode enables fast execution. During the run time phase, multiple instances of the runtime engine run in parallel serving end user requests and enabling end user guidance. By effecting rolling re-initializations of the instances, the technology can adjust to changes made by administrators to the mappings, definitions, and ontologies, essentially in real time with respect to the activities of the end users, and therefore continue to provide guidance to the end user without interruption.
• For purposes of expressing the input data concepts, the internal data concepts, their meanings, the mappings, and the ontologies, the technology uses an expression language. An example of a definition of a data concept is the following.
• • Name: user.total_current_debt
  • Description: the sum of all debt the user holds
  • Formula: user_profile_debt_amount
• Examples of definitions related credit card accounts of a user are shown below.
• Name: _credit_card_accounts[ ]
• Description: All credit cards for the user
• Formula: filter(“account_type”, _accounts[ ], “eq”, “credit_card”)
• Name: user.credit_card.all.credit_limit
• Description: sum of total credit limit for all credit cards
• Formula: sum(_credit_card_accounts[ ].credit_limit)
• Name: user.credit_card.all.ending_balance
• Description: sum of ending balance for all credit cards
• Formula: sum(_credit_card_accounts[ ].ending_balance)
• Each data concept as expressed in the text file includes:
• Name: a unique name of the data concept. The first character of the name must be alphabetic or an underscore [A-Za-z_]. Each remaining character can be an alphanumeric or an underscore [a-zA-Z0-9_]. Compound names in which the portions of the name are separated by period characters, for example user.total_current_debt, imply a hierarchy (ontology) in which the periods delimit branches that can be used for grouping related data concepts.
• Type: an optional code used to impart additional meaning to the data concept. Type is similar to a data type, but is less strict in that the value and interpretation of Type is up to the application and is not enforced in the language itself. Type is optional. If supplied, it must come between Name and Description. Type can be used by user interfaces to inform the presentation of the data concept. For example, the type used indicates a data concept that is in US dollars and can be formatted accordingly.
• Description: a textual description of the data concept, which can be multiple lines. Along with the Name, the Description supplies meaning to (defines) the data concept.
• Formula: an arithmetic definition of the data concept. Can reference input data concepts as well as internal data concepts.
• Data concepts can be scalar quantities like theinteger 42 or the string “good”. Data concepts can also be lists of scalars like [1, 2, 4], objects such as:

• 	{
  	”name”: ”main checking account”,
  	”balance”: 500. 00
  	}

• or lists of objects.
• In the example above the formula is a simple reference to an input concept, but formulas can be arithmetic expressions as well. Some examples:
• • Name: y
  • Formula: x+1
  • Name: z
  • Formula: (y*2)+1
• At runtime the above formulas require a value of x to be input in order to compute y and z. If a value of 10 is supplied for x, then y will be computed to be 11 and z will be computed to be 23.
• Below are other examples of internal data concepts including formulas used to determine them from other data concepts. These examples would be stored in the text file and could be text edited in that file to add, remove, and update the entries.
• # Arithmetic expression in function call
• Name: user.allocatable_lump_cash
• Type: usd
• Description: allocatable one-time cash
• Formula: max (user.total_cash−user.working_capital*1.5, 0
• # Count of a list
• Name: user.credit_card .all.count
• Type: int
• Description: number of total credit cards a user has
• Formula: count (credit_card .accounts[ ])
• # Summing property of a list of objects
• Name: user.credit_card.all.minimum_payme nts
• Type: usd
• Estimated: true
• Description: sum of minimum payments on all credit cards
• Formula: sum(credit_card .accounts [ ].mx .payment_minimum_estimated_amount
• # Nested function calls
• Name: category.top_ranked_name
• Type: st ring
• Description:
• Formula: if(category .consumption .rank=1, 11 consumption11,
• if(category .savings .rank=1, “savings”,
• if(category .debt.rank=1, “debt”,
• if(category .protection.rank=1, “protection”, “unknown”))))
• Following is a more complicated example.
• # Complicated formula example showing the use of a function from an extension
• # library ML.loan_approvel_model1( ) which takes many arguments
• Name: user.personal_loan .likely_preapproved
• Type: Boolean
• Description: likely to be pre-approved for a personal loan
• Formula: (ML.loan_approval_model1(user.credit_card .revolving .ending_balance,
• • user.credit_score, user.unsecured_debt_obligation_to_income_ratio,
  • user.employed_less_than_a_year)>0.5)
• and (ML .loan_approval_model2(user.credit_card .revolving .ending_balance, 36,
• • user.gross_annual_income,
  • user.employed_less_than_a_year, user.public_delinquencies,
  • user.public_derogatory_marks, user.credit_inquiries,
  • user.debt_accounts,
  • user.credit_card.all.utilization, user.public_bankruptcies,
  • user.tax_liens,
  • user.credit_history)>0)
• and (ML .loan_approval_model2(user.credit_card .revolving .ending_balance, 60,
• • user.gross_annual_income,
  • user.employed_less_than_a_year, user.public_delinquencies,
  • user.public_derogatory_marks, user.credit_inquiries,
  • user.debt_accounts,
  • user.credit_card .all.utilization, user.public_bankruptcies,
  • user.tax_liens,
  • user.credit_history)>0)
• A standard function library is included in the engine of the technology. Functions provided by the library can include:
• Name: credit_card_payment
• Formula: max(minimum_payment, suggested_payment)
• The above sets the credit_card_payment model input to the larger of the minimum_payment and the suggested_payment. The following standard library functions are available:
• • abs(x)—absolute value of x
  • ceil(x)—smallest integer>=x
  • count(list)—number
  • exp(x)—Euler's number e raised to the power of x
  • filter(name, list, op, value)—find the elements of list whose property name matches the condition specified by op and value.
• For example: filter(“balance”, user.checking_accounts, “gt”, 1000) returns a list of checking accounts that have a balance greater than 1000.
• • floor(x)—largest integer<=x
  • if (test, trueValue, falseValue)—Return trueValue if test is true else return falseValue
  • log(x)—natural logarithm (base e) of x
  • max(x, y, . . . )—largest value in arguments (accepts list or any number of arguments)
  • mean(x, y, . . . )—arithmetic mean of arguments (accepts list or any number of arguments)
  • nper(r, pmt, pv)—# of payments of periodic payments of a given amount required to payoff a debt
  • pmt(r, nper, pv)—periodic payment amount required to payoff a debt in a given time
  • min(x, y, . . . )—smallest value in arguments (accepts list or any number of arguments)
  • sum(x, y, . . . )—sum of arguments (accepts list or any number of arguments)
• Functions can be used anywhere values can be used, so they can nest.
• In addition to the standard library, additional function libraries are easy to add to the runtime engine. The ontology process includes a machine learning library that predicts loan approval and APR based on model inputs.
• The engine is also used to define business rules, that is, recipes for output guidance (advice) to end users. A business rule is a condition and a result that applies if the condition is true. A set of ordered rules form a decision tree: the result of applying the ruleset is the result of the first rule whose condition is true.
• Here is a sample simplified ruleset:

• 	rule
  	if debt < $10
  	advise: no_financing_needed reason:
  	you_are_good
  	rule
  	if fico > 650
  	advise: personal_loan reason:
  	lowest_rate_for_you

• The above ruleset produces the no_financing_needed advice when debt is <$10. Otherwise if fico is >650 the ruleset produces the personal_loan advice. Otherwise there is no output produced.
• A ruleset can also produce values for named internal data concepts instead of or in addition to advice:

• 	rule
  	if debt < $10
  	{
  	estimated_one_time_cash: 500
  	estimated_recurring_cash: 200
  	estimated_impact: 10
  	}

• where the key/value pairs in curly braces are output values.
• The defined mappings, input data concepts, internal data concepts, recipes, and ontologies of the source file can be changed at any time up to and during run time, through the user interface, after which the source file is recompiled.
• As shown inFIG. 9, in an example sequence of operation of thetechnology40 and theoverall system50, an end user application300 (accessible, for example, through a web browser or a mobile app) enables the end user to sign up and link herfinancial accounts302 to thetechnology40, as part of the onboarding process mentioned earlier. Input sources ofdata values304 are then able to provide input data values306 (which we sometimes call “source facts”) to adatabase307 for staging. Theontology process308 appliesmappings311 to theinput data values310 identified in accordance with the input ontology to generateinternal data values312 identified in accordance with the internal ontologies for which there are available input data values necessary to apply to the mappings. Premises generators314 (here called a hunch service) use the generated internal data values to generate premises and pass them withinternal data values316 to a strategy process318 (which is sometimes referred to as a model). The strategy process generatesoutputs319 for delivery to recommenders321 which will provide guidance to the end user. In some implementations, the premise generators314 (hunch service) and thestrategy service318 operate by running rules of the kind illustrated in the very simple version of the ruleset shown above, and returning the resulting outputs. The strategy process performs at least the following functions320: a. determines a strategy for the end user based on the generated premises; to do so, it applies the stored mappings to the generated internal data values; b. uses a minimal set of input data values to do a.; and c. when information necessary for generating the output is missing, seeks the missing information.
• As part of the onboarding process, the system interacts cooperatively with the user through the web browser or mobile app in a way to identify accounts of the user and to attempt to assure that the user accounts are identified accurately, that all accounts are identified, and that accounts that are actually one and the same (i.e., a single) account are treated as being a single account.
• We use the term “user account” broadly to include, for example, any record maintained by one party with respect to its ongoing (e.g., transactional) relationship with another party (such as its customer or user) and in which transactions or activities for the account are recorded. Examples of a user account include a financial account, a consumer account, a user account, a credit card account, a debit card account, a bank account, a checking account, a savings account, a mortgage account, an investment account, an insurance account, a service account, a telephone service account, a health care account, a travel account, or a tax account, to name a few.
• One way for the system to accumulate identification information and access (authentication) credentials about a user's accounts would simply be to ask the user to identify each such account and provide the access credentials (which will be needed by the system in order to be able to treat the accounts as sources of input data values at run time) by entering them through the user interface.
• Here we describe an especially effective way to engage the user in a cooperative interactive process of accumulating user account identification information.
• The process (illustrated by smart phone screen shots inFIGS. 10 through 23) begins with the system inviting the user to link her accounts to the system (FIG. 10) and advising the user about the credit profile information that will be obtained in her credit report (FIG. 11). Next the user enters personal information that is used both for building internal data values for the internal ontology maintained for this user, to create a system account for the user, and to provide authentication information (credentials) to enable the system to log into and obtain credit report information from a data source such as Experian or Equifax (FIG. 12).
• The system then uses the authentication information to log into the credit data source and accumulates information about each of the credit card accounts referenced in the credit report. The accumulated information for each credit card account can include the name of the creditor, the account number, the credit limit, the last statement balance, and any other information that is available. The system stores the accumulated information as internal data values based on internal data concepts that are part of the internal ontology for this user and the account.
• The system then presents a list of the credit card accounts (FIG. 13) to the user. The entry for each card on the list includes the name of the creditor, a portion of the account number, the credit limit, and the last statement balance. The information presented on the screen is only a portion of the information available in the user's credit report, all of which is acquired by the system using the user's authentication information. The screen ofFIG. 13 also includes (at the top) information intended to give the user confidence in the competence, honesty, and objectiveness of the system by providing an encouraging accurate critique of the credit score and reporting accurate information acquired from the credit report.
• When the user clicks “Next” on the screen ofFIG. 13, she is presented the screen ofFIG. 14 asking her to identify (link) a primary bank checking account to the user's system account in the system that we are describing here. The user enters the institution name of the primary banking institution (or identifies it in a pre-populated list) and then is presented the screen ofFIG. 15, on which she enters the authentication information for that account and clicks on “submit.” The screen ofFIG. 15 also includes a notice (at the bottom) that continues to develop confidence in the user in the reliability and trustworthiness of the system.
• When the user has completed the information on the screen shown inFIG. 15, and clicks on “next,” the system logs into the user's primary bank account and accumulates information at both the account level (name of the account, total balance, account number, and other data) and at the transaction level (debits and credits by date and amount and payee for each of the transactions in the checking, savings, and related credit card accounts). All of this information is stored as internal data values corresponding to internal data concepts of the internal ontology for this user.
• Although, in this example, the interaction with respect to only a primary bank account is shown, the system encourages the user to enter information about every financial account of the user (and then logs into and fetches information from those accounts) so that the system has a complete picture of the user's accounts.
• In the example shown in the figures, the user's primary bank account carries a credit card that the system is able to present to the user to have her verify a match with one of the credit card accounts obtained from the credit report, that is the system is able to determine that the two credit card accounts are possibly one and the same single credit card account. To confirm that the system has correctly matched the two accounts, the system presents (FIG. 16) internal data values for the credit card account information obtained from the primary bank. In other words, the system believes that the credit card for which information is shown inFIG. 16 likely matches the entry for the credit card account shown onFIG. 13 and shows this information on the screen ofFIG. 16.
• When the user clicks the “next button” onFIG. 16, she is presented a screen (FIG. 17) that shows the credit card account information fromFIG. 16 at the top and the list of credit card accounts from the credit report at the bottom. The user is invited to indicate which of the credit card accounts from the credit report matches the credit card account from the primary bank (or to indicate that none of the matches).
• When the user clicks on one of the credit card accounts from the credit report, she is presented the screen ofFIG. 18 showing the matched account at the top. A link symbol in the lower left corner of the card identifies the matched account. The credit card account now shows the credit limit because the system was able to obtain the credit limit from the primary bank.
• The internal ontology in the system for this user captures and retains the matching relationship by holding internal data values for each of the credit card accounts that is part of the match and also by holding an internal data value that represents the determination by the system that the match has been made correctly. An example of this arrangement is shown below.

• 	“accounts”: [
  	{

  “source”: {

  	“value”: “combined_source”,
  	“type”: “enum”,
  	“name”: “user.accounts[ ].source”,

  	},
  	“number”: {

  	“value”: “1110”,
  	“type”: “masked_string”,
  	“name”: “user.accounts[ ].number”,

  	},
  	“new”: {

  	“value”: false,
  	“type”: “boolean”,
  	“name”: “user.accounts[ ].new”,

  },

  “last_statement_month”: {

  	“value”: “2016-11”,
  	“type”: “month_date”,
  	“name”: “user.accounts[ ].last_statement_month”,

  	},
  	“last_statement_balance”: {

  	“value”: 1000,
  	“type”: “usd”,
  	“name”: “user.accounts[ ].last_statement_balance”,

  	},
  	“institution_name”: {

  	“value”: “Cinch Financial V2”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].institution_name”,

  	},
  	“id”: {

  	“value”: “ff1c3713-88ac-4612-9c29-38ad6c0db5b4”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].id”,

  	},
  	“credit_limit”: {

  	“value”: 2500,
  	“type”: “usd”,
  	“name”: “user.accounts[ ].credit_limit”,

  	},
  	“balance”: {

  	“value”: 1000,
  	“type”: “usd”,
  	“name”: “user.accounts[ ].balance”,

  },

  “association_status”: {

  	“value”: “prompted”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].association_status”,

  	},
  	“associated_institution_name”: {

  	“value”: “CBNA”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].associated_institution_name”,

  	},
  	“account_type”: {

  	“value”: “credit_card”,
  	“type”: “enum”,
  	“name”: “user.accounts[ ].account_type”,

  	},
  	“account_site_id”: {

  	“value”: “AV0VvIKsQJP21Z5LhQtr”,
  	“type”: “string”,
  	“name”: “user.accounts[ ].account_site_id”,

  }

  	}
  	]

• In addition, the system creates a rule for generating internal data values for the matched account based on input data values from each of the sources with respect to that single account. For example, during runtime, the system can execute a rule that normally uses internal data values derived from the primary bank records when performing computations and presenting strategies to the user that relate to the matched accounts. Or the rule could rely instead on the credit report record in some cases, or on a combination of both the credit report and the bank account in some cases. An example of such as situation is shown below.
• Name: accounts[ ].association_status
• Description: Has the user been prompted to associate this account—‘unprompted’, ‘prompted’; ‘not_applicable’ for non-credit cards
• Formula: if(_accounts[ ].account_type !=“credit_card”, “not_applicable”,
• first default(accounts[ ].user_input.association_status, “unprompted”))
• Name: _accounts[ ].source
• Formula: if(_accounts[ ].tu_source=“credit_source”,
• • if(_accounts[ ].mx_source=“transaction_source”, “combined_source”, “credit_source”), “transaction_source”)
• Name: _accounts[ ].is_store_card
• Formula: if (accounts[ ].tu.type=“CH”, true, false)
• Name: _accounts[ ].institution_name
• Formula: first(accounts[ ].mx.institution, accounts[ ].tu.name)
• Name: _accounts[ ].associated_institution_name
• Formula: accounts[ ].tu.name
• Name: _accounts[ ].number
• Formula: first(accounts[ ].mx.number, accounts[ ].tu.number)
• Name: _accounts[ ].ending_—balance
• Formula: first(accounts[ ].mx.balance, accounts[ ].tu.balance, accounts[ ].user_input.balance)
• Name: _accounts[ ].credit_limit
• Formula: if(accounts[ ].mx.credit_limit>=250, accounts[ ].mx.credit_limit,
• • first(accounts[ ].tu.credit_limit, accounts[ ].user_input.credit_limit))
• The process shown in the screens ofFIGS. 17 and 18 is repeated until all of the credit card accounts identified in the credit report have been matched with credit card account information from financial institutions identified by the user and for which the user has provided authentication information for use by the system.
• Although we have discussed a process specifically involving credit card accounts, similar processes can be used to cooperatively and interactively work with the user to match and identify any kind of user account.
• When the user clicks on the “done” button onFIG. 18, she is presented the screen ofFIG. 19, which provides a notice enhancing the user's confidence in the system.
• When the user clicks the “start” button, she is presented the screen ofFIG. 20 that asks her for information known personally to her, in this case whether she pays the credit card balance in full every month on the indicated credit card account. She can click either “yes” or “no” and is then presented the screen ofFIG. 21. Whichever answer she gives, the system adds an internal data value to the ontology for her, and asks her about other cash, giving her the option of clicking “yes” or “no”.
• At this stage in the process, and at other times during the operation of the system, a wide variety of questions can be posed to the user to enable the system to develop a more complete set of internal data values describing the user and the user's accounts and financial situation. These questions may include additional account level details that are needed or missing from her credit profile or linked accounts (e.g., missing APR or account “pay in full” status) and other questions that increase the system's depth of understanding of the user's financial situation (e.g., other money or planned future expenses the system can benefit from knowing about).
• Which information a user is asked about (and in some cases required to provide), for example, account information, is determined by the system based upon the internal data values already acquired and available to the system about the user and the user's accounts, for example information provided from primary data sources. If information available from those sources is “complete” for the user's situation, the user need not be asked additional questions. But if, for example, none of the data sources could provide information about whether an account has been paid off each month, and the internal ontology of the system requires that information, the system determines it needs to obtain that from the user and prompts are with a question.
• More generally, the internal ontology of the system can be defined to include internal data concepts and relationships among them that are required or useful for the system as it performs computations and develops and provides strategic and other advice to a user. Certain portions of the internal ontology may represent internal data concepts that are useful for, necessary for, or critical to the operation of the system during run time. Over time, the system populates the internal ontology for a given user with internal data values for each of the internal data concepts of the internal ontology. As discussed here, this can be done partly by using authentication information provided by the user to obtain data values from protected sources, partly by obtaining information from publicly available sources, and partly by asking the user for information, among other ways. The system can probe the internal ontology for a user at any time to identify internal data concepts for which no internal data values have yet been acquired and, when necessary, can go to external sources to get those internal data values, including asking the user.
• Thus, for example, referring again to the bottom portion ofFIG. 10, if not all input data values needed for generating the strategies are present, the strategy process returns anotification322 to the ontology process. The ontology process determines324 missing input data values that will be needed to complete the mappings to the needed internal data values that are missing. Then the ontology process sends anotification326 to thedatabase307, which determines330 what questions to ask the end user in order to obtain the missing input data values. The questions332 are sent to the end user through the end user interface. The requested information is returned334; is converted to an expression of the missinginput data values336 which is returned to the ontology process and the remaining sequence is followed as discussed earlier. In some cases, other methods could be used to generate the missing data values.
• After clicking one of the buttons onFIG. 21, the user is presented the screens ofFIGS. 22 and 23 that report to her in several sections information that the system now believes it knows about her financial condition in several categories, including “money in and money out”, “debt and credit”, “available cash”, “linked accounts”, and “other”. The linked accounts shown in the screen ofFIG. 23 are a listing of the accounts a user has linked with the system outside of their credit report.
• The screens ofFIGS. 22 and 23 represent important steps in the trust-building process with the user. If the user recognizes herself and her financial situation in the “playback” of the screens ofFIGS. 22 and 23, she is more likely to trust future strategic advice from the system. The user has the opportunity to edit any of her responses or link additional accounts to ensure that the system has a robust view of her financial situation.
• Once this process of acquiring account and other financial information from the user has been completed (or updated), the system has stored as internal data values corresponding to internal data concepts of the ontology, information that can be used in executing computational rules and in giving reports to the user and providing strategies and other guidance and interaction.
• Thus, in effect, the account linking part of the process of on-boarding (or updating information about) a user can be based on acquiring two (or more) sets of input or internal data values for a given account and then cooperatively and interactively working with the user to correctly match accounts so that every account of the user is included in the ontology of the system and two or more matched accounts can be treated by the system as a single account for purposes of executing computational rules.
• For example, if the credit report contained three accounts and the user linked two accounts the ontology would reflect five total accounts. This may be inaccurate if some of the linked accounts are, in fact, the same as accounts represented in the credit report.
• The association (matching, linking) of an account from one data source with an account from another data source (credit report) resolves the ontology question of whether these are alternative views of the same account entity. This enables the runtime evaluation of the ontology to choose which information from either or both sources will be used to establish a unified view of that account entity.
• For example, an expression like this: first(accounts[ ].mx.balance, accounts[ ].tu.balance, accounts[ ].user_input.balance) tells the system the preferred order in which accounts should be used when selecting among competing balance amounts (e.g., the balance from the MX data source, the balance from the TU data source, or the balance provided directly by the user).
• In some implementations of the system, the internal relationship between the internal ontology of internal data concepts and instances of that conceptual ontology that apply to respective specific users of the system is implemented by generating and passing to system subcomponents a hierarchical JSON object, as illustrated by the examples presented earlier.
• Other implementations are also with the scope of the following claims.

Claims (11)

1. A method comprising:

using authentication credentials to obtain (a) data for an existing user account from a first party that maintains the existing user account for a user, and (b) putative data for a putative user account of the user from a second party unrelated to the first party,

matching the data for the existing user account and the putative data of the putative user account to infer that the putative user account is the same account as the existing user account,

mapping current data for the existing user account obtained from the first party to internal current data for the existing user account based on data concepts of a stored ontology,

mapping current data for the putative user account obtained from the second party to internal current data for the putative user account based on data concepts of the stored ontology, and

executing a predefined computational rule that uses either the internal current data for the existing user account or the internal current data for the putative user account or a combination of them, depending on a context of the execution, to generate an internal value to be used in providing guidance to the user, the generated internal value conforming to a data concept of the stored ontology.

2. The method ofclaim 1 in which the context of the execution comprises the availability of accurate current data from the first party or the second party or both.

3. The method ofclaim 2 in which the execution uses the internal current data for the existing user account if accurate current data is available from the first party.

4. The method ofclaim 2 in which the execution uses the internal current data for the putative user account if accurate current data is not available from the first party.

5. The method ofclaim 1 comprising storing, based on the ontology, an internal data value that represents the matching relationship of the one putative user account and the existing user account.

6. An apparatus comprising:

a processor, and

storage for instructions executable by the processor to

use authentication credentials to obtain (a) data for an existing user account from a first party that maintains the existing user account for a user, and (b) putative data for a putative user account of the user from a second party unrelated to the first party,

match the data for the existing user account and the putative data of the putative user account to infer that the putative user account is the same account as the existing user account,

map current data for the existing user account obtained from the first party to internal current data for the existing user account based on data concepts of a stored ontology,

map current data for the putative user account obtained from the second party to internal current data for the putative user account based on data concepts of the stored ontology, and

execute a predefined computational rule that uses either the internal current data for the existing user account or the internal current data for the putative user account or a combination of them, depending on a context of the execution, to generate an internal value to be used in providing guidance to the user, the generated internal value conforming to a data concept of the stored ontology.

7. The apparatus ofclaim 6 in which the context of the execution comprises the availability of accurate current data from the first party or the second party or both.

8. The apparatus ofclaim 7 in which the instructions are executable by the processor to use the internal current data for the existing user account if accurate current data is available from the first party.

9. The apparatus ofclaim 7 in which the execution uses the internal current data for the putative user account if accurate current data is not available from the first party.

10. The apparatus ofclaim 6 comprising storing, based on the ontology, an internal data value that represents the matching relationship of the one putative user account and the existing user account.

11. A method comprising

receiving from a user, first credentials for access to a credit card account maintained by a bank for the user,

receiving from the user, second credentials for access to credit bureau information about a credit card account of the user,

applying the first credentials to obtain a current balance on the credit card account maintained by the bank, and applying the second credential to obtain the current balance of the credit card account of the user in the credit bureau information,

inferring from the current balance on the credit card account maintained by the bank and the current balance on the credit card account in the credit bureau information that the two credit card accounts are the same account,

storing, based on an ontology of data concepts, an internal data value that represents the matching relationship of the credit card account in the credit bureau information and the credit card account at the bank, and

executing a computational rule that uses a credit card account balance received from the bank, interpreted according to a data concept of the ontology, when the credit card account balance is available from the bank, and uses a credit card account balance received in the credit bureau information when the credit card account balance is not available from the bank.

Images