Patent Description:
A difficult problem in data processing arises when requests identifying items in a complex list, such as a catalog of products of contact lens manufacturers and distributors, are presented in various forms, while the identification of the item in the list must be exact. In such systems, human error or variability can result in requests that fail to unambiguously match an item in the list. The problem is addressed typically by training of the human data entry personnel. However, as the catalog of products evolves, constant training is required.

In some environments, the items in the catalog may be identified by the data entry personnel in different ways. For example, in a system used to support sales of contact lenses, the data entry personnel are trained to utilize product identifiers that may be developed locally, and which do not match corresponding identifiers of the items in the catalog. In these systems, training of the data entry personnel is important as well. But further difficulty arises when the catalog changes and the product identifiers used at the data entry point may not change according to the catalog.

<CIT> discloses a first keyword-to-image (keyword/image) mapping table. The first keyword mapping table includes a number of entries, each entry mapping a keyword to one or more image identifiers (IDs) identifying one or more images. For each of the keywords of the first keyword/image mapping table, an analysis is performed on the keyword to determine one or more related keywords that are related to the keyword. One or more additional entries corresponding to the one or more related keywords are generated to be incorporated into the first keyword/image mapping table to generate a second keyword/image mapping table. The second keyword/image mapping table is utilized to associated a particular image to a particular content item related to a particular keyword.

<CIT> discloses a method and system unifying existing data of a target industry from existing sources of the data by designing a data model by applying varying data integrity methods to define characteristics, features and/or functions of items in the target industry as data elements, electronically reading, parsing and transforming data from existing electronic data sources of the target industry to input to the data model, designing user interfaces to the data model, the user interfaces corresponding to user segments of the target industry, and dynamically maintaining normalization of the data model according to the varying data integrity methods during any type of access to the data model by the user segments. A data entry access to the data model comprises dynamically constructing search indexes, each search index defined as a unique data field and a text searchable concatenation of other fields' data in any given data table of the data model.

<CIT> discloses a classifier used to receive, via a website, user input associated with a product search of a user, and may be further used to identify a plurality of filters associated with the product search and predict a user-specific subset of the plurality of filters. Then, a filter manager used to provide a webpage of the website to the user, based on the user-specific filter subset.

<CIT> discloses a process for sorting results returned in response to a search query according to learned associations between one or more prior search query search terms and selected results of said prior search queries.

The variabilities caused by combination of the above issues: different local representations of the items, human error of data entry personnel and continuously evolving catalog entries, results in a significant number of incorrectly matched items in the catalog.

It is desirable to provide a data matching solution that can more effectively and automatically match the local variations of the data items with specific representations of corresponding data items in the catalog.

A system and method is provided that can be used for operating a data matching system having a plurality of clients and a master catalog. The data matching system processes input requests from requesting clients. Each input request includes a request field that stores an input variant of a data element and a plurality of additional data fields to identify a requested entry in the master catalog. The master catalog includes entries having multiple fields including one search field storing a specific variant of the data element in the request field of input requests. The data matching system maintains client matching tables for a respective client. The entries in client matching tables match the input variants of data elements in the request field with a specific variant of the data element in the search field of a set of entries in the master catalog.

The matching system in embodiments described herein classifies a client in one of the two states: a learning phase and a post-learning phase. When the requesting client is in the learning phase, the data matching system performs a first procedure. In the first procedure, the data matching system searches plural sets of entries in the master catalog having different variants of the data element in the search field for a specific entry that matches the plurality of additional fields of current input request. The data matching system builds a client matching table in the learning phase by adding entries to the client matching table of the request client that match the input variant of the data element in the request field of the current input request with the specific variant of data element in the master search field of the set of entries of which the specific entry is a member.

The searching of the plural set of entries in the master catalog includes a two-step process. In one embodiment, the first step of the two-step process includes finding plural sets of entries in the master catalog by matching the input variant of a data element in the request field of the input requests with the specific variants of the data element in the search fields of entries in the master catalog within a similarity parameter. The process generates a confidence score for each set of the plural set of entries based on recorded data for other input requests for the particular requesting client. This matching includes matching the plurality of additional fields of one other input request to the plurality of additional fields of an entry of the set of entries. The resulting confidence score for a set of entries in the master catalog identifies a percentage of the other input requests in the recorded set that match with entries in that set. Finally, a single set of entries in the master catalog with the highest confidence score is selected and further searched for a specific entry that matches the plurality of the additional fields of the current input request.

When the requesting client is in a second state (post-learning phase), the data matching system uses a second procedure to match the current input request with a specific entry in the master catalog. In the second procedure, the data matching system uses the client matching table of the requesting client to match the current input request with a matched set of entries in the master catalog. Following this, the data matching system searches the matched set of entries for a specific entry that matches the plurality of additional fields of the current input request. Finally, the data matching system generates a response to the current input request identifying the specific entry in the matched set of entries. When the client matching table does not include a match for the current input request, the data matching system uses the first procedure described above.

Embodiments of the technology described herein, or elements thereof, can be implemented in the form of a computer product including a non-transitory computer-readable storage medium with the computer usable program code for performing the method steps indicated. Furthermore, embodiments of the invention or elements thereof can be implemented in the form of an apparatus including a memory and at least one processor that is coupled to the memory and operative to perform exemplary method steps. Yet further, in another aspect, embodiments of the invention or elements thereof can be implemented in the form of means for carrying out one or more of the procedures described herein.

A system for matching an input request from a client to a specific entry in the master catalog <NUM> is described, where the entries in the master catalog are complex product identifiers with many identifying fields that may not match precisely with parameters of an input request. In a configuration described herein, the system includes a first means for executing a search that has a broader scope in the master catalog for the specific entry while building the client matching table <NUM> using the result of the search. Elements <NUM>, <NUM>, and <NUM> of flowchart <NUM> in <FIG> correspond with, and are an example of, this first means, with details of implementation of these elements presented throughout the description. The first means can include resources to execute a two-step match process as described above. The system includes a second means for executing a search that has a more narrow scope in the master catalog using the client matching table <NUM> once it has been built to a suitable degree. Elements <NUM> and <NUM> in <FIG> correspond with, and are an example of, this second means with details of implementation of these elements presented throughout in the description.

Other aspects and advantages of the present invention can be seen on review of the drawings, the detailed description and the claims, which follow.

The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements.

A system and various implementations for catalog matching are described with reference to <FIG>. The system and processes are described with reference to <FIG>, an architectural level schematic of a system in accordance with an implementation. Because <FIG> is an architectural diagram, certain details are intentionally omitted to improve the clarity of the description.

The discussion of <FIG> is organized as follows. First, the elements of the figure are described, followed by their interconnections. Then, the use of the elements in the system is described in greater detail.

<FIG> provides a block diagram level illustration of a system <NUM>. The system <NUM> includes clients <NUM>, network nodes hosting input request extractors 112a, 112b, and 112n, a data synchronization service (DSS) <NUM>, a data matching system <NUM> deployed in a network node (or nodes) <NUM> on the network, an input requests database <NUM>, a client matching tables database <NUM>, a master catalog database <NUM>, order fulfillment services <NUM>, and public network(s) <NUM>.

As used herein, a network node is an active electronic device or virtual device that is attached to a network, and is capable of sending, receiving, or forwarding information over a communications channel. Examples of electronic devices which can be deployed as hardware network nodes include all varieties of computers, workstations, laptop computers, handheld computers, and smartphones. Network nodes can be implemented in a cloud-based server system. More than one virtual device configured as a network node can be implemented using a single physical device.

For the sake of clarity, only three network nodes hosting input request extractors are shown in the system <NUM>. However, any number of network nodes hosting input request extractors can be connected to the DSS <NUM> through the network(s) <NUM>.

The interconnection of the elements of system <NUM> will now be described. Network(s) <NUM> couples the network nodes hosting input request extractors 112a, 112b, and 112n, the DSS <NUM>, the network node <NUM> hosting the data matching system <NUM>, the input requests database <NUM>, the client matching tables database <NUM>, the master catalog database <NUM>, and the order fulfillment services <NUM>. Clients <NUM> are connected to the DSS <NUM> through network nodes hosting input request extractors 112a, 112b, and 112n. In one embodiment, each client <NUM> is a computer platform enabling user input to create requests located for example in an eye care practice office. Eye care practice offices can use a practice management system (PMS) to manage their patient related data including prescriptions. Examples of PMS include, Crystal Practice Management™, OfficeMate™, Visionpro POS™. The PMS is installed in a typical configuration on a local server in an eye care practice office. Data entry personnel in the client <NUM> connect to the client's PMS using a variety of computing devices listed above. In one embodiment, an input request extractor 112a is deployed on the same server as the one on which the PMS is deployed. In such an embodiment, one input request extractor is deployed for one eye care practice office. One or more data entry personnel in an eye care practice office connect to the PMS to enter the patient prescription information. This data is stored in a database of the PMS.

In another embodiment, the PMS can be implemented as a Software-as-a-Service (SaaS) application, a web-architected application or a cloud-delivered service. Examples of SaaS PMS applications include Revolution EHR™, Eyecare Advantage™, Integrity EMR for Eyes™, and Eyecom3™. SaaS applications provide functionalities to users that are implemented in the cloud, and that are the target of policies, e.g., logging in, editing user information, updating whitelists, deleting contacts from the contact list, in contrast to the offerings of simple websites and e-commerce sites. Note that a SaaS application can be supported by both web browser clients and application clients that use URL-based APIs (application programming interfaces). In such an embodiment, the DSS <NUM> connects to a SaaS PMS application through a specialized API for that SaaS PMS. Further details of this embodiment are depicted in <FIG>.

The DSS <NUM> stores input requests received from the network nodes hosting input request extractors 112a, 112b, and 112n in the input requests database <NUM>. The DSS maintains a separate input requests database <NUM> for each client <NUM>. The data matching system <NUM> receives input requests from a requesting client <NUM> via the DSS <NUM> and processes the input requests into a format used to match with a specific record in the master catalog <NUM>.

During processing of the input requests from a client <NUM>, the data matching system <NUM> builds a client matching table for the client <NUM> and stores it in client matching tables database <NUM>. A separate client matching table is maintained for each client <NUM>.

The input requests processed and resolved to a specific entry in the master catalog by the data matching system <NUM> are sent to order fulfillment services <NUM> for further processing.

The actual communication path through the internet can be point-to-point over public and/or private networks. The communications can occur over a variety of networks <NUM>, e.g., private networks, VPN, MPLS circuit, or Internet, and can use appropriate application programming interfaces (APIs) and data interchange formats, e.g., Representational State Transfer (REST), JavaScript™ Object Notation (JSON), Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Java™ Message Service (JMS), and/or Java Platform Module System. All of the communications can be encrypted. The communication is generally over a network such as the LAN (local area network), WAN (wide area network), telephone network (Public Switched Telephone Network (PSTN), Session Initiation Protocol (SIP), wireless network, point-to-point network, star network, token ring network, hub network, Internet, inclusive of the mobile Internet, via protocols such as EDGE, <NUM>, <NUM> LTE, Wi-Fi, and WiMAX. Additionally, a variety of authorization and authentication techniques, such as username/password, Open Authorization (OAuth), Kerberos, SecureID, digital certificates and more, can be used to secure the communications.

The technology disclosed herein can be implemented in the context of any computer-implemented system including a database system, a multi-tenant environment, or a relational database implementation like an Oracle™ compatible database implementation, an IBM DB2 Enterprise Server™ compatible relational database implementation, a MySQL™ or PostgreSQL™ compatible relational database implementation or a Microsoft SQL Server™ compatible relational database implementation or a NoSQL™ non-relational database implementation such as a Vampire™ compatible non-relational database implementation, an Apache Cassandra™ compatible non-relational database implementation, a BigTable™ compatible non-relational database implementation or an HBase™ or DynamoDB™ compatible non-relational database implementation. In addition, the technology disclosed can be implemented using different programming models like MapReduce™, bulk synchronous programming, MPI primitives, etc. or different scalable batch and stream management systems like Apache Storm™, Apache Spark™, Apache Kafka™, Apache Plink™, Truviso™, Amazon Elasticsearch Service™, Amazon Web Services™ (AWS), IBM Info-Sphere™, Borealis™, and Yahoo! S4™.

Modules of an embodiment of a data matching system, usable as system <NUM> of <FIG>, are shown in <FIG>. The data synchronization service DSS <NUM> includes a receive order module <NUM>, a request order module <NUM> and a normalizer <NUM>. The receive order module receives input requests from network nodes hosting input request extractors 112a, 112b, and 112n. The input request extractors are configured in some systems to send the input requests to the DSS periodically at regular intervals. The DSS <NUM> can also proactively connect to network nodes hosting input request extractors 112a, 112b, and 112n using request order module <NUM> to collect input requests. The DSS <NUM> can use application programming interfaces (APIs) <NUM> to connect to Software-as-a-Service (SaaS) applications to receive input requests. Input requests from clients <NUM> are saved in the input requests database <NUM>, which can be separately maintained for each client <NUM>. Another embodiment may be deployed for example if an eye practice office has multiple offices at different locations. In such an embodiment, a head office of the eye care practice can include a network node that collects input requests from different locations and sends multiple input requests in a file (e.g., as a comma separated values (CSV) file containing input requests arranged in rows and field values of input requests arranged in columns) to the DSS <NUM>.

An input request received from a requesting client includes a request field storing an input variant of a data element and a plurality of additional data fields to identify a requested entry in the master catalog <NUM>. The normalizer <NUM> processes the input requests to condition the data to remove inconsistencies in the data fields in input requests. For example, in one embodiment, the input requests are prescriptions for patients received from clients that are eye care practice offices. An example of a prescription (input request) in such an embodiment is shown below. The prescription has additional information such patient related data, refill information, etc. The additional information is not shown in the example shown below. The fields in this example are shown for illustrative purposes.

Eye: { "productName" : "Proclear Dailies <NUM><NUM> -<NUM>",
"baseCurve" : "<NUM>",
"diameter" : "<NUM>",
"color" : "",
"power" : "-<NUM>",
"series" : "Proclear Dailies",
"quantity" : <NUM>,
"trial" : "<NUM>"
}.

Due to a variety of practice management systems (PMS) used by eye care practice offices and for other reasons, different field names may be used for the same data in prescriptions. A contact lens prescribed by an eye care practitioner to a patient belongs to a "series" of contact lenses offered by a manufacturer or a distributor. In the input request example <NUM>, the contact lens belongs to "Proclear Dailies" series. The "series" field in the input request (prescription) can be used as the request field used in the matching system. Different PMS systems may refer to this "series" field by different field names such as "product family," "product" or "series". The normalizer <NUM> can remove such variations in field names of input requests. It is understood that other fields or a combination of multiple fields in the input request can be used as the request field.

When prescriptions are received in bulk by the DSS <NUM> in a CSV file, fields may be arranged in a different order. For example, a CSV file received from one eye care practice office can have "series" field values in the first column and another eye care practice office can send "series" field values in the tenth column. The normalizer <NUM> identifies discrepancies in prescriptions and removes them. For example, after normalization, all prescriptions have a field value representing a single concept, arranged in one field. Other functionalities of the DSS <NUM> include deduplication of data. For example, by identifying and discarding the input requests previously received by the system. Normalizer <NUM> also identifies missing information in the input requests. For example, if patient related data is not received for a prescription, the DSS <NUM> will identify the missing information and stop further processing on the prescription until all required information is received.

The input request also contains a plurality of additional data fields to identify a requested entry in the master catalog <NUM>. In the input request example <NUM> shown above, the additional fields are "baseCurve," "diameter," "color," "power". More additional fields may be added to the input request depending on prescription requirements. The normalizer <NUM> processes the input requests received from clients <NUM> to remove variations in names and data formats of additional fields.

The normalizer <NUM> sends a control signal to matching state checker <NUM> indicating that input requests for a requesting client are ready for processing. The matching state checker <NUM> checks a matching state of the requesting client, which state can be stored for example in the client matching tables database <NUM>. The requesting client can be in one of the two matching states: a learning phase represented by a first value and a post-learning phase represented by a second value. If the client is in learning phase, the catalog match engine <NUM> is invoked. In the learning phase the catalog match engine <NUM> builds the client matching table in the client matching tables database <NUM> for the requesting client as it processes the input request from the requesting client.

In the post-learning phase, the client matching table for the requesting client is in a mature state i.e., it contains entries that match (majority of) the input variants of a data element in the request field with a specific variant of the data element in the search field of a set of entries in the master catalog. For example, in the eye care practice office embodiment, the entries in the client matching table for a requesting client (eye care practice office) contain request ("series") field values for the contact lens series that are commonly prescribed by the requesting client (eye care practice). In the post-learning phase, "series" field values in the client matching table are matched (for example, using foreign key and primary relationship) to a specific variant of the data element in the search field ("series") in master catalog <NUM>.

In one embodiment, the entries in the master catalog <NUM> are hierarchical with one parent entry with a specific variant of the data element in the search field. This parent entry has multiple child entries with different values of the data elements in additional fields. In such an embodiment, each child record has a field that references to its parent record. An example child record in the master catalog <NUM> is shown below. This child record belongs to a parent record with "series : Proclear <NUM> Day <NUM> Pack". In other words, each specific (child) entry in the master catalog <NUM> is a member of a set of entries having the same specific variant of the data element in the search field.

{ "_id" : ObjectId("5494a67c0f65af7ed25cf992"),
"productId" : "<NUM>",
"productName" : "PRCLR <NUM> DAY 90PK <NUM><NUM> -<NUM>",
"manufacturer" : "COOPER VISION",
"series" : "Proclear <NUM> Day <NUM> Pack",
"baseCurve" : "<NUM>",
"diameter" : "<NUM>",
"power" : "-<NUM>",
"addition" : "<NUM>",
"cylinder" : "<NUM>",
"axis" : "<NUM>",
"distance" : "<NUM>",
"color" : "Clear",
"modality" : "Daily",
"annualSupply" : <NUM>,
"upc" : "<NUM>",
"lastUpdated" : ISODate("<NUM>-<NUM>-11T2320:<NUM>. 667Z"),
"distributor" : [ "ABB", "WVA", "CVI", "NEWERA" ],
"abbProductId" : "COOPD90000000",
"wvaProductId" : "<NUM>",
"oogpProductId" : "BC07B24",
"normalizedParams" : {
"baseCurve" : <NUM>,
"diameter" : <NUM>,
"power" : -<NUM>,
"addition" : <NUM>,
"cylinder" : <NUM>,
"axis" : <NUM>
}
}.

The example entry (shown above) in the master catalog <NUM> contains the search field labelled as "series" with a specific variant "Proclear <NUM> Day <NUM> Pack". The catalog match engine <NUM> matches the input request from the requesting client to entries in the master catalog in a two-step matching process (details of the matching steps are described with reference to <FIG>). If the match is successful, the catalog match engine <NUM> creates a new entry in the client matching table for the requesting client. This new entry contains the input variant of the data element in the request field of input request and a reference to the specific variant of the data element in the search field in the master catalog <NUM>.

Following a successful match of an input request to a specific entry in the master catalog <NUM>, the catalog match engine <NUM> sends a "matched order" signal to input request converter <NUM> to process the matched input request.

The matching state checker <NUM> can also call the input request converter <NUM> to process an input request when the requesting client is in the second of the two states: the post-learning phase. In this state, the input requests from the requesting client are sent directly to the input request converter <NUM> by-passing the catalog match engine <NUM>. The input request converter <NUM> processes the input request to create a final input request containing the information combined from the input request and the master catalog entry matched to the input request. The input request converter <NUM> sends the final input request to order fulfillment services <NUM>. If input request converter <NUM> encounters an error during creation of the final input request, it stops processing the input request and informs the catalog match engine through an "exception order" signal. The input request is saved in a pending state in the input requests database <NUM>. The catalog match engine processes the pending input request after a period of time during which the catalog matching tables may be updated, improving the likelihood of a match in a later attempt using the pending order. The period of time after which the pending input request is re-processed can be a pre-determined time, or the period of time can be indeterminate but terminated on-demand or according to algorithms that may indicate improved likelihood of matching.

The master catalog <NUM> receives data from master catalog builder module <NUM> which in turn connects to external services through application programming interfaces (APIs) <NUM> to collect data. In the eye care practice office embodiment, the master catalog receives contact lens data from manufacturers and distributors of contact lenses.

As described above, the catalog match engine <NUM> is invoked when the requesting client is in the learning phase. The purpose of catalog match engine <NUM> is two-fold: (<NUM>) match an input request to an entry in the master catalog <NUM> and (<NUM>) build the client matching table for the requesting client by creating a new entry containing an input variant of the data element in the request field of the current input request with the specific data element in the master search field of the matched entry in the master catalog <NUM>. The catalog match engine <NUM> performs a two-step match to satisfy the first purpose in some embodiments. The example modules of catalog match engine <NUM> are shown in <FIG>.

In a first step of the two-step match, plural sets of entries in the master catalog are found, to narrow the search range needed to make a final match. In this example, a text string matcher <NUM> applies a string matching algorithm to compare an input variant of a data element in the request field of the input request to specific variants of the data elements in the search fields of entries in the master catalog. Other matching algorithms can be used to measure similarity of variants of data elements as suits a particular embodiment. In this example, a master catalog entry selector <NUM> uses the output of the text string matcher (or other matching logic module) to find plural sets of entries in the master catalog that match the input request within a similarity parameter, where the similarity parameter can be for example finding a number of, such as three, sets that match most closely according to the match technique utilized so that a number of most closely matching sets can be identified.

Now consider the example embodiment of eye care practice office in which an input request is a contact lens prescription for a patient. The master catalog <NUM> is a list of contact lens records (child entries or member entries) offered by multiple manufacturers and distributors organized under multiple "series" names (parent entries or sets of entries). The text string matcher <NUM> matches the "series" field value in the input request to the "series" field values of entries (parent entries or sets of entries) in the master catalog <NUM>. The master catalog entry selector <NUM> selects the top three entries (parent entries or sets of entries) from the master catalog <NUM> based on the results of the string matching algorithm that are within the similarity parameter. In one embodiment, the text string matcher <NUM> uses a text string matching algorithm that calculates Jaro-Winkler distance between text string in "series" field in the input request and the text strings in "series" fields in entries of the master catalog <NUM>. It is understood that other string matching algorithms can be used in a text string matcher, including for example, by calculating Hamming distance, Levenshtein distance, longest common substring distance etc..

Referring to input request example <NUM> (shown above), the request field is labeled "series" and the text string or the input variant is "Proclear Dailies. " Continuing with this example, let us consider after text string matching (first step match) by text string matcher <NUM>, the master catalog entry selector <NUM> selects the following three "series" as top three sets of entries in the master catalog <NUM>.

A second step of the two-step match in the catalog match engine <NUM> is applied to search the plural sets to identify a specific entry in the master catalog for use in a response to the input request. In this example, the second step is performed by a full matcher <NUM> and a confidence score calculator <NUM>. The full matcher accesses a database storing previously recorded input requests for the requesting client (for example, input requests received from the requesting client in the last one year). Each of the recorded input requests for the requesting client that had been matched to specific member entries (child entries) in the selected plural sets (three) of entries in the master catalog <NUM> is identified and counted. In this matching, the values of additional data fields (for example, "baseCurve," "cylinder," "diameter," "color,", "power") in recorded input requests are matched with the additional field values in the specific master catalog <NUM> entry (member entry or child entry) to which the recorded input request is matched.

For example, consider a recorded input request as shown below. For this input request to be considered a full match, the values of the additional data fields (for example, "baseCurve," "cylinder," "diameter," "color," "power") match to a specific member entry of a selected set of entries in the plural sets in the master catalog <NUM>.

Eye: { "productName" : "Total Dailies <NUM><NUM><NUM> -<NUM>",
"baseCurve" : "<NUM>",
"diameter" : "<NUM>",
"color" : "",
"power" : "-<NUM>",
"series" : "Total Dailies <NUM>",
"quantity" : <NUM>,
"trial" : "<NUM>"
}.

A confidence score calculator <NUM> uses the results of the full matcher <NUM> for recorded historical data for other input requests for the particular requesting client to calculate a confidence score for the top-three sets of entries. The recorded data for other input requests for a client is saved in the client's input requests database <NUM>. In the example embodiment of the eye care practice office, prescriptions for one year issued by the eye care practice office are saved in the history database of prescriptions in the input requests database <NUM>. In other embodiments, prescriptions older than one year can be stored in the history database.

The confidence score for a set of entries indicates the portion of prescriptions in the history database for the requesting client that match with member entries of the set of entries in the master catalog <NUM>. This match can include, in preferred embodiments, exactly matching the plurality of additional fields of one other input request in the history database of the requesting client to the plurality of additional fields of a member entry of the set of entries in the master catalog. The confidence score calculator calculates a percentage for each set of entries (top three sets) in the master catalog <NUM> using the matching procedure described above. This percentage is used as the confidence score for the set of entries. A higher percentage indicates a higher confidence score meaning a higher number of input requests from the requesting client's history database matched to entries of the set of entries. The confidence score calculator <NUM> saves the confidence scores for the set of entries in a confidence score database <NUM>.

The confidence score calculator <NUM> compares the confidence score of the set of entries having the highest confidence score with a threshold, which can be a set threshold or a threshold that is adjusted over time. If the confidence score is higher than the threshold, the set of entries is selected for inclusion in the tenant's catalog. A tenant catalog builder <NUM> adds the input variant of the data element in the request field of the current input request and the specific variant of the data element in the search field of the set of entries in the master catalog <NUM> to the client matching tables <NUM>.

For example, consider the embodiment of the eye care practice office that sends a prescription (input request). A part of the prescription is shown in the input request example <NUM> (shown above). Now further consider that in the second step of matching, the confidence score calculator identified the first set of the three sets of series (selected in the first step match and shown above) as the one having the highest confidence score which is above the set-threshold. The tenant catalog builder <NUM>, updates the client matching tables <NUM> of the requesting client with "series" in input requests matched to "series" in master catalog <NUM> (as shown below).

It is understood that in other embodiments, entries in client matching tables can be created in different ways such as by including a reference to entries in a master catalog, by creating a foreign key and primary key relationship, etc. In the case where a series with the highest confidence score has a confidence score below the set-threshold, the current input request will be marked as "pending". The pending input request is re-processed by the catalog match engine <NUM> at a predetermined period of time or on-demand.

A number of flowcharts illustrating logic executed by a memory controller or by a memory device are described herein. The logic can be implemented using processors programmed using computer programs stored in memory accessible to the computer systems and executable by the processors, by dedicated logic hardware, including field programmable integrated circuits, and by combinations of dedicated logic hardware and computer programs. With all flowcharts herein, it will be appreciated that many of the steps can be combined, performed in parallel, or performed in a different sequence, without affecting the functions achieved. In some cases, as the reader will appreciate, a re-arrangement of steps will achieve the same results only if certain other changes are made as well. In other cases, as the reader will appreciate, a re-arrangement of steps will achieve the same results only if certain conditions are satisfied. Furthermore, it will be appreciated that the flow charts herein show only steps that are pertinent to an understanding of the embodiments, and it will be understood that numerous additional steps for accomplishing other functions can be performed before, after and between those shown.

<FIG> is a flowchart <NUM> illustrating process steps for matching input requests to entries in a master catalog in two different matching states of clients <NUM>. The process starts at step <NUM> when an input request from a requesting client is received. At step <NUM> the matching state of the requesting client is checked. If the requesting client is in the learning phase of the matching state (represented by a first value), a perform catalog match step <NUM> is called. At step <NUM>, the output of the perform catalog match step <NUM> is checked. If the output of the perform catalog match step <NUM> is not successful, the input request is transitioned to a pending state (step <NUM>). At step <NUM>, the reprocessing of pending input request is initiated by calling the perform catalog match step <NUM>.

If the perform catalog match step <NUM> returns a successful match result, a respond to input request step <NUM> is invoked. This step provides a response to the input request, which can be utilized for example to produce a finalized request in a form for use by the order fulfillment process. If the response is generated successfully and does not raise any exception (step <NUM>), the finalized request is sent to an order fulfillment process at step <NUM>. The process ends at step <NUM>.

If the requesting client is in a post-learning matching state, a perform full match step <NUM> is called. In this step, the data matching system uses the client matching table of the requesting client from the client matching tables database <NUM> to match the current input request with a matched set of entries in the master catalog. The field values of the plurality of additional fields in the current input request are matched to values of a plurality of additional fields in the member entries (child entries) of the matched set of entries in the master catalog <NUM>. This results in a specific entry in the set of entries in the master catalog <NUM>. The specific entry in the master catalog <NUM>, along with the input request are converted into a finalized request in the convert input request step <NUM>. The next steps (<NUM> and <NUM>) are performed as described above to complete the process at the step <NUM>.

<FIG> is a flowchart showing detailed steps for performing the perform catalog match step <NUM> of <FIG>. A calculate edit distance step <NUM> uses an edit distance algorithm to calculate the edit distance between the input variant of a data element in the request field of the input request with the variant of the data element in the search field of a set of entries in the master catalog. A top-n set of entries from the master catalog is selected in step <NUM> using the results of the edit distance calculations in step <NUM>. The selected sets of entries are within a similarity parameter such as the set of entries with top-<NUM> edit distance results.

At step <NUM> (perform full catalog match to master catalog), recorded data for other input requests for the particular requesting client are matched with entries of each set of the multiple sets of entries selected in step <NUM>. In this matching step, each match includes matching the plurality of additional fields of one other input request to the plurality of additional fields of an entry of the set of entries. The calculate confidence score step <NUM> generates a confidence score for each set of the multiple sets of entries based on recorded data for other input requests for the particular requesting client. The confidence score of a set of entries indicates a portion of other input requests that matched with entries of the set. At step <NUM> a single set of entries in the master catalog with the highest confidence score that is above a set-threshold is selected. If there is no set of entries with a confidence score above the set threshold, the current input request is set as pending in the step <NUM>. If the set of entries with the highest confidence score has a confidence score above the set-threshold, a next step (<NUM>) adds a match of the input variant of the data element in the request field of the current input request with the specific data element in the master search field of the set of entries to the client matching tables <NUM>.

<FIG> shows an example <NUM> of an input request data structure. In the example embodiment of the eye care practice office, the input request is a prescription for a patient. The example <NUM> only shows a part of the prescription to help readers understand the technology disclosed. The data structure includes several fields including a request field <NUM> and the input variant <NUM> of a data element. The additional fields (such as "baseCurve," "diameter," "color," and "power") represent the parameters of the contact lens prescribed to a patient. Note that the fields are repeated in "left" and "right" sections. These represent prescription details for left and right eyes of the patient.

<FIG> is an example <NUM> of a master catalog entry (partially displayed) that matched with the example input request <NUM>. The example shows a search field <NUM> and a specific variant <NUM> of the data element. Note that values of additional fields in the example <NUM> match with the additional fields in the input request <NUM>. In addition, the master catalog entry has additional fields which help the system to further process the prescription.

<FIG> is a simplified block diagram of the network node <NUM> hosting the data matching system <NUM> of <FIG>. Storage subsystem <NUM> stores the basic programming and data constructs that provide the functionality of certain embodiments of the present invention. For example, the various modules implementing the functionality of certain embodiments of the invention may be stored in storage subsystem <NUM>. These software modules are generally executed by processor subsystem <NUM>.

Host memory subsystem <NUM> typically includes a number of memories including a main random access memory (RAM) <NUM> for storage of instructions and data during program execution and a read-only memory (ROM) <NUM> in which fixed instructions are stored. File storage subsystem <NUM> provides persistent storage for program and data files, and may include a hard disk drive, a floppy disk drive along with associated removable media, a CD ROM drive, an optical drive, or removable media cartridges. The databases and modules implementing the functionality of certain embodiments of the invention may have been provided on a computer-readable medium such as one or more CD-ROMs, volatile memory, non-volatile memory, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or later developed. The databases and modules implementing the functionality of certain embodiments of the invention may also be stored by file storage subsystem <NUM>. The host memory subsystem <NUM> contains, among other things, computer instructions which, when executed by the processor subsystem <NUM>, cause the computer system to operate or perform functions as described herein. As used herein, processes and software that are said to run in or on "the host," "the computer" or "the network," execute on the processor subsystem <NUM> in response to computer instructions and data in the host memory subsystem <NUM> including any other local or remote storage for such instructions and data.

Bus subsystem <NUM> provides a mechanism for letting the various components and subsystems of network node <NUM> communicate with each other as intended. A number of peripheral devices such as a network interface subsystem <NUM>, user interface output devices <NUM>, and user interface input devices <NUM> communicate with the processor subsystem <NUM> via the bus subsystem <NUM>. Although bus subsystem <NUM> is shown schematically as a single bus, alternative embodiments of the bus subsystem may use multiple busses.

Claim 1:
A method for operating a data matching system having a plurality of clients (<NUM>) and a master catalog (<NUM>), the master catalog (<NUM>) including entries having multiple fields including at least one search field (<NUM>), comprising:
processing input requests (<NUM>) from requesting clients in the plurality of clients, wherein each input request is a contact lens prescription, each of the input requests including a request field (<NUM>) storing an input variant (<NUM>) of a data element and a plurality of additional data fields to identify a requested entry in the master catalog;
maintaining client matching tables (<NUM>) for respective clients in the plurality of clients, entries in the client matching tables matching the input variants of data elements in the request field with specific variants of the data element in the search field of a set of entries in the master catalog;
wherein the entries in the master catalog are hierarchical with one parent entry with a specific variant of the data element in the search field having multiple child entries with different values of the data elements in additional fields;
the processing of input requests for a current input request of a particular requesting client, including during a learning phase using a first procedure comprising,:
searching, using a two-step match process (<NUM>), plural sets of entries in the master catalogue having different variants of the data element in the search fields for a specific entry that matches the plurality of additional fields of the current input request, and generating (<NUM>) a response to the current input request identifying the specific entry; and
adding (<NUM>) the match of the input variant of the data element in the request field of the current input request with the specific variant of the data element in a master search field of the set of entries of which the specific entry is a member to the client matching table of the requesting client; and
after the learning phase, using a second procedure comprising:
using the client matching table to match the current input request with a matched set of entries in the master catalog;
searching the matched set of entries for a specific entry that matches the plurality of additional fields of the current input request and generating (<NUM>) a response to the current input request identifying the specific entry; and
when the client matching table does not include (<NUM>) a match for the current input request, using the first procedure.