FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: CARDINALITY BASED DATA HARMONIZATION
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman Point,
SERVICES LIMITED Maharashtra -400021
India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter is related, in general to data processing in a computing environment and, in particular, to a system and method for cardinality based data harmonization in the computing environment.
BACKGROUND
[0002] Alphabetical data harmonization is one of the major challenging issues of the present times, irrespective of noteworthy advancement in the field of data processing in natural languages. The rapidly growing cultural, racial, and national diversities in the global environment create additional complexities and variations in alphabetical data and their respective spellings, and thus, the efforts to deal with such complexities result in a flurry of matching algorithms comprising rigorous data cleansing, data matching and scoring intelligence.
[0003] At the same time, the emerging need for the connectivity and sorting of people in workplace, social networks, security system, social security database, various business environments ranging from but not limited to banking, universities, etc., trigger not only the wide-spread use of alphabetical data storage, but also various fraudulent activities of such data alteration. Thus the challenge of alphabetical data harmonization is multi-dimensional and inherently complex in nature.
[0004] A significant set of alphabetical data is stored in various repositories like databases, data warehouse, data mart, or flat files, are name data. For such data, the traditional matching algorithm incorporating simple string correlation techniques (e.g., Jaro-Winkler) become inefficient, as not only matching the individual words in the name becomes relevant, but how they permute and appear in order also becomes pertinent. As an example, Rekha John Kumar could easily be altered to Kumar Rekha Jonathan, where the position of words as well as the strings gets altered.
[0005] The earliest attempt to treat such alphabetical data variations, specially the name data variations, was aided by various name-matching optimization techniques based on phonetic algorithms that index words by their pronunciations. The most popular amongst those is the Soundex matching algorithm (developed and patented by Robert C. Russell and

Margaret K. Odell in 1918 and 1922), where names with same pronunciations are encoded to the same string, so that the matches are obtained despite minor intentional or unintentional differences in spelling. Following Soundex, several other name matching algorithms, like NYSIIS algorithm, Daitch-Motokoff Soundex (D–M Soundex) algorithm, etc. have been conventionally devised.
SUMMARY
[0006] This summary is provided to introduce concepts related to cardinality based data harmonization and the concepts are further described below in the detailed description. This summary is neither intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0007] Embodiments of the present subject matter comprise a cardinality-based method and system for indexing, querying and scoring of alphabetical data stored in a computing environment. According to one of embodiments, a cardinality-based query is generated and triggered against the alphabetical data repository, wherein the said query includes a predetermined query logic comprising at least one cardinality element. According to another embodiment, the alphabetical data harmonization system and method perform pre-defined scoring logic on the alphabetical data for generating scores.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The present subject matter and other features and advantages thereof will become apparent and may be better understood from the following drawings. The components of the figures are not necessarily to scales, emphasis instead being placed on better illustration of the underlying principle of the subject matter. Different numeral references on figures designate corresponding elements throughout different views. In the figure(s), the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference number in different figure(s) indicates similar or identical items. However, the manner in which the above depicted features, aspects, and advantages of the present subject matter are accomplished, does not limit the scope of the subject matter, for the subject matter may admit to other equally effective embodiments.

[0009] The detailed description is described with reference to the following accompanying figure(s):
[00010] Fig. 1 illustrates a schematic diagram of the computing environment comprising user devices in communication with the server system over a network, according to one of the embodiments of the present subject matter.
[00011] Fig.2 illustrates details of the server system, referred in Fig. 1, comprising a repository, data input port, a cardinality based query generator and a data harmonization engine, according to one of the embodiments of the present subject matter.
[00012] Fig. 3(a) depicts the details of the repository as referred in Fig. 2, according to one of the embodiments of the present subject matter.
[00013] Fig. 3(b) presents the processing details of the input alphabetical data before it is used for comparison and matching, according to one of the embodiments of the present subject matter.
[00014] Fig. (4)(a), 4(b) and 4(c) show a flow diagram of the method for cardinality based query generation and data matching, according to one of the embodiments of the present subject matter.
[00015] Fig. 5 illustrates an equation depicting fuzzy scoring logic, based on the quantization of matching between the input alphabetical data and alphabetical data stored in the repository, and another equation depicting an example of the abovementioned fuzzy scoring logic in which equal weight distributions to conjugal elements have been assigned, according to one of the embodiments of the present subject matter.
DETAILED DESCRIPTION
[00016] The embodiments of the present subject matter comprise a cardinality-based
system and method for alphabetical data matching between input alphabetical data and stored alphabetical data.
[00017] In the following description, several references and examples are made to the
embodiments of the subject matter. However, it should be emphasized clearly that the subject matter in no manner is restricted by or limited to these specified references or examples of the embodiments. On the contrary, any combination of the following references and examples is

contemplated to implement and practice the present subject matter. Furthermore, in various embodiments the present subject matter provides numerous advantages over the prior art, which are merely illustrative and are not considered elements of limitations for the present subject matter, specifically the claims.
[00018] One embodiment of the subject matter is realized as a product being used in a computing environment. The software programs for such a product may comprise routines and subroutines/source codes written in a computer language to perform cardinality based alphabetical data matching or harmonization, described as an embodiment of the present subject matter. Such a product can be contained on a variety of computer-readable or computer-rewritable media, wherein such media may include, but are not restricted to CD-ROM, DVD-ROM, floppy disks, hard disk drive, diskette drive, or other form of storage media, on which alterable/upgradable information can be stored.
[00019] Fig. 1 depicts an exemplary computing environment 100 for cardinality based data harmonization, according to one of the embodiments of the present subject matter. In the said embodiment, the computing environment 100 comprises a plurality of user devices 101-1, 101-2 ...101-N, collectively referred to as the user devices 101, communicating with a server system 102 over a network 104. The server system 102 and the user device 101 may be implemented as any of a variety of conventional computing devices, including, for example, a desktop personal computer (PC), a notebook or portable computer, a tablet computer, a workstation, a mainframe computer, a mobile computing device, an entertainment device, a computing platform, an internet appliance and similar systems. However, a person skilled in the art will comprehend that the embodiment of the present subject matter are not limited to any particular computing system, architecture or application device, as it may be adapted to take advantage of new computing system and platform as they become accessible.
[00020] The server system 102 is connected to the user device 101 over the network 104 through one or more communication links, for example, via dial-up modem connections, cable links, digital subscriber lines (DSL), wireless or satellite links, or any other suitable form, wherein the network 104 may be a wireless network, a wired network, or any combination thereof. Needless to mention that those skilled in the art will recognize that Fig. 1 illustrates a simplified schematic diagram to highlight the essential features of the present

subject matter and that the computing environment 100 can include varieties of additional components elaborating intricate details which have not shown in Fig. 1.
[00021] Moreover, although the computing environment 100 of Fig. 1 illustrates an example of a user/server or a client/server like architecture, one of ordinary skill in the art will recognize that the embodiments of the present subject matter may be adapted for use in a variety of computing environments, such as standalone systems, distributed systems, embedded systems and the like. As an example, the complete user/server system may be a part of a software application running on a single computer system.
[00022] Fig. 2 exhibits a conceptual illustration of the server system 102, which comprises three main components: a repository 210 of alphabetical data, a data input port 215 to feed the input alphabetical data, and a query engine 260 for alphabetical data harmonization, according to an embodiment of the present subject matter. The server system 102 can further include a computer-readable display (not shown in figure) for displaying.
[00023] The repository 210 of alphabetical data may comprise special indexes to store the data in a structured environment thereby supporting matching of the said stored alphabetical data with the input alphabetical data. Further, the repository 210 may comprise a particular naming database wherein name data is stored as alphabetical data, or may comprise a structured name database with special naming indexes, multiple databases, data mart, data warehouse, or distributed data storage across network. The alphabetical data stored in the repository is also referred to as reference alphabetical data.
[00024] Fig 3(a) illustrates the operational architecture of the repository 210, wherein a flowchart 300 of various functions operational on the alphabetical data, before it is being stored in the repository 210, is illustrated as an example embodiment of the present subject matter. We may further consider the repository 210 to include an indexed naming database 322, wherein indexed name data is stored as alphabetical data.
[00025] The first function, referred in the flowchart 300, which is being operational on the input alphabetical data, (wherein the input alphabetical data may be considered as the name data) is the cleansing 315 of the name data by various cleansing rules, referred to by 316, 317, 318 and 319. No constrains have been imposed on the order of operations of the cleansing rules 316, 317, 318 and 319, which further do not limit the scope of the present subject matter.

The cleansing rules comprise removal of non alphabetical data 316 from the alphabetical data to be stored, wherein such non alphabetical data comprises numeric data like, 0, 1,2, ….9 and special characters like full stop (.), comma (,), hyphen (-), etc., wherein the special characters include country-specific characters like umlaut (¨), acute accent (´)¸ etc. A person skilled in the art will acknowledge that the abovementioned special characters are mere examples of few such special characters and will encompass many other similar special characters.
[00026] The cleansing rules further comprise removal of titles 317 from the name data based on the positional word and cardinality of remaining set of words (like Dr, Miss, Mrs, Mr, Kumar, Kumari, Major, Pandit, Shree, Shreemati, Bai, Devi, DR, MRS, etc), wherein the generic titles include culture-specific, religion-specific, and country-specific titles from different cultural and geographical diversities across the world, and wherein such generic titles, particularly, comprise generic titles with Indian origin. Indeed, a person skilled in the art will understand that the generic titles mentioned here are mere examples and do not exclude other generic titles from the list. Moreover, the repository 210 may comprise an inbuilt artificial intelligence (AI) controller (not shown in figure) configured to retain the generic title if the alphabetical data, specially the name data, contains 2 or less cardinality elements. Few examples of the generic titles are illustrated in Table I below. Needless to mention that a person skilled in the art would understand that the tabular alphabetical data are mere examples of generic titles and are not excluding the scope of the subject matter for other generic titles.

LATE SMT KUM KUMARI MASTER MAJOR
DR MRS MASTER SHAHIB SAHEB KUMAR
MR MISS SHRI KM SAHIB KMR
DEVI DEBI BAI BAAI PANDIT PILOT
USTAD BEGUM BIBI BHAI MAESTRO AL
SHREEMATI SHRIMAN SOW SHREE SRI SIR
AASAAN AMMAVEEDU BABA BADSHAH BABU BAHADUR

CHHATRAPATI
DEWAN DEWANIYA FAUIDAR MAHARAJA MAHARANA
MAHARANI MAHARAO MALIK MIRZA NAWAB NIZAM
PALAIYAKKARAR RAJA RANA RAI
TABLE I
[00027] The terms “cardinality”, “cardinality element” and “cardinality count” have been defined herein for the clarity and better understanding of the present subject matter. In mathematics, the cardinality of a set is a measure of the number of elements in the set. For example, the set S = {1, 2, 9} contains 3 elements, and therefore S has a cardinality of 3. The cardinality count 320 determines the cardinality C of the cleansed alphabetical data. As an example embodiment, the alphabetical data Gabriel Garcia Marquez has Cardinality 3, wherein each of Gabriel, Garcia and Marquez are called Cardinality element.

Variants 1 Variants 2 Variants 3 Variants 4 Pre-defined
MOHAMMAD MOHAMMED MUHAMMAD MOHD MD
GHULAM GULAM GH GH
KHALID KH KH
AHMED ALAHMED AHMED
BANERJI BANERJEE BANDOPADHYAY BANDOPADHYAYA BANERJI
CHATTERJI CHATTERJEE CHATTOPADHYAY CHATTOPADHYAYA CHATTERJI
MUKERJI MUKHERJEE MUKHOPADHYAY MUKHOPADHYAYA MUKERJI
BHATTACHARJI BHATTACHARJEE BHATTACHARYYA BHATTACHARYA BHATTACHARJI
TABLE II
[00028] In another embodiment of the flowchart 300, the name data can further be cleansed by a cleansing rule according to which, generic data cleansing 319 is achieved, wherein culture specific cardinality elements with multiple variants may be mapped to a common predefined cardinality element, as shown in Table II.

[00029] The cleansing 315 of the name data as depicted in Fig. 3(a) further comprises removal of cardinality element comprising singular alphabet 318 from the name data, after which the cleansed name data may be retained in the same field.
[00030] The flowchart 300, being operational on the alphabetical data prior to its storage in the repository 210, further comprises an indexing engine 325, as shown in Fig. 3(a). The indexing engine 325 comprises 3 functionalities, viz. determination of a cardinality C 320 of the cleansed alphabetical data, generation of codes or indices for each cardinality element of the alphabetical data by a coding engine 321 and tabulation 330 of the coded alphabetical data in the repository 210 in a plurality of tables or classes in the indexed naming database 322, wherein such classes or tables possess different cardinality C.
[00031] As described for the indexing engine 325 in the flowchart 300, determination of the cardinality count 320 of the cleansed alphabetical data is performed by counting the cardinality elements present in each alphabetical data. Hereinafter, the alphabetical data may further be standardized or indexed by the coding engine 321, which is configured to generate indices or codes of the cleansed alphabetical data. In an embodiment, such alphabetical data may further comprise name data. Moreover, the coding engine 321 may be implemented as a series of operating instructions or as dedicated hardware, or as a combination thereof, wherein the indices or codes can be created for all of the alphabetical data to be stored in the repository 210 or for a portion of the said data to be stored.
[00032] The coding engine 321 as depicted in Fig. 3(a) may employ various techniques like, but not limited to, vowel replacement, phonetic replacement, etc. and may employ SOUNDEX, METAPHONE, multi-parity soundex, or other techniques or a combination thereof. A person skilled in the art would recognize that the coding of the alphabetical data can be performed in various ways and the present examples mentioned herein are few exhibits of such techniques.
[00033] As an example of various coding techniques configured in the coding engine 321, the multi-parity soundex based logic maps a plurality of cardinality elements to a single unique cardinality element, wherein the cardinality elements may comprise different initial letters belonging to the same multi-parity soundex group. The multi-parity soundex group can be understood as a group containing words having same or similar phonetics. This has been

performed by breaking the consonant groups of soundex technique into more closely related sets, as described below in the Table III, to retrieve the cardinality elements, for example, name data elements, with similar phonetic origin or pronunciations but disparate spellings, from a single query. As an example, Bijay and Vijay may be considered similar. The multi-parity soundex group has been created based on culture-specific grouping, for example, for alphabetical data or name data of Indian origin. Hence, it can be understood that the indexing engine 325 is configured to index the alphabetical data based on a culture-specific phonetic technique, which is explained previously.
[00034] Moreover, the multi-parity soundex technique may comprise string length of five or higher, wherein the code for each cardinality element encompasses leftmost alphabet of the cardinality element of the alphabetical data or the name data, followed by plurality of numerical digits, primarily four or higher. The numerical digits are assigned according to a predetermined multi-parity soundex grouping as depicted in TABLE III.
[00035] Another embodiment of multi-parity soundex is to recognize and code certain alphabet clusters, like DN, GN, KSH, SMR, GY, KHY, etc., that represent a single sound for alphabetical data, for example, in case of the name data of Indian origin.

B, V 1
F, P 2
C, K, S 3
G, J, Y 4
Q, X, Z 5
D, T 6
L 7
M, N 8
R 9
H, Y, W Omitted for non-initial case

A, E, I, O, U
Omitted for non-initial case
TABLE III
[00036] The indexed naming database 322 described in the flowchart 300 of Fig. 3(a) comprises the entire set or subset of the alphabetical data, with pre-defined coding executed by the coding engine 321, or any non-coded data, organized under certain pre-defined tables or classes with particular cardinality C, matching with the cardinality of the coded or non-coded input alphabetical data. More precisely, a person skilled in the art will understand that for alphabetical data with cardinality C = 1,2,3,…m, will be classified or tabulated in m distinct classes or tables, wherein a table assigned for the cardinality p stores coded or non-coded alphabetical data with p cardinality elements.
[00037] As an example of the said tabulation of the stored alphabetical data may comprise attributes like column name, data type name, character length, nulls, etc., wherein tuples may comprise cardinality Count, attribute_left, attribute_left_multi-parity soundex, etc, as illustrated in the indexed naming database 322. However, a person skilled in the art may acknowledge that the suggested table with the attributes and tuples are a mere example and not by any means restrict the scope of the present subject matter.
[00038] As the repository 210 described in Fig. 2 may store new alphabetical data being gathered in the repository, such functionalities may be achieved by triggering and performing batch reconciliation 340 for the new alphabetical data in the repository after certain predefined intervals, as shown in Fig 3(a). According to an implementation, the alphabetical data stored in the repository 210 is also partitioned, wherein the partitioning is mapped to a cardinality C of the alphabetical data in the repository.
[00039] Fig 3(b) illustrates a flowchart 300-2 showing various operations being performed on the input alphabetical data, before it is being provided to the query engine 260 to find harmonization with the stored alphabetical data in the repository 210. The first function referred in the flowchart 300-2 is similar to the cleansing 315 comprising cleansing rules, referred as 316, 317, 318 and 319, which may be performed previously on the alphabetical data to be stored in the repository.

[00040] The cleansed input alphabetical data may further be passed through the indexing engine 325 which comprises 2 functionalities, viz. determination of the cardinality of the cleansed input alphabetical data by a cardinality count 320-1, generation of codes or indices by a coding engine 321-1 for each cardinality element of the input alphabetical data. Moreover, a person skilled in the art will recognize that such operations are similar to the operations being performed on the alphabetical data prior to its storage in the repository.
[00041] Referring back to Fig. 2, illustrated is the query engine 260, generally designated and constructed according to the principles and embodiments of the present subject matter. The query engine 260 comprises three primary components, viz., cardinality-based query generator 220, an alphabetical data search and harmonization engine 250, and a score generator 270 based on the quantization of matching of the input alphabetical data with respect to the alphabetical data stored in the repository. One skilled in the art will identify that the query engine 260 comprises additional components typically encompassed in conventional query engines that are not pertinent to the present subject matter or may even adapt newer components when they become available. As an example, one skilled in the art will recognize that the query engine 260 may include interfaces to receive and distribute information. The query engine 260 may be implemented as a series of operating instructions, or as a dedicated hardware, or as a combination thereof. In one of the embodiments, the query engine 260 may be a dedicated computing system or a distributed computing system. Further, the query engine 260 may be employed as a web search engine for the Internet.
[00042] The query engine 260 is configured to search the data based on a cardinality based query. Fig. 2 illustrates the cardinality based query generator 220 which comprises cardinality based software search routines with inclusion of fuzzy logic. In principle, fuzzy logic is a form of many-valued logic dealing, with the concept of partial truths. Instead of having values limited to 1 or 0 (i.e., true or false) such as with the Boolean systems, fuzzy logic allows truth values that are real values in the closed interval [0 …..1]. Thus, the fuzzy logic can provide values ranging in degree between completely true and completely false.
[00043] The cardinality based query generator 220 employs such concepts of fuzzy logic incorporated in the cardinality based query, wherein the input alphabetical data may have

approximate or partial matching with the stored alphabetical data. Such approximate or partial matching can occur when the input alphabetical data is totally new or if the mismatch is being implemented by accidental, incidental or intentional means. A person skilled in the art will understand the general concepts of such fuzzy logic systems and that the conventional logic will project to Boolean logic system with two terminal values of complete match and complete mismatch between the input alphabetical data and the stored alphabetical data.
[00044] As an example of an embodiment of the cardinality based query generator 220, as illustrated in Fig. 2, it may generate the cardinality based query comprising rotating singular or plurality of cardinality elements of the input alphabetical data, to search for corresponding matching alphabetical data with similar or different cardinalities stored as reference alphabetical data in the repository 210. Further, additional embodiments of the cardinality based query generator 220 may generate the cardinality based query to match for truncated or altered singular or plurality of cardinality elements in the input alphabetical data, while searching for corresponding matching alphabetical data with similar or different cardinalities stored as reference alphabetical data in the repository 210.
[00045] The input alphabetical data may be generated as a consequence of joining plurality of cardinality elements or separation of singular cardinality element into plurality of Cardinality elements. For such scenario, the cardinality based query generator 220 incorporates fuzzy logic to search for harmonization or similarity between the input alphabetical data and the stored alphabetical data wherein the input alphabetical data may result from joining or separating singular or plurality of cardinality elements. Moreover, a person skilled in the art will understand that these functionalities, viz., rotation, alteration, truncation, joining, separation of singular or plurality of cardinality elements to generate the cardinality based query may comprise one or multiple functionalities, wherein no constraints are imposed on the order of such operations.
[00046] As an additional embodiment of the cardinality based query generator 220, the fuzzy logic of the cardinality based query further comprises preserving the first alphabet in each cardinality element of the input alphabetical data followed by sorting alphabetically the remaining alphabets for each cardinality element and further generating a series of search elements with removal of a singular alphabet from the said alphabetically sorted cardinality

element, in case of partial matching of singular or plurality of cardinality elements. However, the sorting of alphabet in the above scenario should not split certain alphabet clusters like DN, GN, KSH, SMR, GY, KHY, etc., that represent a single sound for alphabetical data, for example, for the name data with Indian origin. As described in Fig. 2, the query engine 260 further comprises the alphabetical data search and harmonization engine 250, wherein the cardinality based query may be received from the cardinality based query generator 220. After receiving the cardinality based query, a cardinality based matching technique is selected to determine alphabetical data matching or harmonization between the input and stored data.
[00047] Fig. 4(a), 4(b) and 4(c) depict the conceptual illustration of the flow diagram of a method 401-460 for cardinality based matching for measuring the matching or harmonization between the input and the stored alphabetical data, according to the embodiment of the present subject matter.
[00048] The method in Fig. 4(a), 4(b), and 4(c) may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform particular functions or implement particular abstract data types. The methods depicted by the flow diagrams may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communication network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[00049] The order in which the method in the flow diagrams is described is not
intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method, or alternative methods. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. The method is presently provided for cardinality based matching or harmonization between the input and the stored alphabetical data.

[00050] As shown in Fig. 4(a), 4(b), and 4(c), the method 401-460 for cardinality based matching begins at block 401, wherein the alphabetical data search and harmonization engine 250 receives the cardinality based query with inbuilt fuzzy logic to match with alphabetical data stored in the repository. As second and third steps of the method 401-460 for cardinality based matching, the input alphabetical data and the alphabetical data in the repository, also referred to as reference alphabetical data, and their attributes are obtained at block 402 and block 403, respectively. Further, at block 404, the leftmost cardinality element of the cleansed input alphabetical data, coded or non-coded, may be matched with corresponding leftmost, cleansed, coded or non-coded alphabetical data in the repository 210, thereby producing a set S1 of data. Similarly, the rightmost cardinality element of the cleansed input alphabetical data, coded or non-coded, may be matched with corresponding rightmost, cleansed, coded or non-coded alphabetical data in the repository 210, producing a set S2 of data at block 404.
[00051] Accordingly, a list may be generated with the intersection of set S1 and set S2 at block 404-1, emphasizing the matching of the input alphabetical data with the stored alphabetical data, and it can be checked whether the list generated as a result of intersection of the two sets S1 and S2 is null or not. For non-null intersection of the sets S1 and S2, the method 401-460 generates a complete match and goes to the resultant set A shown as block 405. Moreover, in case the list of intersection of the sets S1 and S2 is null, then as a part of the fuzzy logic, the method 401-460 also searches for alphabetical data in the repository 210 wherein the leftmost cardinality element of the input alphabetical data matches with the rightmost alphabetical data of the repository 210 and vice versa, thereby producing sets S3 and S4, respectively, at block 406. At block 407, it is checked whether an intersection of the sets S3 and S4 is null or not. In a scenario in which a non-null intersection of the sets S3 and S4 is obtained at block 407, a complete match is produced and the method 401-460 goes to the resultant set A at block 405. As an example, “Anand Raj” may be the input alphabetical data wherein the stored alphabetical data may comprise “Raj Anand”.
[00052] However, for a scenario in which either the leftmost or the rightmost cardinality elements of the input alphabetical data matches with only one of the cardinality elements of the stored data, the method 401-460 runs the step at block 407-1, wherein it determines the cardinality C of the input alphabetical data. Hereinafter, the method 401-460 runs in three

parallel steps for cardinality C equal to 1 from block 410 onwards, for cardinality C equal to 2 408 (at step B after block 408), and for cardinality C greater than 2 (at step C after block 409).
[00053] For cardinality C equal to 1, at block 410, the singular cardinality element of the input alphabetical data is matched with the non-leftmost and non-rightmost cardinality elements of the stored alphabetical data with cardinality C greater than 2. If the input data completely matches with any of the cardinality elements of the stored alphabetical data for C greater than 2, a list is being generated in set A at block 405, which is a subset of a resultant set R generated at block 411. The partial matches between the input data and the stored alphabetical data are stored in the resultant set R at block 411. As an example, “Nagarajan” may be the input alphabetical data, wherein the stored alphabetical data may comprise “Swati Nagarajan Subramaniam”.
[00054] For cardinality C equal to 2, the method 401-460 is depicted by Fig. 4(b) continuing from step B, at block 421. At block 422, the sets S1 and S2 are evaluated. If only the leftmost cardinality element of the input data matches with the leftmost cardinality element of the data stored in the repository, determined at block 423, then at block 424, the fuzzy logic of the method 406-410 may search for matching of the rightmost cardinality element of the input data with the non-rightmost cardinality elements of the stored data, wherein the stored data has cardinality C higher than 2. The resultant matches may be stored as set S5A at block 425.
[00055] Further, at block 426 an intersection of set S5A and set S1 may be achieved and it can be checked whether the resultant of the intersection is null or not. For non-null intersection of set S1 and set S5A, the method 401-460 generates the resultant set A, at block 405. As an example, “Sunil Dev” may be the input alphabetical data wherein the stored alphabetical data may comprise “Sunil Dev Barman”. Moreover, for approximate or partial matches of the rightmost cardinality element of the input data with the non-rightmost cardinality element of the stored data, the matches produce a set S5Aw at block 432.
[00056] Further, at block 433, an intersection between set S5Aw and set S1 is obtained and determined whether the result of the intersection is null or not. For a non-null intersection of the sets S1 and S5Aw, the resultant set A is generated at block 405. On the contrary, for a null intersection of set S1 and set S5Aw, at block 437, a set S-weak may be generated, wherein, at

block 438, for all the cardinality elements belonging to S-weak, fuzzy logic of the method 401-460 produces new data from the repository 210 by joining the cardinality elements of the respective stored data. For non-null intersection of such data at block 438, the method 401-460 again generates the resultant set A at block 405. As an example, “Mohammed Shamimuddin” may be the input alphabetical data wherein the stored alphabetical data may comprise “Mohammed Shamim Uddin”.
[00057] For cardinality C equal to 2, if only the rightmost cardinality element of the input data matches with the rightmost cardinality element of the data stored in the repository 210, as shown at block 427, then at block 428, the fuzzy logic of the method 401-460 may search for matching of the leftmost cardinality element of the input data with the non-leftmost cardinality elements of the stored data, wherein the stored data has a cardinality C higher than 2. The resultant matches may be stored as set S6A at block 429. At block 430, an intersection of set S6A and set S2 is obtained and it is determined whether the result of the intersection is null or not. For a non-null intersection of set S1 and set S6A, the method 401-460 generates the resultant set A at block 405. As an example, “Sunil Dev” may be the input alphabetical data wherein the stored alphabetical data may comprise “Niti Sunil Dev”.
[00058] If the rightmost cardinality element of the input data matches with the rightmost cardinality element of the stored data (i.e., the set S2 is not a null set), then for cardinality C equal to 2 of the input alphabetical data, the method 410-460 will generate a set S6Aw at block 435 for partial matches of the leftmost cardinality element of the input alphabetical data with the leftmost cardinality element of the stored data. At block 436, an intersection between set S6A2 and set S2 is determined, and it is also determined whether the intersection results in a null or a non-null set. For a non-null intersection of the sets S2 and S6Aw, the resultant set A is generated at block 405. On the other hand, for null intersection of set S2 and set S6Aw at block 436, a set S-weak may be generated at block 439, wherein for all the cardinality elements belonging to set S-weak, the fuzzy logic of the method produces new data from repository 210 by joining the cardinality elements of the respective stored data at block 440. For non-null intersection of such data at block 440, the method 401-460 again generates a resultant set A at block 405. As an example, “Paramjit Singh” may be the input alphabetical data wherein the stored alphabetical data may comprise “Param Jit Singh”.

[00059] For cardinality C greater than 2 of the input alphabetical data, the method 401-460 is depicted by Fig. 4(c) continuing from block 441 (viz. step C). If the leftmost cardinality element matches with the leftmost Cardinality element of the stored data (i.e., Set S1 is non-null), as shown at block 443, then the fuzzy logic of the method 401-460 may, at block 444, search for matching the non rightmost cardinality element of the input alphabetical data with the rightmost element of the stored data for cardinality C equal to 2 or with the any non-leftmost cardinality element of the stored data for cardinality C greater than 2. The matches, if any, generate a non-null resultant set S7A at block 445. At block 446, an intersection between set S7A and set S1 is achieved to determine whether the result of the intersection is null or not. For a non-null intersection of set S7A with set S1 at block 446, the method 401-460 generates the resultant set A at block 405. As an example, “Asmat Syed Akhtar” may be the input alphabetical data wherein the stored alphabetical data may comprise “Asmat Akhtar Syed”.
[00060] Similarly, for cardinality C greater than 2 of the input alphabetical data, if the rightmost cardinality element matches with the rightmost cardinality element of the stored data (i.e., Set S2 is non-null), as shown at block 452, then at block 453, the fuzzy logic of the method 401-460 may match the non leftmost cardinality element of the input alphabetical data with the leftmost element of the stored data with cardinality C equal to 2 or with the any non-rightmost cardinality element of the stored data for cardinality C greater than 2. At block 454, the matches, if non-null, generate a set S8A, and subsequently, at block 455, an intersection of set S8A and set S2 is achieved and determined whether the intersection results in a null set or not. In case of a non-null intersection of set S8A with set S2, the method 401-460 generates the resultant set A at block 405. As an example, “Karabasappa Khyati Godbole” may be the input alphabetical data wherein the stored alphabetical data may comprise “Khyati Karabasappa Godbole”.
[00061] For cardinality C of the input alphabetical data greater than 2, if the leftmost cardinality element of the input data matches with the leftmost cardinality element of the stored data (i.e., Set S1 is non null), as shown at block 443, wherein, at block 447, the rightmost cardinality element of the input data matches only partially or approximately with the stored data, a set S7Aw may be generated with such partially or approximately matched data at block 448. Further, at block 449, an intersection between set S7Aw and set S1 is

achieved and it is determined whether the intersection between the two sets S7Aw and S1 is null or not. For a non-null intersection of the sets S7Aw and S1, the resultant set A is generated at block 405. On the other hand, for a null intersection of set S7Aw with set S1, a resultant set S-weak may be created at block 450, wherein the fuzzy logic of the method 401-460 may further join the rightmost cardinality element with the non-rightmost and non-leftmost cardinality element of the input data to use as a search element and perform a match at block 451. If such fuzzy logic at block 451 generates a non null set, then the method 401-460 again generates the resultant set A at block 405. As an example, “Nikhil Dev Burman” may be the input alphabetical data wherein the stored alphabetical data may comprise “Nikhil Devburman”.
[00062] For the cardinality C of the input alphabetical data greater than 2, if the rightmost cardinality element of the input data matches with the rightmost cardinality element of the stored data (i.e., Set S2 is non null), as shown at block 452, wherein at block 456, the leftmost cardinality element of the input data matches only partially or approximately with the stored data, a set S8Aw may be generated at block 457 with such partially or approximately matched data. In addition, at block 458 an intersection of set S8Aw and set S2 is obtained and it is determined whether the result of the intersection is null or not. For a non-null intersection of set S7Aw with set S2, the resultant set A is generated at block 405. On the other hand, for null intersection of set S7Aw with set S2, a resultant set S-weak may be created at block 459, wherein the fuzzy logic of the method 401-460 may further join the leftmost cardinality element with the non-leftmost and non-rightmost cardinality element of the input data to use as a search element to perform a match at block 460. If such fuzzy logic generates a non-null set at block 460, then the method 401-460 again generates the resultant set A at block 405. As an example, “Taran Preet Singh” may be the input alphabetical data wherein the stored alphabetical data may comprise “Taranpreet Singh”.
[00063] Referring back to Fig. 2, the query engine 260 further comprises the score generator 270 based on the quantization of data matching of input data with the corresponding data stored in the repository, wherein such input data may further incorporate first level intelligence brought by the multi-parity soundex with prior factorization of the fuzziness in the actual cardinality element for coded data.

[00064] Equation (1), employed as part of the scoring logic is illustrated in Fig. 5, which is being performed on the resultant set A or the resultant set R generated by the method 401-460 for cardinality based data matching, wherein set A is a subset of set R. Equation (1) in particular refers to an algebraic addition of two arbitrarily weighed fuzzy components, wherein each component projects the similarity of leftmost or rightmost cardinality element of the input data with the data stored in the repository 210. The contribution of the leftmost and the rightmost cardinality elements in obtaining a score from the score generator are depicted by the two elements 510 and 520 that form a part of equation (1).As described above, such “normalized weightage factor” adoption (the weightage factors referred to as “a” and “b” in equation (1)), within the score generator 270, is implemented by considering the conjugal impact of the leftmost and rightmost cardinality elements. However, a scenario may further be considered as simplification of the scoring logic, wherein asymmetric weight distribution with non-equal weightage factors “a” and “b” may be replaced by symmetric, equal weight distribution of the two components, as an example embodiment of the present subject matter as illustrated in equation (2) (referring to the sum of the elements 530 and 540).
[00065] Further, each component as described in equation (1) comprises a sub component depicting partial matching of the input data (“a′” and “b′”), wherein such partial representation goes through an additional arbitrary weight-factor scaling process (referring to “a′” and “b′” being attached to partial leftmost and partial rightmost cardinality element, respectively, in equation (1)), which depicts a “factor of propensity” for the partial match. A person skilled in the art will understand that by partial matching, one recognizes matching of plurality of alphabets in a singular cardinality element with or without similar order of appearance in the said data, wherein the exact matching of the said data is deficient. Moreover, as an embodiment of the scoring logic, one can further assign equal weightage as 0.5 to the factors of propensity, viz. a′, and b′, as illustrated in equation (2) of Fig. 5.
(Nomenclature implemented in Equation (1) and (2): LW_exact and LW_partial refer to exact matching and partial matching of the leftmost cardinality element of the input data, respectively. Similar nomenclatures have been used for the rightmost cardinality elements also. Moreover, the LW_weak and the RW_weak matching will further generate null value, wherein a person skilled in the art will gather that the matching of the cardinality elements will be weak if it is neither exact nor partial.)

S = ([LW_exact + (LW_partial x a′ )] x a) + ([RW_exact + (RW_partial x b′ )] x b) …..(1)
Snum = {([LW_exact + (LW_partial x 0.5)] x 0.5) + ([RW_exact + (RW_partial x 0.5)] x 0.5)} …..(2)
[00066] Thus, the exact matching of the leftmost cardinality element and the rightmost cardinality element of the input data will generate maximum score of 1, wherein the score generator 270 may further implement two pre-determined, arbitrary threshold scores lower than the maximum score, hereinafter referred as score 1 and score 2. Based on such scoring logic, an intermediate matching and ranking of the input alphabetical data with the stored data at various intermediate stages of the method for cardinality based data matching may be performed, which in turn may generate scores for each intermediate ranking based on the quantization of matching. Such a scoring process may be performed at each subsequent level of the pre-determined fuzzy logic, in accordance with the method, until either the final score is generated or a score achieved is higher than the pre-defined threshold scores.
[00067] As an example of the scoring logic, one can further consider equation (2), where simplified, equal weightage normalized factors have been implemented with values of 0.5 of the factors of propensity, viz. a′, and b′, as illustrated in equation (2) of Fig. 5, and wherein the threshold scores score1 and score2 may be considered to be 0.75 and 0.5, respectively. In such a scenario, resultant score above the threshold score score1 will be achieved for exact match of either the leftmost or the rightmost cardinality element and the partial match of the other cardinality element. For partial match of both the leftmost and rightmost cardinality elements or exact match of one of the cardinality element and weak match or no match of the other cardinality element, resultant score will generate the value 0.5, which may be considered the other threshold score score2. For weak match of both the leftmost and rightmost cardinality elements, the resultant score will generate score lower than the lower threshold score score2, wherein such score will have a value of less than 0.5, as depicted in the example embodiment of the present subject matter.
[00068] As an additional embodiment of the present subject matter, the score generator 270 may further comprise sorting of the final score into plurality of categories, for example, three categories, based on the range between the maximum score (S = 1) and the threshold score

score1, between the threshold score score1 and threshold score score2, and below the threshold score score2. Moreover, such a categorization may create bucketing of the resultant complete matched, partially matched and weakly matched data into three corresponding lists, wherein the matches with scores in the range between the maximum, or 100 base point score, and the threshold score score1 may be included in a potential list. A reference list may be created with scores in the range between the two threshold scores score1 and score2, wherein scores below score2 may be bucketed in the weakly matched list. Moreover, a person skilled in the art will understand that although the abovementioned scoring logic is directed to embodiments of the present subject matter, other and further embodiments related to scoring logic may be devised without departing from the basic scope of the representation of the matched, unmatched, and partially or approximately matched data.
[00069] The present subject matter, therefore, provides an augmented cardinality based method and system of alphabetical data matching or harmonizing, which implements fuzzy logic to allow finding information using incomplete, misspelled, accidental, intentional or incidental mistakes or restructured forms of information. The present subject matter may be used for data cleaning or to ensure data quality (DQ). The present subject matter may also be used to search multiple repositories, databases of information for data elements, and return partially matched or approximately matched data. This can be advantageous in searching legacy databases of different systems. For example, consider the multiple databases of various police groups, the Passport Services, the Central Bureau of Investigation (CBI) in India, Secret Service, etc. In such databases, the method as described by the present subject matter may be used for fraud detection wherein the alphabetical data are name data, and look for frauds or leads in various crimes, terrorism, threats, etc.
[00070] It is to mention at this juncture that although the present subject matter has been described to its fullest extent. Those skilled in the art should understand that they can make various changes, substitutions and alteration herein, without departing from the crux of the subject matter in its broadest form.

I/We Claim:
1. A computer implemented method for alphabetical data matching, the method
comprising:
receiving input alphabetical data with at least one cardinality element;
generating a cardinality based query comprising a pre-determined logic based on the input alphabetical data;
triggering the cardinality based query for the input alphabetical data to be matched with reference alphabetical data stored in a repository (210); and
generating scores based on a pre-determined scoring logic, wherein the generating is further based on matching between the input alphabetical data and the reference alphabetical data.
2. The computer implemented method for alphabetical data matching as claimed in claim 1, wherein the input alphabetical data and the reference alphabetical data further comprise name data with indexing based on a culture-specific phonetic technique.
3. The computer implemented method for alphabetical data matching as claimed in claim 1, further comprising cleansing rules of the input alphabetical data and the reference alphabetical data, wherein the input alphabetical data and the reference alphabetical data comprise a name data, and wherein cleansing rules for the name data comprises:
removing non-alphabetical characters from the name data;
removing culture-specific title from the name data, wherein the culture specific title comprises one of a title of Indian origin and a generic title;
removing of singular alphabet as the cardinality element from the name data; and cleansing of culture-specific generic cardinality elements from the name data.
4. The computer implemented method for alphabetical data matching as claimed in claim 1, further comprises partitioning of the reference alphabetical data stored in the repository (210), wherein the partitioning is mapped to a cardinality (C) of the reference alphabetical data.
5. The computer implemented method for alphabetical data matching as claimed in claim 1 wherein the cardinality based query comprises:

performing rotation of the at least one cardinality element of the said input alphabetical data; and
searching for corresponding matching data from the reference alphabetical data in the repository (210).
6. The computer implemented method for alphabetical data matching as claimed in claim 1
wherein the cardinality based query comprises:
performing separation of the at least one cardinality element of the input alphabetical data; and
searching for corresponding matching data from the reference alphabetical data in the repository (210).
7. The computer implemented method for alphabetical data matching as claimed in claim 1
wherein the cardinality based query comprises:
performing joining of the at least one cardinality element of the input alphabetical data; and
searching for corresponding matching data from the reference alphabetical data in the repository (210).
8. The computer implemented method for alphabetical data matching as claimed in claim 1
wherein the pre-determined logic for generating the cardinality based query comprises:
performing truncation of the at least one cardinality element of the input alphabetical data; and
searching for corresponding matching data from the reference alphabetical data in the repository (210).
9. The computer implemented method for alphabetical data matching as claimed in claim 1
wherein the cardinality based query comprises:
performing a set of combination of operations comprising rotation, separation, joining and truncation of the at least one cardinality element of the said input alphabetical data, wherein an order of operations is arbitrary; and
searching for corresponding matching data from the reference alphabetical data in the repository (210).
10. The computer implemented method for alphabetical data matching as claimed in claim 1
wherein the cardinality based query comprises:

preserving first alphabet in the at least one cardinality element of the input alphabetical data;
sorting, alphabetically, remaining alphabets in the at least one cardinality element, wherein the sorting comprises excluding alphabet groups being considered as unified element in multi-parity soundex technique; and
generating a series of search elements by removal of one of a singular alphabet and the alphabet group being considered as unified element in multi-parity soundex technique from the alphabetically sorted alphabets in the at least one cardinality element in case of a partial matching of the at least one cardinality element.
11. The computer implemented method for alphabetical data matching as claimed in claim
I, wherein the pre-determined scoring logic comprises:
pre-determining a threshold score score1 lower than a maximum score and predetermining at least one additional threshold score score2 lower than score1;
matching and ranking, intermediately, the input alphabetical data with the reference alphabetical data stored in a repository (210) to generate scores for each intermediate ranking based on a percentage of matching, wherein the scores are further based on the maximum score, the threshold score score1, and the additional threshold score score2;
performing a subsequent level of the cardinality based query comprising the predetermined logic until one of a final score is generated or a score above threshold score score1 is achieved; and
sorting the final score in plurality of categories.
12. The computer implemented method for alphabetical data matching as claimed in claim
II, wherein the pre-determined scoring logic further comprises:
creating a potential list of matching alphabetical data from the reference alphabetical data, wherein the potential list comprises final scores ranging between 100 base point score and the threshold score score1; and
creating a reference list of matching alphabetical data from the reference alphabetical data, wherein the reference list comprises final scores between the threshold score score1 and the threshold score score2.

13. A computer implemented server system (102) for alphabetical data matching, the server
system (102) comprising:
a repository (210) for storing alphabetical data with at least one cardinality element;
a data input port (215) for an user to input alphabetical data to the server system (102);
a query engine (260) coupled to the repository (210) for generating a query based on a pre-determined fuzzy logic for matching the input alphabetical data with the stored alphabetical data;
a score generator (270) coupled to the query engine (260) to generate a score based on the matching; and
a computer-readable display for displaying the score.
14. The computer implemented server system (102) as claimed in claim 13, wherein the repository (210) is indexed.
15. The computer implemented server system (102) as claimed in claim 13 wherein the query engine (260) comprises:
fuzzy logic comprising rotation of at least one cardinality element of the input alphabetical data;
fuzzy logic comprising separation of the at least one cardinality element of the input alphabetical data;
fuzzy logic comprising joining of the at least one cardinality element of the input alphabetical data;
fuzzy logic comprising truncation of the at least one cardinality element of the input alphabetical data;
fuzzy logic comprising combination of rotation, separation, joining, truncation of the at least one cardinality element of the input alphabetical data;
fuzzy logic comprising alphabetical sorting of the at least one cardinality element of the input alphabetical data; and
fuzzy logic comprising generating a set of variants with removal of one or more alphabets from the at least one cardinality element after the alphabetical sorting of the input alphabetical data.

16. The computer implemented system as claimed in claim 13 wherein the computer
readable display for the search results is configured to:
displaying a potential list comprising one of an exact match and final scores above a threshold score score1; and
displaying a reference list comprising the final scores between the threshold score score1 and a threshold score score2.
17. A computer-readable medium having embodied thereon a computer program for
executing a method comprising:
receiving an input alphabetical data with at least one cardinality element;
generating a cardinality based query comprising a pre-determined logic based on the input alphabetical data;
triggering the cardinality based query for the input alphabetical data to be matched with reference alphabetical data stored in a repository (210); and
generating scores based on a pre-determined scoring logic, wherein the generating is further based on matching between the input alphabetical data and the reference alphabetical data.