Patent Grant
8370355
This disclosure relates generally to a system and method for associating data records within one or more databases, and in particular to a system and method for identifying data records in one or more databases that may contain information about the same entity and associating those data records together for easier access to information about the entity. Additionally, embodiments disclosed herein relate to associating one or more data records that may contain information about the same entity.
In today's day and age, the vast majority of businesses retain extensive amounts of data regarding various aspects of their operations, such as inventories, customers, products, etc. Data about entities, such as people, products, or parts may be stored in digital format in a computer database. These computer databases permit the data about an entity to be accessed rapidly and permit the data to be cross-referenced to other relevant pieces of data about the same entity. The databases also permit a person to query the database to find data records pertaining to a particular entity. The terms data set, data file, and data source may also refer to a database. A database, however, has several limitations which may limit the ability of a person to find the correct data about an entity within the database. The actual data within the database is only as accurate as the person who entered the data. Thus, a mistake in the entry of the data into the database may cause a person looking for data about an entity in the database to miss some relevant data about the entity because, for example, a last name of a person was misspelled. Another kind of mistake involves creating a new separate record for an entity that already has a record within the database. In a third problem, several data records may contain information about the same entity, but, for example, the names or identification numbers contained in the two data records may be different so that the database may not be able to associate the two data records to each other.
For a business that operates one or more databases containing a large number of data records, the ability to locate relevant information about a particular entity within and among the respective databases is very important, but not easily obtained. Once again, any mistake in the entry of data (including without limitation the creation of more than one data record for the same entity) at any information source may cause relevant data to be missed when the data for a particular entity is searched for in the database. In addition, in cases involving multiple information sources, each of the information sources may have slightly different data syntax or formats which may further complicate the process of finding data among the databases. An example of the need to properly identify an entity referred to in a data record and to locate all data records relating to an entity in the health care field is one in which a number of different hospitals associated with a particular health care organization may have one or more information sources containing information about their patient, and a health care organization collects the information from each of the hospitals into a master database. It is necessary to link data records from all of the information sources pertaining to the same patient to enable searching for information for a particular patient in all of the hospital records.
There are several problems which limit the ability to find all of the relevant data about an entity in such a database. Multiple data records may exist for a particular entity as a result of separate data records received from one or more information sources, which leads to a problem that can be called data fragmentation. In the case of data fragmentation, a query of the master database may not retrieve all of the relevant information about a particular entity. In addition, as described above, the query may miss some relevant information about an entity due to a typographical error made during data entry, which leads to the problem of data inaccessibility. In addition, a large database may contain data records which appear to be identical, such as a plurality of records for people with the last name of Smith and the first name of Jim. A query of the database will retrieve all of these data records and a person who made the query to the database may often choose, at random, one of the data records retrieved which may be the wrong data record. The person may not often typically attempt to determine which of the records is appropriate. This can lead to the data records for the wrong entity being retrieved even when the correct data records are available. These problems limit the ability to locate the information for a particular entity within the database.
To reduce the amount of data that must be reviewed and to prevent the wrong data record from being picked, it is also desirable to identify and associate data records from the various information sources that may contain information about the same entity. There are conventional systems that locate duplicate data records within a database and delete those duplicate data records, but these systems only locate data records which are identical to each other. Thus, these conventional systems cannot determine for instance if two data records with slightly different last names nevertheless contain information about the same entity. For much the same reason, these conventional systems cannot associate data records with multiple entities.
Moreover, in some cases, it may be desirable to associate a data record for a person with other data records for that person to represent the entity of that person while at the same time it may be desired to associated the same data record for the person with other data records for others in the same household at the person to represent a household entity. Conventional systems which may only associate identical data records together do not have this desired capability.
Embodiments disclosed herein provide a system and method for managing group entities. More specifically, in addition to associating a data record for a person with other data records for that person to represent an identity entity of that person, embodiments disclosed herein can associate the same data record for that person with other data records for other persons in a group entity. In this way, a person can be associated with members at the same household of that person.
Traditional entity management generally attempts to identify a single object. For example, if one is to query a database for “Bill Johnson”, then the database might return one unique “Bill Johnson” if found or “Not Found” if none exists in the database. More advanced database management systems can create and manage identity entities more intelligently. In some cases, if a record matches any of the existing records above a certain confidence score, then that record is considered to be part of the same identity entity, even if that record matches only one other records in the identity entity.
Embodiments disclosed herein bring a class of entities together in a group entity. The definition of what makes up an identity entity is different from a group entity with which items are grouped together. An example of a group entity is a household. Following the above example, a “Bill Johnson” may live in a household at a first address and have a summer house at a second address. There may be other members in the Bill Johnson family or other people living in Bill Johnson's household. Thus, a group entity “Bill Johnson Household” may comprise members associated with Bill Johnson and living in two different addresses. However, to be included in the same group entity, every member has to match everybody else in the group entity above a certain threshold. As a specific example, to be in the group entity having A, B, and C, D would have to match A, B, and C above a predetermined threshold. By comparison, in an identity entity, if A matches B, B matches C, and C matches D, D does not have to match A or B above any threshold to be part of the same identity entity having A, B, and C.
From another perspective, an identity entity pertains to consolidating records into a single identity; whereas a group entity pertains to expressing the relationship and association among these records. Thus, with identity entities, if two guys with the same name have different date of birth, the determination that they are not the same person is a binary decision. With group entities, the grouping mechanism is not binary. A record can participate in different group entities of the same type at the same time if that record has multiple descriptions and/or attributes associated with that record that match certain required criteria. Following the above example, if a record for Bill Johnson contains multiple addresses, it may be allowed to participate in both group entities. It is thus possible for a household to be made of people traveling to the same destination at the same time. As another example, a person might be a member of a boy scout troop and also belong to a travel club. In order to keep the expression of relationship and association from exploding where everybody is linked to everybody, a group entity threshold is usually set higher than an identity entity threshold and, as mentioned before, a member has to match everybody in the group entity above that threshold. According to embodiments disclosed herein, this member can exist within multiple entities.
One advantage provided by embodiments disclosed herein pertains to the ability to resolve, store, and retrieve member data having many-to-many relationships. For example, a company may wish to utilize group entities to identify strategic relationships within or outside the company. Another example is within the intelligence community where one embodiment of a group entity management system may allow organizations to graph “persons of interest” and other associated intelligence data.
Other features and advantages of the disclosure will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings.
The drawings accompanying and forming part of this specification are included to depict certain aspects of the invention. A clearer impression of the invention, and of the components and operation of systems provided with the invention, will become more readily apparent by referring to the exemplary, and therefore non-limiting, embodiments illustrated in the drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like features (elements). The drawings are not necessarily drawn to scale.
Preferred embodiments and the various features and advantageous details thereof are explained more fully with reference to the examples illustrated in the accompanying drawings. Descriptions of well known computer hardware and software, including programming and data processing techniques, are omitted so as not to unnecessarily obscure the invention in detail. Skilled artisans should understand, however, that the detailed description and the specific examples, while disclosing preferred embodiments of the invention, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions or rearrangements within the scope of the underlying inventive concept(s) will become apparent to those skilled in the art after reading this disclosure.
As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, product, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).
Additionally, any examples or illustrations given herein are not to be regarded in any way as restrictions on, limits to, or express definitions of, any term or terms with which they are utilized. Instead these examples or illustrations are to be regarded as being described with respect to one particular embodiment and as illustrative only. Those of ordinary skill in the art will appreciate that any term or terms with which these examples or illustrations are utilized encompass other embodiments as well as implementations and adaptations thereof which may or may not be given therewith or elsewhere in the specification and all such embodiments are intended to be included within the scope of that term or terms. Language designating such nonlimiting examples and illustrations includes, but is not limited to: “for example,” “for instance,” “e.g.,” “in one embodiment,” and the like.
Before discussing specific embodiments, an exemplary hardware architecture for implementing certain embodiments is described. Specifically, one embodiment can include a computer communicatively coupled to a network (e.g., the Internet). As is known to those skilled in the art, the computer can include a central processing unit (“CPU”), at least one read-only memory (“ROM”), at least one random access memory (“RAM”), at least one hard drive (“HD”), and one or more input/output (“I/O”) device(s). Examples of I/O devices can include, but are not limited to, a keyboard, monitor, printer, electronic pointing device, mouse, trackball, stylist, or the like. In some embodiments, the computer has access to at least one database. ROM, RAM, and HD are computer memories for storing computer-executable instructions executable by the CPU. Within this disclosure, the term “computer-readable medium” is not limited to ROM, RAM, and HD and can include any type of data storage medium that can be read by a processor. For example, a computer-readable medium may refer to a data cartridge, a data backup magnetic tape, a floppy diskette, a flash memory drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, or the like.
The functionalities and processes described herein can be implemented in suitable computer-executable instructions. The computer-executable instructions may be stored as software code components or modules on one or more computer readable media. Examples of computer readable storage media include, but are not limited to, non-volatile memories, volatile memories, DASD arrays, magnetic tapes, floppy diskettes, hard drives, optical storage devices or any other appropriate computer-readable medium or storage device. In one exemplary embodiment of the invention, the computer-executable instructions may include lines of complied C++, Java, HTML, or any other programming or scripting code. Additionally, the functions of the present disclosure may be implemented on one computer or shared/distributed among two or more computers in or across a network. Communications between computers implementing embodiments of the invention can be accomplished using any electronic, optical, ratio frequency signals, or other suitable methods and tools of communication in compliance with known network protocols.
Reference is now made in detail to the exemplary embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts (elements). In one embodiment, the system and method of the invention is particularly applicable to a system and method for indexing information from multiple information sources about companies to an explicit business hierarchy such as Dun and Bradstreet (D&B), Experian, or Equifax. It is in this context that the invention will be described. It will be appreciated, however, that the system and method in accordance with the invention has utility in a large number of applications that involve identifying, associating, and structuring into hierarchy information about entities.
In describing embodiments of the systems and methods of the present invention, it may first be helpful to go over examples of embodiments of systems and methods for associating entities which may be utilized in conjunction with embodiments of the present invention such has those described in the U.S. Pat. No. 5,991,758, entitled “System and Method for Indexing Information about Entities from Different Information Sources”, issued Nov. 23, 1999 by inventor Scott Ellard hereby incorporated by reference in its entirety.
As shown, the MEI 32 may receive data records from the information sources as well as write corrected data back into the information sources. The corrected data communicated to the information sources may include information that was correct, but has changed, information about fixing information in a data record or information about links between data records. In addition, one of the users 40-44 may transmit a query to the MEI 32 and receive a response to the query back from the MEI. The one or more information sources may be, for example, different databases that possibly have data records about the same entities. For example, in the health care field, each information source may be associated with a particular hospital in the health care organization and the health care organization may use the master entity index system to relate the data records within the plurality of hospitals so that a data record for a patient in Los Angeles may be located when that same patient is on vacation and enters a hospital in New York. As another example, in the health care field, a health care organization may use the master entity index system to relate data records within the plurality of hospitals so that data records for various patients which are members of the same household may be associated in the same entity.
The MEI 32 of the master entity index system 30 may be located at a central location and the information sources and users may be located remotely from the MEI and may be connected to the MEI by, for example, a communications link, such as the Internet. The MEI, the one or more information sources and the plurality of users may also be connected together by a communications network, such as a wide area network. The MEI may have its own database that stores the complete data records in the MEI, but the MEI may also only contain sufficient data to identify a data record (e.g., an address in a particular information source) or any portion of the data fields that comprise a complete data record so that the MEI retrieves the entire data record from the information source when needed. The MEI may link data records together containing information about the same entity in an entity identifier or associative database, as described below, separate from the actual data record. Thus, the MEI may maintain links between data records in one or more information sources, but does not necessarily maintain a single uniform data record for an entity. Now, an example of the master entity index system for a health care organization in accordance with the invention will be described.
As data records from the information sources are fed into the MEI, the MEI may attempt to match the incoming data record about an entity to a data record already located in the MEI database. The matching method will be described in more detail below. If the incoming data record matches an existing data record, a link between the incoming data record and the matching data record may be generated. If the incoming data record does not match any of the existing data records in the MEI, a new entity identifier, as described below, may be generated for the incoming data record. In both cases, the incoming data record may be stored in the MEI. Then as additional data records are received from the information sources, these data records are matched to existing data records and the MEI database of data records is increased.
The one or more control databases 58 may be used by the MEI to control the processing of the data records to increase accuracy. For example, one of the control databases may store rules which may be used to override certain anticipated erroneous conclusions that may normally be generated by the MEI. For example, the operator of the MEI may know by experience that the name of a particular patient is always misspelled in a certain way and provide a rule to force the MEI to associate data records with the known different spellings. The control databases permit the operator to customize the MEI for a particular application or a particular type of information. Thus, for a health care system containing information about a patient, the control databases may contain a rule that the nickname “Bill” is the same as the full name “William.” Therefore, the MEI will determine that data records otherwise identical except for the first name of “Bill” and “William” contain information about the same entity and should be linked together. The MEI will now be described in more detail.
For each of the operations of the MEI, including the synthesis, as described below, the querying and the monitoring, the results of those operations may depend on a trust value that may be associated with each data field in a data record. The trust computation for a data field may vary depending on the characteristics of the data field, such as the date on which that data record containing the field was received, or a quantitative characterization of a level of trust of the information source. For example, a data field containing data that was manually entered may have a lower trust value than a data field with data that was transferred directly from another information source. The trust value for a data field may also affect the probability of the matching of data records. Now, the data store 54 of the master entity index system will be described in more detail.
The MEI may provide other operations that can be constructed from combining the operations listed above For example, an operation to process data records for which it is not known if a data record exists can be constructed by combining the query operation for data records with the add new data record or update existing data record operations. These “composite”operations may lead to better performance than if the operator executed a combination of the basic operations. They also relieve the operator for having to determine the correct sequencing of operations to achieve the desired result.
The data store 54 may include an entity database 56, one or more control databases 58, and an exception occurrence database 90 as described above. The entity database may include a data record database 76 and an identity database 78. The data record database may store the data records or the addresses of the data records in the MEI, as described above, while the associative identity database may store a group of data record identifiers that associate or “link” those data records which contain information about the same entity. The separation of the physical data records from the links between the data records permits more flexibility because a duplicate copy of the data contained in the data record is not required to be present in the identity database. The data record database and the associative database may also be combined if desired.
The identity database represents the combination of data records in the data record database that refer to the same entity. Each entity is assigned an entity identifier. Entity identifiers are based on the concept of “versioned” identification. An entity identifier consists of a base part and a version number. The base part represents a specific entity about which information is being linked. The version number represents a specific combination of data records that provides information about the entity that is known at a specific time. In this example, the data records are shown as squares with the alphabetic identifier of the data record inside, and the entity identifier is shown as the base part followed by a period followed by a version number. For example, “100.1” indicates an entity identifier with 100 as the base part and 1 as the version number. In this example, entity identifier 100.1 links data records A and B, entity identifier 101.1 links data records C, D and E, and entity identifier 100.2 links data records A, B, and R. Now, the details of the control databases will be described.
The one or more control databases 58 may permit the operator of the master entity index system to customize the MEI's processing based on information known to the operator. The control databases shown are merely illustrative and the MEI may have additional control databases which further permit control of the MEI by the operator. The control databases may, for example, include a rules database 80, an exception handling database 82, an anonymous name database 84, a canonical name database 86, and a thresholds database 88.
The rules database may contain links that the operator of the system has determined are certain and should override the logic of the matching of the MEI. For example, the rules database may contain identity rules (i.e., rules which establish that a link exists between two data records) and/or non-identity rules (i.e., rules which establish that no link exists between two data records). In this example, the rules database contains identity rules which are A=B and C=D and a non-identity rule which is Q.notequal.R. These rules force the MEI to establish links between data records or prevent links from being established between data records. For example, the information sources may have four patients, with data records S, T, U, and V respectively, who are all named George Smith and the operator may enter the following nonidentity rules (i.e. S.notequal.T, T.notequal.U, U.notequal.V, V.notequal.S) to keep the data records of the four different entities separate and unlinked by the MEI. The rules in the rules database may be updated, added or deleted by the operator of the master entity index system as needed.
The exception handling database 82 contains one or more exception handling routines that permit the master entity index system to handle data record problems. The exception handling rules within the database may have the form of “condition.fwdarw.action” processing rules. The actions of these rules may be actions that the MEI should automatically take in response to a condition, for example, to request that an individual manually review a data record. An example of an exception handling rule may be, “if duplicate data record.fwdarrow.delete data record” which instructs the MEI to delete a duplicate data record. Another example is, “if different attributes (sex).forwardarrrow.request further review of data record” which instructs the MEI that if there are two data records that appear to relate to the same entity, but the sex of the entity is different for each data record, the MEI should request further review of the data records. In response to this request, an operator may determine that the data records are the same, with an incorrectly typed sex for one of the records and the operator may enter a rule into the rules database that the two data records are linked together despite the difference in the sex attribute. The exception database may have an associated database 90 (described below) which stores the actual exceptions that occur during processing of the input data records.
The anonymous name database 84 permits the MEI to automatically recognize names that should be ignored for purposes of attempting to match two data records. In this example, the anonymous name database may contain “not on file”, “John Doe” and “baby 1” which are names that may be typically assigned by a hospital to a patient when the hospital has not yet determined the name of the patient. As another example, a part not in a warehouse inventory may be referred to as “not on file” until the part may be entered into the database. These anonymous names may be used by the MEI to detect any of the anonymous names or other “filler” data that hold a space, but have no particular meaning in data records and ignore those names when any matching is conducted because a plurality of data records containing the name of “John Doe” should not be linked together simply because they have the same name.
The canonical name database 86 may permit the MEI to associate short-cut data, such as a nickname, with the full data represented by the short-cut data, such as a person's proper name. In this example for a health care organization, the nickname Bill may be associated with William and Fred may be associated with Frederick. This database permits the MEI to link together two data records that are identical except that one data record uses the first name Bill while the second data record uses the first name William. Without this canonical name database, the MEI may not link these two data records together and some of the information about that patient will be lost. The thresholds database 88 permits the thresholds used by the MEI for matching data records, as described below, to be adjustable. For example, an operator may set a high threshold so that only exact data records are matched to each other. A lower threshold may be set so that a data record with fewer matching data fields may be returned to the user in response to a query. The details of the matching method will be described below in more detail.
The exception occurrence database 90 allows the MEI to maintain a record of all of the exceptions that have occurred. The exception occurrence database 90 may store the actual exception conditions that have arisen during processing. For example, the exception occurrence database 90 may contain an entry that represents that entity 100.2 has two data records with different values for the “sex” attribute.
The operator of the MEI may clear the identity database 78 without clearing the data record database 80. Thus, an operator may have the MEI receive a plurality of input data records and generate a plurality of links with a particular matching threshold level, as described below, being used. The operator may then decide to perform a second run through the data using a lower matching threshold level to produce more links, but does not want to delete the data records themselves, and does not want to delete the identity and non-identity rules from the rules database created during the first run through the data. Thus, the operator may delete the identity database, but keep the control databases, and in particular the rules database, for the second run through the data. Now, a method of adding or updating data in the master entity index in accordance with the invention will be described.
For all of the data records stored by the MEI, a record identifier may be used to uniquely identify the entity referred to by that record compared to other data records received from the data source. For example, in data records obtained from a hospital information system, an internally-generated patient identifier may be used as a record identifier, while in data records from a health plan membership database, a social security number can be used as a record identifier. A record identifier differs from an entity identifier because its scope is only the data records from a single data source. For example, if a person in a health plan is also a patient in a particular hospital, then his or her hospital record will have a different record identifier than his or her health plan record. Furthermore, if records from those two data sources happened to have the same record identifier, this would be no indication that the records referred to the same entity.
An additional aspect of the data record database is that one or more timestamps may be recorded along with the data record. The timestamps may indicate when the data record was last changed, indicating when the data record is valid, and when the data record was received from the information source. The timestamps may be used to track changes in a data record which may indicate problems, such as fraud, to the operation of the MEI. The timestamps may be generated whenever a data record is added to the MEI or updated so that the historical changes in the data record may be documented. Additionally, individual attribute values may be associated with status descriptors that describe how the values should be used. For example, an attribute value with an “active” status would be used for identification, an attribute value with an “active/incorrect” status would be used for identification but not presented to the operator as being the correct value (for example, an old address that still occurs in some incoming data records), and a status of inactive/incorrect means that the value should no longer be used for matching but should be maintained to facilitate manual review. Now, a method for querying the MEI in accordance with the invention will be described.
Additional queries may be performed by the MEI. The MEI may be queried about the number of entities in the MEI database and the MEI may respond with the number of entities in the MEI database. The MEI may also be queried about the volatility (e.g., the frequency that the data records change) of the data in the data records using a timestamp indicating the last time and number of times that the data has been changed that may be associated with each data record in the MEI. The volatility of the data may indicate fraud if the data about a particular entity is changing frequently. The MEI may also be queried about the past history of changes of the data in the data records so that, for example, the past addresses for a particular entity may be displayed. Once the queries or matches have been completed, the data is returned to the user in step 138. The MEI may then determine whether there are additional queries to be performed in step 140 and return to step 122 if additional queries are going to be conducted. If there are no additional queries, the method ends. Now, an exception processing method that may be executed by the MEI will be described.
Validation in step 172 may include examining the lengths of the fields or the syntax or character format of the fields, for example, as numeric fields may be required to contain digits in specified formats. Validation may also involve validating codes in the new data record, for example, valid state abbreviations or diagnostic codes. Additional data sets may be involved in the validation process, for example, a data set containing valid customer account numbers. If the validation process fails, in step 178 an exception may be created that indicates that invalid data is received, the exception handling method described above may be performed, and processing of the insert new record operation is complete.
During standardization in step 174, the MEI may process the incoming data record to compute standard representations of certain data items. For example, the incoming data record may contain the first name of “Bill” and the MEI may add a matching field containing “William” into the incoming data record so that the MEI may match data records to William. This standardization prevents the MEI from missing data records due to, for example, nicknames of people. Other kinds of standardization may involve different coding systems for medical procedures or standard representation of street addresses and other geographic locations.
The MEI may then attempt in step 176 to determine if a data record with the same record identifier already exists in the data record database. If the standardized input data has the same record identifier as an existing data record, in step 178 an exception may be created that indicates that two data records with the same record identifier have been received, the exception handling method described above may be performed, and processing of the insert new record operation is complete. If the standardized input data does not have the same record identifier as an existing data record, then the standardized input data may be added into the MEI and a timestamp may be added to the data record in step 180. Then in step 182, the match/link method 210 described below and summarized in
If the standardized input data does have the same record identifier as an existing data record, then the incoming data record is checked in step 194 to see if it contains exactly the same values for data fields as a data record already contained in the data record database. If the standardized input data does not have the same record identifier as an existing data record, in step 199 an exception may be created that indicates that a duplicate data record has been received, the exception handling method described above may be performed, and processing of the update existing data record operation is complete. If the standardized input data contains exactly the same values, then the execution of this operation cannot affect the identity database. As a result, the timestamp of the existing data record may be updated in step 195 to reflect the current time and processing of the operation is completed. If the standardized input data contains different field values than the existing record with the same record identifier, in step 196 the existing record's field values may be updated to be consistent with the values in the standardized input data, and its timestamp may be updated to reflect the current time. Since the data in the existing record has now changed, the impact on the identity database must be computed. To do this, the MEI in step 197 may first remove an entry in the identity database involving the existing record, if such an entry exists. The MEI may then perform a match/link operation in step 198 for the existing records and any other records referred to in the identity database record removed in step 197. These are the records that had been previously recorded in the identity database as referring to the same entity as the existing data record. The match/link operation performs as described in
To perform the match/link operation, in step 212, the MEI may perform the match operation 300 described below and diagrammed in
Once the threshold has been set, in step 306, a plurality of candidates may be retrieved. To select the candidates, the input attributes are divided into combinations of attributes, such as the last name and phone number of the patient, the first name and last name of a patient, and the first name and phone number of the patient. The data records in the MEI database are exactly matched against each combination of attributes to generate a plurality of candidate data records. Determining candidates from several combinations of attributes permits more fault tolerance because a data record may have a misspelled last name, but will still be a candidate because the combination of the first name and the phone number will locate the data record. Thus, a misspelling of one attribute will not prevent the data record from being a candidate. Once the group of candidates has been determined, the confidence level for each candidate data record may be calculated at step 308.
The confidence level may be calculated based on a scoring routine, which may use historical data about a particular attribute, such as a last address. Thus, if the current address and past addresses match a query, the confidence level is higher than that for a data record with the same current address but a different old address. The scoring routine may also give a higher confidence level to information more likely to indicate the same entity, such as a social security number. The scoring routine may add the confidence level for each attribute to generate a confidence level value for a candidate record (match score). Once the confidence levels have been calculated, any data records with confidence levels higher than the threshold level are displayed for the user in step 310. The method of matching attributes to data records within the MEI database has been completed.
As mentioned above, in some cases, it may be desirable to allow data records in MEI to be associated with multiple entities. Examples of such entities may include, but are not limited to, individuals, households, shipping containers, organizations, etc. To facilitate the ability to include data records in multiple distinct entities, particular matching or linking methodologies may be utilized in accordance with the methods and systems of the present invention. Embodiments of these operations may be used to determine data records that refer to the same entity as an input data record and allow these data records to belong to multiple entities.
At step 1730, a process called transitive bucketing may be performed. For the purpose of illustration, transitive bucketing is akin to putting items in a common bucket if there is a definable logical relationship between these items. Note these items may themselves belong to different buckets. For example, suppose a given relation exists between “a” and “b” and between “b” and “c”, then it also exists between “a” and “c”. Transitive relationships may include “is greater than,” “is equal to,” and “is similar to.” In the example of
Referring back to
Entities may then be reconciled at step 1640 using the set of groups. In one embodiment, for each of the groups, it may be determined whether a corresponding entity exists in the data store of MEI. In this case, a corresponding entity may be an entity which comprises at least one of the data records of the group and no data records which are not in the group. If no corresponding entity is found in the data store, an entity corresponding to the group may be created and associated with the data record(s) of the group (e.g. an entity identifier created and the data record(s) of the group associated with the entity identifier). If a corresponding entity is found, and data records of the group which are not associated with the entity identifier for that entity are associated with the entity identifier.
These group entities 1970,1972, and 1974 may be reconciled with other entities in the MEI described above and a set of corresponding entities may be created if they do not already exist as discussed above. For example, it may be determined if an entity which comprises any one of data record “A” 1810a, data record “B” 1810b or data record “C” 1810c and no other data record exists in the MEI. If such an entity exists and is associated with all the data records of the group (in this case, data record “A” 1810a, data record “B” 1810b and data record “C” 1810c), it may be left unaltered. Otherwise, any data records of the group not associated with the entity may then be associated with the entity. If no such entity exists, a new entity associated with data record “A” 1810a, data record “B” 1810b and data record “C” 1810c may be created. For example, if the entity is associated with data record “C” 1810c, data record “A” 1810a and data record “B” 1810b may then be associated with the entity. To continue with the example, it may then be determined if an entity which is associated with any one of data record “C” 1810c, data record “E” 1810e, or data record “F” 1810f and no other data record exists in the MEI. If such an entity exists and is associated with all the data records of the group (in this case, data record “C” 1810c, data record “E” 1810e, and data record “F” 1810f), it may be left unaltered. Otherwise, any data records of the group not associated with the entity may then be associated with the entity. If no such entity exists, a new entity associated with data record “C” 1810c, data record “E” 1810e, and data record “F” 1810f may be created. Assume here that no such entity exists and that therefore a new entity associated with data record “C” 1810c, data record “E” 1810e, and data record “F” 1810f is created. Note that at this point two entities exist where both of the entities are associated with data record “C” 1810c. Continuing with the example, it may be determined if an entity exists in the MEI corresponding to data record “D” 1810d, and if one does not exist, an entity associated with data record “D” 1810d is created.
Embodiments of a system and method for group entity management as described above can relax the constraint that a member record must exist in only one entity and allow for more complex relationship modeling of data records. In some embodiments, rules can be utilized to handle exceptions, perhaps providing an overwrite capability where necessary, facilitating even more flexibility to the modeling of group relationships. Specifically, embodiments of a system and method for group entity management as described above allow for the manipulation of many-to-many relationships as well as the discovery of non-obvious relationships. As described above, this can be done by transitive bucketing in which a bridge member who is associated with more than one bucket can act as a bridge between two or more otherwise non-related member sets.
In the foregoing specification, the invention has been described with reference to specific embodiments. However, it should be understood that the description is by way of example only and is not to be construed in a limiting sense. It is to be further understood, therefore, that numerous changes in the details of the embodiments of this invention and additional embodiments of this invention will be apparent to, and may be made by, persons of ordinary skill in the art having reference to this description. It is contemplated that all such changes and additional embodiments are within the scope of the invention as set forth in the following claims and their legal equivalents.
This application claims priority from U.S. Provisional Application No. 60/920,758, filed Mar. 29, 2007, entitled “METHOD AND SYSTEM FOR MANAGING ENTITIES,” which is fully incorporated by reference herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4531186 | Knapman | Jul 1985 | A |
| 5020019 | Ogawa | May 1991 | A |
| 5134564 | Dunn et al. | Jul 1992 | A |
| 5247437 | Vale et al. | Sep 1993 | A |
| 5321833 | Chang et al. | Jun 1994 | A |
| 5323311 | Fukao et al. | Jun 1994 | A |
| 5333317 | Dann | Jul 1994 | A |
| 5381332 | Wood | Jan 1995 | A |
| 5442782 | Malatesta et al. | Aug 1995 | A |
| 5497486 | Stolfo et al. | Mar 1996 | A |
| 5535322 | Hecht | Jul 1996 | A |
| 5535382 | Ogawa | Jul 1996 | A |
| 5537590 | Amado | Jul 1996 | A |
| 5555409 | Leenstra et al. | Sep 1996 | A |
| 5561794 | Fortier | Oct 1996 | A |
| 5583763 | Atcheson et al. | Dec 1996 | A |
| 5600835 | Garland et al. | Feb 1997 | A |
| 5606690 | Hunter et al. | Feb 1997 | A |
| 5615367 | Bennett et al. | Mar 1997 | A |
| 5640553 | Schultz | Jun 1997 | A |
| 5651108 | Cain et al. | Jul 1997 | A |
| 5675752 | Scott et al. | Oct 1997 | A |
| 5675753 | Hansen et al. | Oct 1997 | A |
| 5694593 | Baclawski | Dec 1997 | A |
| 5694594 | Chang | Dec 1997 | A |
| 5710916 | Barbara et al. | Jan 1998 | A |
| 5734907 | Jarossay et al. | Mar 1998 | A |
| 5765150 | Burrows | Jun 1998 | A |
| 5774661 | Chatterjee | Jun 1998 | A |
| 5774883 | Andersen | Jun 1998 | A |
| 5774887 | Wolff et al. | Jun 1998 | A |
| 5778370 | Emerson | Jul 1998 | A |
| 5787431 | Shaughnessy | Jul 1998 | A |
| 5787470 | DeSimone et al. | Jul 1998 | A |
| 5790173 | Strauss | Aug 1998 | A |
| 5796393 | MacNaughton et al. | Aug 1998 | A |
| 5805702 | Curry | Sep 1998 | A |
| 5809499 | Wong et al. | Sep 1998 | A |
| 5819264 | Palmon et al. | Oct 1998 | A |
| 5835712 | DuFresne | Nov 1998 | A |
| 5835912 | Pet | Nov 1998 | A |
| 5848271 | Caruso et al. | Dec 1998 | A |
| 5859972 | Subramaniam et al. | Jan 1999 | A |
| 5862322 | Anglin et al. | Jan 1999 | A |
| 5862325 | Reed et al. | Jan 1999 | A |
| 5878043 | Casey | Mar 1999 | A |
| 5893074 | Hughes et al. | Apr 1999 | A |
| 5893110 | Weber et al. | Apr 1999 | A |
| 5905496 | Lau et al. | May 1999 | A |
| 5930768 | Hooban | Jul 1999 | A |
| 5960411 | Hartman et al. | Sep 1999 | A |
| 5963915 | Kirsch | Oct 1999 | A |
| 5987422 | Buzsaki | Nov 1999 | A |
| 5991758 | Ellard | Nov 1999 | A |
| 5999937 | Ellard | Dec 1999 | A |
| 6014664 | Fagin et al. | Jan 2000 | A |
| 6016489 | Cavanaugh et al. | Jan 2000 | A |
| 6018733 | Kirsch et al. | Jan 2000 | A |
| 6018742 | Herbert, III | Jan 2000 | A |
| 6026433 | D'Arlach et al. | Feb 2000 | A |
| 6049847 | Vogt et al. | Apr 2000 | A |
| 6067549 | Smalley et al. | May 2000 | A |
| 6069628 | Farry et al. | May 2000 | A |
| 6078325 | Jolissaint et al. | Jun 2000 | A |
| 6108004 | Medl | Aug 2000 | A |
| 6134581 | Ismael et al. | Oct 2000 | A |
| 6185608 | Hon et al. | Feb 2001 | B1 |
| 6223145 | Hearst | Apr 2001 | B1 |
| 6269373 | Apte et al. | Jul 2001 | B1 |
| 6297824 | Hearst et al. | Oct 2001 | B1 |
| 6298478 | Nally et al. | Oct 2001 | B1 |
| 6311190 | Bayer et al. | Oct 2001 | B1 |
| 6327611 | Everingham | Dec 2001 | B1 |
| 6330569 | Baisley et al. | Dec 2001 | B1 |
| 6356931 | Ismael et al. | Mar 2002 | B2 |
| 6374241 | Lamburt et al. | Apr 2002 | B1 |
| 6385600 | McGuinness et al. | May 2002 | B1 |
| 6389429 | Kane et al. | May 2002 | B1 |
| 6446188 | Henderson et al. | Sep 2002 | B1 |
| 6449620 | Draper | Sep 2002 | B1 |
| 6457065 | Rich et al. | Sep 2002 | B1 |
| 6460045 | Aboulnaga et al. | Oct 2002 | B1 |
| 6496793 | Veditz et al. | Dec 2002 | B1 |
| 6502099 | Rampy et al. | Dec 2002 | B1 |
| 6510505 | Burns et al. | Jan 2003 | B1 |
| 6523019 | Borthwick | Feb 2003 | B1 |
| 6529888 | Heckerman et al. | Mar 2003 | B1 |
| 6556983 | Altschuler et al. | Apr 2003 | B1 |
| 6557100 | Knutson | Apr 2003 | B1 |
| 6621505 | Beauchamp et al. | Sep 2003 | B1 |
| 6633878 | Underwood | Oct 2003 | B1 |
| 6633882 | Fayyad et al. | Oct 2003 | B1 |
| 6633992 | Rosen | Oct 2003 | B1 |
| 6647383 | August et al. | Nov 2003 | B1 |
| 6662180 | Aref et al. | Dec 2003 | B1 |
| 6687702 | Vaitheeswaran et al. | Feb 2004 | B2 |
| 6704805 | Acker et al. | Mar 2004 | B1 |
| 6718535 | Underwood | Apr 2004 | B1 |
| 6742003 | Heckerman et al. | May 2004 | B2 |
| 6757708 | Craig et al. | Jun 2004 | B1 |
| 6795793 | Shayegan et al. | Sep 2004 | B2 |
| 6807537 | Thiesson et al. | Oct 2004 | B1 |
| 6842761 | Diamond et al. | Jan 2005 | B2 |
| 6842906 | Bowman-Amuah | Jan 2005 | B1 |
| 6879944 | Tipping et al. | Apr 2005 | B1 |
| 6907422 | Predovic | Jun 2005 | B1 |
| 6912549 | Rotter et al. | Jun 2005 | B2 |
| 6922695 | Skufca et al. | Jul 2005 | B2 |
| 6957186 | Guheen et al. | Oct 2005 | B1 |
| 6990636 | Beauchamp et al. | Jan 2006 | B2 |
| 6996565 | Skufca et al. | Feb 2006 | B2 |
| 7035809 | Miller et al. | Apr 2006 | B2 |
| 7043476 | Robson | May 2006 | B2 |
| 7099857 | Lambert | Aug 2006 | B2 |
| 7143091 | Charnock et al. | Nov 2006 | B2 |
| 7155427 | Prothia | Dec 2006 | B1 |
| 7181459 | Grant et al. | Feb 2007 | B2 |
| 7249131 | Skufca et al. | Jul 2007 | B2 |
| 7330845 | Lee et al. | Feb 2008 | B2 |
| 7487173 | Medicke et al. | Feb 2009 | B2 |
| 7526486 | Cushman, II et al. | Apr 2009 | B2 |
| 7567962 | Chakrabarti et al. | Jul 2009 | B2 |
| 7620647 | Stephens et al. | Nov 2009 | B2 |
| 7627550 | Adams et al. | Dec 2009 | B1 |
| 7685093 | Adams et al. | Mar 2010 | B1 |
| 7698268 | Adams et al. | Apr 2010 | B1 |
| 7788274 | Ionescu | Aug 2010 | B1 |
| 8321383 | Schumacher et al. | Nov 2012 | B2 |
| 8321393 | Adams et al. | Nov 2012 | B2 |
| 20020007284 | Schurenberg et al. | Jan 2002 | A1 |
| 20020073099 | Gilbert et al. | Jun 2002 | A1 |
| 20020080187 | Lawton | Jun 2002 | A1 |
| 20020087599 | Grant et al. | Jul 2002 | A1 |
| 20020095421 | Koskas | Jul 2002 | A1 |
| 20020099694 | Diamond et al. | Jul 2002 | A1 |
| 20020152422 | Sharma et al. | Oct 2002 | A1 |
| 20020156917 | Nye | Oct 2002 | A1 |
| 20020178360 | Wenocur et al. | Nov 2002 | A1 |
| 20030004770 | Miller et al. | Jan 2003 | A1 |
| 20030004771 | Yaung | Jan 2003 | A1 |
| 20030018652 | Heckerman et al. | Jan 2003 | A1 |
| 20030023773 | Lee et al. | Jan 2003 | A1 |
| 20030051063 | Skufca et al. | Mar 2003 | A1 |
| 20030065826 | Skufca et al. | Apr 2003 | A1 |
| 20030065827 | Skufca et al. | Apr 2003 | A1 |
| 20030105825 | Kring et al. | Jun 2003 | A1 |
| 20030120630 | Tunkelang | Jun 2003 | A1 |
| 20030145002 | Kleinberger et al. | Jul 2003 | A1 |
| 20030158850 | Lawrence et al. | Aug 2003 | A1 |
| 20030174179 | Suermondt et al. | Sep 2003 | A1 |
| 20030182101 | Lambert | Sep 2003 | A1 |
| 20030195836 | Hayes et al. | Oct 2003 | A1 |
| 20030195889 | Yao et al. | Oct 2003 | A1 |
| 20030195890 | Oommen | Oct 2003 | A1 |
| 20030220858 | Lam et al. | Nov 2003 | A1 |
| 20030227487 | Hugh | Dec 2003 | A1 |
| 20040107189 | Burdick et al. | Jun 2004 | A1 |
| 20040107205 | Burdick et al. | Jun 2004 | A1 |
| 20040122790 | Walker et al. | Jun 2004 | A1 |
| 20040143477 | Wolff | Jul 2004 | A1 |
| 20040143508 | Bohn et al. | Jul 2004 | A1 |
| 20040181526 | Burdick et al. | Sep 2004 | A1 |
| 20040181554 | Heckerman et al. | Sep 2004 | A1 |
| 20040220926 | Lamkin et al. | Nov 2004 | A1 |
| 20040260694 | Chaudhuri et al. | Dec 2004 | A1 |
| 20050004895 | Schurenberg et al. | Jan 2005 | A1 |
| 20050015381 | Clifford et al. | Jan 2005 | A1 |
| 20050015675 | Kolawa et al. | Jan 2005 | A1 |
| 20050050068 | Vaschillo et al. | Mar 2005 | A1 |
| 20050055345 | Ripley | Mar 2005 | A1 |
| 20050060286 | Hansen et al. | Mar 2005 | A1 |
| 20050071194 | Bormann et al. | Mar 2005 | A1 |
| 20050075917 | Flores et al. | Apr 2005 | A1 |
| 20050114369 | Gould et al. | May 2005 | A1 |
| 20050149522 | Cookson et al. | Jul 2005 | A1 |
| 20050154615 | Rotter et al. | Jul 2005 | A1 |
| 20050210007 | Beres et al. | Sep 2005 | A1 |
| 20050228808 | Mamou et al. | Oct 2005 | A1 |
| 20050240392 | Munro et al. | Oct 2005 | A1 |
| 20050256740 | Kohan et al. | Nov 2005 | A1 |
| 20050256882 | Able et al. | Nov 2005 | A1 |
| 20050273452 | Molloy et al. | Dec 2005 | A1 |
| 20060053151 | Gardner et al. | Mar 2006 | A1 |
| 20060053172 | Gardner et al. | Mar 2006 | A1 |
| 20060053173 | Gardner et al. | Mar 2006 | A1 |
| 20060053382 | Gardner et al. | Mar 2006 | A1 |
| 20060064429 | Yao | Mar 2006 | A1 |
| 20060074832 | Gardner et al. | Apr 2006 | A1 |
| 20060074836 | Gardner et al. | Apr 2006 | A1 |
| 20060080312 | Friedlander et al. | Apr 2006 | A1 |
| 20060116983 | Dettinger et al. | Jun 2006 | A1 |
| 20060117032 | Dettinger et al. | Jun 2006 | A1 |
| 20060129605 | Doshi | Jun 2006 | A1 |
| 20060129971 | Rojer | Jun 2006 | A1 |
| 20060136205 | Song | Jun 2006 | A1 |
| 20060161522 | Dettinger et al. | Jul 2006 | A1 |
| 20060167896 | Kapur et al. | Jul 2006 | A1 |
| 20060179050 | Giang et al. | Aug 2006 | A1 |
| 20060190445 | Risberg et al. | Aug 2006 | A1 |
| 20060195560 | Newport | Aug 2006 | A1 |
| 20060265400 | Fain et al. | Nov 2006 | A1 |
| 20060271401 | Lassetter et al. | Nov 2006 | A1 |
| 20060271549 | Rayback et al. | Nov 2006 | A1 |
| 20060287890 | Stead et al. | Dec 2006 | A1 |
| 20070005567 | Hermansen et al. | Jan 2007 | A1 |
| 20070016450 | Bhora et al. | Jan 2007 | A1 |
| 20070055647 | Mullins et al. | Mar 2007 | A1 |
| 20070067285 | Blume et al. | Mar 2007 | A1 |
| 20070073678 | Scott et al. | Mar 2007 | A1 |
| 20070073745 | Scott et al. | Mar 2007 | A1 |
| 20070094060 | Apps et al. | Apr 2007 | A1 |
| 20070150279 | Gandhi et al. | Jun 2007 | A1 |
| 20070192715 | Kataria et al. | Aug 2007 | A1 |
| 20070198481 | Hogue et al. | Aug 2007 | A1 |
| 20070198600 | Betz | Aug 2007 | A1 |
| 20070214129 | Ture et al. | Sep 2007 | A1 |
| 20070214179 | Hoang | Sep 2007 | A1 |
| 20070217676 | Grauman et al. | Sep 2007 | A1 |
| 20070250487 | Reuther | Oct 2007 | A1 |
| 20070260492 | Feied et al. | Nov 2007 | A1 |
| 20070276844 | Segal et al. | Nov 2007 | A1 |
| 20070276858 | Cushman et al. | Nov 2007 | A1 |
| 20070299697 | Friedlander et al. | Dec 2007 | A1 |
| 20070299842 | Morris et al. | Dec 2007 | A1 |
| 20080005106 | Schumacher et al. | Jan 2008 | A1 |
| 20080016218 | Jones et al. | Jan 2008 | A1 |
| 20080069132 | Ellard et al. | Mar 2008 | A1 |
| 20080120432 | Lamoureaux et al. | May 2008 | A1 |
| 20080126160 | Takuechi et al. | May 2008 | A1 |
| 20080243832 | Adams et al. | Oct 2008 | A1 |
| 20080244008 | Wilkinson et al. | Oct 2008 | A1 |
| 20090089317 | Ford et al. | Apr 2009 | A1 |
| 20090089332 | Harger et al. | Apr 2009 | A1 |
| 20090089630 | Goldenberg et al. | Apr 2009 | A1 |
| 20090198686 | Cushman, II et al. | Aug 2009 | A1 |
| 20100114877 | Adams et al. | May 2010 | A1 |
| 20100174725 | Adams et al. | Jul 2010 | A1 |
| 20100175024 | Schumacher et al. | Jul 2010 | A1 |
| 20110010214 | Carruth | Jan 2011 | A1 |
| 20110010346 | Goldenberg et al. | Jan 2011 | A1 |
| 20110010401 | Adams et al. | Jan 2011 | A1 |
| 20110010728 | Goldenberg et al. | Jan 2011 | A1 |
| 20110047044 | Wright et al. | Feb 2011 | A1 |
| 20110191349 | Ford et al. | Aug 2011 | A1 |
| Number | Date | Country |
|---|---|---|
| 9855947 | Dec 1998 | WO |
| 0159586 | Aug 2001 | WO |
| 0159586 | Aug 2001 | WO |
| 0175679 | Oct 2001 | WO |
| 03021485 | Mar 2003 | WO |
| 2004023297 | Mar 2004 | WO |
| 2004023311 | Mar 2004 | WO |
| 2004023345 | Mar 2004 | WO |
| 2009042931 | Apr 2009 | WO |
| 2009042941 | Apr 2009 | WO |
| Entry |
|---|
| International Search Report and Written Opinion for PCT/US08/58404, Dated Aug. 15, 2008. |
| Fair, “Record Linkage in the National Dose Registry of Canada”, European Journal of Cancer, vol. 3, Supp. 3, pp. S37-S43, XP005058648 ISSN: 0959-8049, Apr. 1997. |
| International Search Report and Written Opinion, for PCT/US2007/012073, Mailed Jul. 23, 2008, 12 pages. |
| International Preliminary Report on Patentability Issued in PCT/US2007/013049, Mailed Dec. 17, 2008. |
| International Search Report and Written Opinion issued in PCT/US2007/013049, mailed Jun. 13, 2008. |
| Office Action issued in U.S. Appl. No. 11/809,792, mailed Aug. 21, 2009, 14 pages. |
| Oracle Date Hubs: “The Emperor Has No Clothes?”, Feb. 21, 2005, Google.com, pp. 1-9. |
| IEEE, no matched results , Jun. 30, 2009, p. 1. |
| IEEE No matched Results, 1 Page, Sep. 11, 2009. |
| Office Action issued in U.S. Appl. No. 11/522,223 dated Aug. 20, 2008, 16 pgs. |
| Office Action issued in U.S. Appl. No. 11/522,223 dated Feb. 5, 2009, Adams, 17 pages. |
| Notice of Allowance issued for U.S. Appl. No. 11/522,223, dated Sep. 17, 2009, 20 pages. |
| De Rose, et al. “Building Structured Web Community Portals: A Top-Down, Compositional, and Incremental Approach”, VDLB, ACM, pp. 399-410, Sep. 2007. |
| Microsoft Dictionary, “normalize”, at p. 20, Fifth Edition, Microsoft Corp., downloaded from http://proquest. safaribooksonline.com/0735614954 on Sep. 8, 2008. |
| Office Action issued in U.S. Appl. No. 11/521,928, dated Apr. 1, 2009, 22 pages. |
| Office Action issued in U.S. Appl. No. 11/521,928 dated Sep. 16, 2008, 14 pages. |
| Notice of Allowance issued for U.S. Appl. No. 11/521,928, dated Sep. 18, 2009, 20 pages. |
| Gopalan Suresh Raj, Modeling Using Session and Entity Beans, Dec. 1998, Web Comucopia, pp. 1-15. |
| Scott W. Ambler, Overcoming Data Design Challenges, Aug. 2001, p. 1-3. |
| XML, JAVA and the future of the Web, Bosak, J., Sun Microsystems, Mar. 10, 1997, pp. 1-9. |
| Integrated Document and Workflow Management applied to Offer Processing a Maching Tool Company, Stefan Morschheuser, et al., Dept. of Information Systems I, COOCS '95 Milpitas CA, ACM 0-89791-706-5/95, p. 106-115. |
| Hamming Distance, HTML. Wikipedia.org, Available: http://en.wikipedia.org/wiki/Hamming—distance (as of May 8, 2008). |
| Office Action issued in U.S. Appl. No. 11/521,946, mailed May 14, 2008, 10 pgs. |
| Office Action issued in U.S. Appl. No. 11/521,946 mailed Dec. 9, 2008, 10 pgs. |
| Office Action issued in U.S. Appl. No. 11/521,946 mailed May 13, 2009, 12 pgs. |
| Freund et al., Statistical Methods, 1993, Academic Press Inc., United Kingdom Edition, pp. 112-117. |
| Waddington, D., “Does it signal convergence of operational and analytic MDM?” retrieved from the internet<URL: http://www.intelligententerprise.com>, 2 pages, Aug. 2006. |
| International Search Report mailed on Oct. 10, 2008, for PCT Application No. PCT/US07/20311 (10 pp). |
| International Search Report and Written Opinion issued in PCT/US07/89211, mailing date of Jun. 20, 2008. |
| International Preliminary Report on Patentability Under Chapter 1 for PCT Application No. PCT/US2008/058665, issued Sep. 29, 2009, mailed Oct. 8, 2009, 6 pgs. |
| International Search Report and Written Opinion mailed on Dec. 3, 2008 for International Patent Application No. PCT/US2008/077985. |
| Gu, Lifang, et al., “Record Linkage: Current Practice and Future Directions,” CSIRO Mathematical and Informational Sciences, 2003, pp. 1-32. |
| O'Hara-Schettino, et al., “Dynamic Navigation in Multiple View Software Specifications and Designs,” Journal of Systems and Software, vol. 41, Issue 2, May 1998, pp. 93-103. |
| International Search Report and Written Opinion mailed on Oct. 10, 2008 for PCT Application No. PCT/US08/68979. |
| International Search Report and Written Opinion mailed on Dec. 2, 2008 for PCT/US2008/077970. |
| Martha E. Fair, et al., “Tutorial on Record Linkage Slides Presentation”, Chapter 12, pp. 457-479. |
| International Search Report and Written Opinion mailed on Aug. 28, 2008 for Application No. PCT/US2008/58665, 7 pgs. |
| C.C. Gotlieb, Oral Interviews with C.C. Gotlieb, Apr. 1992, May 1992, ACM, pp. 1-72. |
| Google.com, no match results, Jun. 30, 2009, p. 1. |
| Supplementary European Search Report for EP 07 79 5659 dated May 18, 2010, 5 pages. |
| European Communication for EP 98928878 (PCT/US9811438) dated Feb. 16, 2006. |
| European Communication for EP 98928878 (PCT/US9811438) dated Mar. 10, 2008. |
| European Communication for EP 98928878 (PCT/US9811438) dated Jun. 26, 2006. |
| Gill, “OX-Link: The Oxford Medical Record Linkage System”, Internet Citation, 1997. |
| Newcombe et al., “The Use of Names for Linking Personal Records”, Journal of the American Statistical Association vol. 87, Dec. 1, 1992, pp. 335-349. |
| European Communication for EP 07795659 (PCT/US2007013049) dated May 27, 2010. |
| Jason Woods, et al., “Baja Identity Hub Configuration Process”, Publicly available on Apr. 2, 2009, Version 1.3. |
| Initiate Systems, Inc. “Refining the Auto-Link Threshold Based Upon Scored Sample”, Publicly available on Apr. 2, 2009; memorandum. |
| Initiate Systems, Inc. “Introduction”, “False-Positive Rale (Auto-Link Threshold)”, Publicly available on Apr. 2, 2009; memorandum. |
| Jason Woods, “Workbench 8.0 Bucket Analysis Tools”, Publicly available on Apr. 2, 2009. |
| “Parsing” Publicly available on Oct. 2, 2008. |
| Initiate, “Business Scenario: Multi-Lingual Algorithm and Hub,” Publicly available on Apr. 2, 2009. |
| Initiate, “Business Scenario: Multi-Lingual & Many-To-Many Entity Solutions”, Publicly available on Apr. 2, 2009. |
| Initiate, “Relationships-MLH”, presentation; Publicly available on Sep. 28, 2007. |
| Initiate, “Multi-Lingual Hub Support viaMemtype Expansion”, Publicly available on Apr. 2, 2009. |
| Initiate Systems, Inc. “Multi-Language Hubs”, memorandum; Publicly available on Apr. 2, 2009. |
| Initiate, “Business Scenario: Support for Members in Multiple Entities”, Publicly available on Oct. 2, 2008. |
| Initiate, “Group Entities”, Publicly available on Mar. 30, 2007. |
| Jim Cushman, MIO 0.5: MIO As a Source; Initiate; Publicly available on Oct. 2, 2008. |
| Initiate, “Provider Registry Functionality”, Publicly available on Oct. 2, 2008. |
| Edward Seabolt, “Requirement Specification Feature #NNNN Multiple Entity Relationship”, Version 0.1-Draft; Publicly available on Oct. 2, 2008. |
| Initiate, “Arriba Training Engine Callouts”, presentation; Publicly available on Mar. 30, 2007. |
| Initiate, “Business Scenario: Callout to Third Party System”, Publicly available on Oct. 2, 2008. |
| John Dorney, “Requirement Specification Feature #NNNN Conditional Governance”, Version 1.0-Draft; Publicly available on Oct. 2, 2008. |
| Initiate, Release Content Specification, Identity Hub Release 6.1, RCS Version 1.0; Publicly available on Sep. 16, 2005. |
| Initiate, “Initiate Identity Hub™ Manager User Manual”, Release 6.1; Publicly available on Sep. 16, 2005, |
| End User Training CMT; CIO Maintenance Tool (CMT) Training Doc; Publicly available on Sep. 29, 2006. |
| “Hierarchy Viewer-OGT 3.0t”, Publicly available on Sep. 25, 2008. |
| “Building and Searching the OGT”, Publicly available on Sep. 29, 2006. |
| Sean Stephens, “Requirement Specification B2B Web Client Architecture”, Version 0.1-Draft; Publicly available on Sep. 25, 2008. |
| “As of OGT 2.0”, Publicly available on Sep. 29, 2006. |
| Initiate, “Memtype Expansion Detailed Design”, Publicly available on Apr. 2, 2009. |
| Initiate, “Java SDK Self-Training Guide”, Release 7.0; Publicly available on Mar. 24, 2006. |
| Ohgaya, Ryosuke et al., “Conceptual Fuzzy Sets-, NAFIPS 2002, Jun. 27-29, 2002, pp. 274-279. Based Navigation System for Yahoo!”. |
| Xue, Gui-Rong et al., “Reinforcing Web-Object Categorization Through Interrelationships”, Data Mining and Knowledge Discover, vol. 12, Apr. 4, 2006, pp. 229-248. |
| Adami, Giordano et al., “Clustering Documents in a Web Directory”, WIDM '03, New Orleans, LA, Nov. 7-8, 2003, pp, 66-73. |
| Chen, Hao et al., “Bringing Order to the Web: Automatically Categorizing Search Results”, CHI 2000, CHI Letters, vol. 2, Issue 1, Apr. 1-6, 2000, pp. 145-152. |
| “Implementation Defined Segments—Exhibit A”, Publicly available on Mar. 20, 2008. |
| Initiate, “Implementation Defined Segments—Gap Analysis”, Publicly available on Mar. 20, 2008. |
| “Supporting Hierarchies”, Publicly available on Nov. 29, 2007. |
| Xue, Gui-Rong et al., “Implicit Link Analysis for Small Web Search”, SIGIR '03, Toronto, Canada, Jul. 28-Aug. 1, 2003, pp. 56-63. |
| Liu, Fang et al., “Personalized Web Search for iMproving Retrieval Effectiveness”, IEEE Transactions on Knowledge and Data Engineering vol. 16, No. 1, Jan. 2004, pp. 28-40. |
| Anyanwu, Kemafor et al. “SemRank: Ranking complex Relationship Search Results on the Semantic Web”, WWW 2005, Chiba, Japan May 10-14, 2005, pp. 117-127. |
| International Preliminary Report on Patentability, PCT/US2008/58404, Mar. 21, 2011, 4 pages. |
| European Search Report/EP07795659.7, Apr. 15, 2011, 7 pages. |
| Emdad Ahmed, “A Survey on Bioinformatics Data and Service Integration Using Ontology and Declaration Workflow Query Language”, Department of Computer Science, Wayne State University, USA, Mar. 15, 2007, pp. 1-67. |
| International Preliminary Report on Patentability, PCT/US2007/89211, Apr. 30, 2012, 6 pages. |
| European Search Report/EP07795108.5, May 29, 2012, 6 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20080243885 A1 | Oct 2008 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60920758 | Mar 2007 | US |
