Abstract:
A method, system, and computer readable medium for evaluating a string input for a name, categorizing the words within the string into different fields, and using the relations to make better or exact hits during a name search possible.

Description:
BACKGROUND  
       [0001]     Searching through databases is becoming more complex as storage capacity is increased and more information can be stored. With databases that contain large amounts of information, particularly about people, the amount of retrievable names can be significant. Furthermore, many people have variations on names, particularly in affixes, that make their names difficult to search. Many people also have similar names or similar surnames. Searching for a common name may lead to a large processing time. In addition, a result list returned to a user may be too large, may not contain variations of certain parts of names, may contain redundant names, or may be inaccurate. The large amount of information in a person&#39;s name, and the various parts to a person&#39;s name, are currently not utilized in helping to narrow the field of search for a name. At the same time, requiring a user to input parts of a person&#39;s name into separate search fields respectively corresponding to those parts may be confusing to a user and requires more time than entering the complete name in a single field. There is also a possibility of human error if part of a name is placed in the wrong field. Thus, a method is needed to increase the number of variables that is searchable without increasing the complexity of the user input. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0002]      FIG. 1  illustrates a possible configuration of a system capable of using an embodiment of the invention.  
         [0003]      FIG. 2   a  illustrates an example lookup table.  
         [0004]      FIG. 2   b  illustrates an example list of the fields in a customizing table.  
         [0005]      FIG. 2   c  illustrates an example description of the fields in a customizing table, including the various types of affixes.  
         [0006]      FIG. 2   d  illustrates an example customizing table.  
         [0007]      FIG. 3  illustrates an example user input box in a user interface.  
         [0008]      FIG. 4  illustrates the example logic that may be performed in order to determine the parts of the name input in the example input box of  FIG. 3  using the example lookup table of  FIG. 2   a  and the example customizing table in  FIG. 2   d.    
         [0009]      FIG. 5  illustrates the general logic that may be used by an embodiment of the system to return a result list given a string, in this example, the string is a name. 
     
    
     DETAILED DESCRIPTION  
       [0010]     In order to decrease the number of entries in a result list from a database search, differentiation between name parts is utilized to get more exact hits. In order to not confuse a user and allow flexibility, rather than presenting a user with multiple fields representing parts of names, a user can enter the name once, and an embodiment parses the name. An embodiment may take permutations of the name and places them into a lookup table. As the embodiment traverses the index of the lookup table, each permutation of the name is checked against a customizing table, which contains a list of all possible affixes in the name database. An affix may be any subpart of a name, e.g., a suffix, prefix, etc. Different parts of the name are found by iterating through a lookup table and determining affix type by searching through a customizing table. One advantage of the procedure performed by the embodiment is to identify all affixes (such as “Dr.”, “Van”, etc.) that are in an input name string. Once this information on the parts of the name is identified, it is used to retrieve names (and any other corresponding information) from the name database. The result list may then be returned to the user. This procedure may be used when the entire name is entered into a single field.  
         [0011]      FIG. 1  illustrates a possible configuration of a system capable of using an embodiment of the invention. A user  100  inputs an employee name  104  into a user interface  105  on a computing device  101 . The computing device  101  takes the input and the embodiment processes the information  106  and communicates with a server  103  over a communication medium  102  to retrieve a result list  108  which is returned to the user  100 . The computing device  101  can be any hardware that has processing or computational capability, such as a laptop, handheld device, etc. The communication medium  102  can be either intranet or internet and over a wireless or wired communication (e.g. ethernet cable). The server  103  can hold database information, and one can distribute the functional modules of an embodiment across one or more server computers  103  as appropriate.  
         [0012]      FIG. 2   a  illustrates an example lookup table. The lookup table is created from an example input string “Dr. Van Muller Baron”. All possible permutations of the name are placed in the lookup table under the heading “Value.” The numbers in the left-most column indicate the index number of all the strings, and the right-most column under the heading “Index” represents the index number to place a marker indicating the next value to be read if the current “value” in that row is found in the customizing table. The marker is the placeholder of an embodiment to allow it to keep track of which “value” is being processed. The “ 0 ” index value means to “exit” the lookup table search, indicating that there are no more values to be processed, or that all the values have been processed. However, any value may be used to indicate that the search can be exited as long as the number is not an index number in the lookup table. The “Index” number indicating the next number is done by determining the index that evaluates a string containing the remaining words that are left if one of the words is found. For example, if the value “Dr.” is found in the customizing table then the corresponding Index is “ 5 ”, meaning that the next value to be processed possibly contains any permutation of the remaining value of “Van Muller Baron.” 
         [0013]      FIG. 2   b  illustrates an example list of the fields in a customizing table. The customizing table contains two fields in this example embodiment, either the “ART” field or a “TITLE” field. The descriptions are also in the figure. The data type indicates the storage type of the fields, and in this example embodiment they are both of type “CHAR” meaning characters. Length in this example would be the number of characters, and in this case the “ART” field is a single character while the “TITLE” may be as long as 15 characters. This is adjustable depending on the information that is found in the customizing table.  
         [0014]      FIG. 2   c  illustrates an example description of fields that may be in a customizing table, including the various types of affixes. For example, the single ‘S’ character is a suffix that represents an “academic title after name,” such as the “M.D.” for a medical doctor or the “Esq.” for esquire that comes after a lawyer&#39;s name. A ‘T’ character represents a prefix indicating that it is an “academic title before name,” such as a “Dr.” string used to indicate those that are medical doctors or doctors of philosophy (a.k.a. a Ph.D. or philosophiae doctor). A user may change the types of characters representing various affixes in the description of fields, as well as in the customizing table.  
         [0015]      FIG. 2   d  illustrates an example customizing table. The customizing table may contain not only affixes that are common in names, but also variations of spelling for the affixes. For example, the suffix “the Second” may appear as “II” or “the 2nd” or “the 2 nd ”. Also, the academic title “MD” for medical doctor may also exist in the customizing table as “M.D.”. The title “Ph.D.” may also be listed as “PhD.” Having variations on affixes allows for an embodiment to account for alternative (or even commonly mistaken) spellings of affixes. All the affixes in the example are listed together in a single customizing table, as shown by the example ART: ‘T’ corresponding to the value “Dr.”  200 , ‘V’ corresponding to the value “Van”  201 , and ‘Z’ corresponding to the value “Baron”  202 . However, a customizing table may also be divided into different tables by affix type.  
         [0016]      FIG. 3  illustrates an example user input box in a user interface. A user interface searching for names will have a single input  300 , rather than multiple inputs. This is because the embodiment will process the name to separate the name into its various parts and then return the result list based on its parsing and search of the name. The example in  FIG. 3  has the name “Dr. Van Muller Baron, Peter Smith.” The embodiment would automatically parse out the First Name, “Peter”, and the Middle Name “Smith” leaving only the various affixes and parts of the Last Name. The lookup table for the remaining string “Dr. Van Muller Baron” is already in the example lookup table provided in  FIG. 2   a.    
         [0017]      FIG. 4  illustrates the example logic that may be performed in order to determine the parts of the name input in the example input box of  FIG. 3  using the example lookup table of  FIG. 2   a  and the example customizing table in  FIG. 2   d . Starting at Step  400  the first value is queried, in this case the value is “Dr. Van Muller Baron.” If “Dr. Van Muller Baron” was in the customizing table  402 , then Step  401  would be executed because the corresponding index is “ 0 ”  401  and the lookup table search would exit  408 , meaning that the parsing and separation of the name into parts has been completed. However, in this example, “Dr. Van Muller Baron” is not in the customizing table and thus the next value is queried  403 . If the value at the next index, “Dr. Van Muller”, was in the customizing table  404 , the corresponding index is “ 10 ”  405 , the marker of the embodiment would be “ 10 ” and the value at “ 10 ” would be the next value searched. However, “Dr. Van Muller” is not found in the customizing table, thus, the next value is queried  409  and the embodiment would search the customizing table for the value “Dr. Van”  410 . If the value “Dr. Van” were found in the customizing table  410 , then the corresponding index would equal “ 8 ”  411 , the marker would be at “ 8 ”, and the value at “ 8 ,” which is “Muller Baron,” would be searched in the customizing table. In this example, “Dr. Van” is also not in the customizing table and the next value is queried  417 . The next value “Dr.” is found in the customizing table  418  as an affix of ART ‘T’  200 . Thus the corresponding index is “ 5 ”  419  and the marker would be at “ 5 ”; however, one can note that even if “Dr.” were not found in the customizing table, the next value searched  421  would have been at index “ 5 ”.  
         [0018]     Since the value “Dr.” has been found, the embodiment now has to determine whether the rest of the name has any particular affix values. Thus the remaining values are essentially all permutations of the original string “Dr. Van Muller Baron” without the string that was already found “Dr.”, leaving all the permutations of the word “Van Muller Baron”. The value “Van Muller Baron” is the value at index “ 5 ” and had it been found in the customizing table  420 , the corresponding index and marker would be “ 0 ”  401  and the search could exit  408 . However, the value “Van Muller Baron” is not in the customizing table, and the next value queried  422  is “Van Muller”, which is also not found in the customizing table. Had “Van Muller” been found  423  then the index would be “ 10 ” and the marker would be placed at “ 10 ”. However, the value “Van Muller” is not in the customizing table and the next value queried  424  is “Van”. The embodiment would query the value “Van” in the customizing table  425  and since it exists as the affix of ART ‘V’, the index would be “ 8 ” and the marker would be “ 8 ”; however, one can again note that even if “Van” were not found in the customizing table, the next value searched  426  would have been at index “ 8 ”.  
         [0019]     The value at index “ 8 ” is “Muller Baron.” If “Muller Baron” were found in the customizing table  412 , the index would be “ 0 ”  401  and the search could exit  408 . However, the value “Muller Baron” is not in the customizing table, and the next value queried  413  is “Muller”, which is also not in the customizing table.  
         [0020]     However, one can note that whether “Muller” is found  414  is irrelevant because had “Muller” been in the customizing table, the marker would have pointed to index “ 10 ”  416 . The next value queried  415  is “Baron.” If “Baron” were not in the customizing table  406 , as it is the last entry the next value in the index  407  is automatically index “ 0 ”  401 , and the search would exist  408 . However, “Baron” does exist in the customizing table as the affix of ART ‘Z’ and the index marker is now “ 0 ”  401  meaning the search exits  408 .  
         [0021]      FIG. 5  illustrates the general logic that may be used by an embodiment of the system to return a result list given a string, in this example, the string is a name. First, an embodiment would retrieve string from an input  500 , similar to that of  FIG. 3 . Next, a lookup table would be created  501 , similar to that of  FIG. 2   a . Next, an embodiment would point a marker to the first index value  502  and then perform a recursive search step on the lookup table. An embodiment would retrieve a value from the index row to which it is pointing  503 . If the current value were in a customizing table  504 , then the relevant field information of that value would be temporarily stored  505 , the marker would be given the number in the corresponding index. If the index was “ 0 ”  507  then the embodiment would exit out of the search. The exit value does not necessarily have to be a “ 0 ”. It need only be a unique identifier that is not an index number that exists in the lookup table.  
         [0022]     If the current value were not in the customizing table, then the marker would be incremented to the next value  508 . If there were not a next index value  509  then the lookup table search would exit, otherwise the next value would be queried  503  and the search would repeat in the remaining values in the lookup table.  
         [0023]     Once the lookup table search is complete, the information stored in step  505  is used to retrieve names from the database  510 . Also, any parts of a name that were not found in the customizing table may by default be listed in the last name field. Of course, the default information may be adjustable depending on the information found in the database or adjustments by a user.  
         [0024]     Since the information stored provides the corresponding fields, each part of the name would not have to be searched in all the fields of a database table. Thus, an advantage of the embodiment is not only to save both the user the hassle of inputting various strings into multiple search fields, but also to save the system resources by reducing the amount of fields of a table searched. For example, if the value “Dr.” is known to be a prefix of ART ‘T’, then only names that contain an academic title before the name would be potential matches. The “Dr.” value would not be searched in the suffix fields of the database. Furthermore, if the ART ‘V’ value “Van” were determined, then this information would only be used to whittle down the remaining names that are possible matches. Thus, among names with “Dr.”, the remaining list would only be names that also contained an aristocratic prefix between the first and second name with the value “Van.” This would continue until all the information is matched with the result list. The result list is provided to the user and the embodiment exits  510 .  
         [0025]     An advantage of an embodiment is that with a reduced list of names found, a user would make less calls to the database for all the information that corresponds to the names returned. Furthermore, the result list may be returned as a list of full names, or the result list can return a list broken down by the various parts of the name. An advantage of the result list is that the information is expandable so that if other search engines have input fields that are broken down by parts of names, the user would have this information.  
         [0026]     Several embodiments of the present invention are specifically illustrated and described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.