Multi-element confidence matching system and the method therefor6311178Abstract The present invention relates to a computer matching system used by a plurality of users and the method therefor, said system comprising a database; an offer creation program means for creating an entity for an offer input by each user in the database and storing said offer therein; and a search engine for comparing and matching a requirement input by a user with other users' offers stored in the database and returning matching results to said user. Advantageously, said requirement includes multiple elements as search criteria, each of said elements is assigned a weight of importance thereby each matching result has a search score indicating satisfaction level of said user, said search engine further perform ordering and ranking of said matching results according to the respective search scores thereof, and only the matching results have search scores above a predetermined satisfaction level are returned to said user. Said multi-element confidence matching system can automatically provide the user or trader with the information he is interested in without the intervention of the trader, and give the user the maximum amount of information about offers which may meet their requirement, so as to give the trader the ability to not just see offers which exactly match their criteria, but ones which come close or can fulfill part of, or more than, their needs, thereby the trader may conduct the search efficiently Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
Entity Name Description
USER A member of system, creates and owns
requirements and offers. User information is mainly
flat, raw data about user. It will be obtained by an
interface available to user.
REQUIREMENT is also referred as search criteria. In traditional
(Virtual Entity) search activities, criteria information entered by
user is not kept in database, but if this information
is intended to be base for afterward notification and
triggering system, could be stored in a real entity.
REQUIREMENT keeps information about individual parts of
ATTRIBUTE requirement. During the process of requirement
(Virtual Entity) system might create new entries for this entity
called complex attribute, which consists of result of
previous single attribute.
OFFER All users offer for supply or demand. This entity
keeps the Id. And fixed part of the offers.
OFFER_ATTRIB variable part of offers, showing the attributes of
offer.
FIELD look-up table for name of fields will be used in
offer and requirement entities to refer to type of
specifications.
UNIT look-up table to be used to show the units for
figures in offer and requirement entities.
Although Requirement and Offer entities contain similar information, their functionality is different. Offer entity keeps information about fixed demand or supply, user provides or requests. This information will be tested by the system every time a requirement (search criteria) is submitted. Requirement contains user specified conditions and include ranges. Requirement is a virtual entity, means that it will not necessarily be kept in a real entity after the process is finished. Field and Unit entities are tables used to create attributes for Offer and Requirement. FIG. 4b illustrates the relationship among the entities in the database according to the embodiment of the present invention. As shown in FIG. 4b, each user has a record in user entity, and there is no more than one entry for each user. There is zero, one or more than one requirement for each user, and these requirements are tied to user's entry Each user may create zero, one or more than one demand or supply offer. Each offer/ requirement has one or more attribute. Every attribute will point to an entry in field entity to show the type of field. And every attribute will point to the entry in the unit entity to specify the unit type FIG. 4c illustrates the details of the key relationship of the entities shown in FIG. 4b, and the detailed description to the corresponding attributes for separate entities is shown in following tables 2-8.
TABLE 2
entity name: user
NOT NULL
Attribute Name Attribute Definition Primary Key
user-id Identification number, unique for
each user
user_identity Series of information about a user's
identification. Attributes and their
types could vary based on sector,
subject and nature of the business,
but this information is mostly of the
fixed, informative type and does not
affect the flow of the logic.
user_profile information about a user's
preferences. This will be used in
order to specify the look and type of
information represented to the user in
general an during execution of
individual tasks.
FIG. 5 illustrates a web-based clients communicating over the internet to an information server according to an embodiment of the invention. The matching system according to the present invention has an open architecture and can be used in a number of environments, but in the International Trade market the internet is used. The matching system is housed inside a server which is on the internet, and the users may connect to the server which has the matching system via a web browser, as shown in FIG. 5. The server can be SUN Microsystems-Unix based, or Intel-Microsoft NT based. The clients can be PCs running the Microsoft Windows 95 operating system, Apple Macintosh running Apple MacOS, or Sun Microsystems Workstation running Unix. The Extensible Database Management System used for the database of the invention can be Informix or Oracle product. And the plug-in modules available for the above databases could include Verity, Excalibur or Virage, FIG. 6 illustrates the detailed components of both the client and server according to the embodiment of the invention in FIG. 5. As shown in FIG. 6, each client has an operating system, a basic storage for local information and applications, a web browser for working with the web based application and browsing pages in HTML format and a network transport for connection to the global network The server which has the multi-element confidence matching system includes an operating system, a mass storage for storing the database and common information and applications, an extensible database engine for providing database services and responding to requests from clients, a web server to provide web services and a network transport, wherein the extensible database engine is used for serving clients in relation with their queries and database service requests, and it comprises database tables, SQL functions and extensible modules. Said extensible modules comprise 3rd party matching (data matching performed by applications written by other software companies) engines, web development and delivery modules for utilizing existing standard services, and core technology modules for adding the extraordinary multi-element confidence matching system functions. FIG. 7 shows the structure of the core technology modules and its connection to the 3.sup.rd party matching engine and SQL functions. The core technology modules include a matching engine for comparing the requirement with the offers stored in the offer database, custom matching components, and an ordering and ranking module. Here the custom matching is data matching which have been implemented in addition to built-in functions and 3.sup.rd party technology, e.g. inclusive match-where a supply item has more quantity than the requirement As shown in FIG. 7, the requirement and the offer details are sent to the matching engine, and the matching engine and the custom matching components perform the comparison of the requirement and the offers by means of the 3.sup.rd party matching engines, including Verity Text and Excalibur Text, and SQL functions such as equal (=), like, less than (<), and greater than (>). Thereafter, the matching results produced by the matching engine are sent to the ordering and narrowing module, in which they are ranked according to the confidence or score each matching result has, and are narrowed to reduce the amount of data returned to the user based on their own narrowing criteria, for example, only show me data with exact matches and limit it to the first 5 in price order. The results of which the matching score is less than a minimum acceptable level are discarded, thereby the ranked and narrowed matching offer set is sent back to the user The arrangement in FIG. 7 is independent of interface This diagram would remain the same whether the implementation are client-server, web-base or via a simple terminal character interface. All types of user interface can generate requirements and match them with existing offers and produce a result set. All of the above processing would take place from within a core technology extensibility module and interface to the core database engine and any other extensibility modules installed. FIG. 8 illustrates a typical web implementation of the multi-element confidence matching system according to the present invention and the additional components required to support it. As shown in FIG. 8, the web server shown in FIG. 6 comprises configuration details for specifying the behavior of the server, internal functions for providing basic services, custom functions for user and application specific services and standard HTML data, and a delivery engine for integrating results of search engine with standard HTML pages. The HTML form containing the requirement from the user is sent to the delivery engine. The delivery engine sends all the data of the requirement to the other modules. The web development and delivery modules include web page storage and a web page delivery. These modules handle application logic, static content of standard HTML and a dynamic content of actual data, the result of queries to the database, and variables. The web page delivery communicates with the internal functions and modules using SQL. FIG. 9a, 9b, and 9c illustrate the creation of the entities in the database shown in FIG. 4 according to an embodiment of the invention. In FIG. 9a, when creating an offer entity, first, the offer fixed information is input into the system which creates an offer in the offer entity. The attribute information is also taken in from field and unit entities and this creates an attribute in the offer attribute entity. In FIG. 9b, when creating user entity, first, the user information is input into the system, the user profile is also input, then a user record is created in the user entity. Each user keeps a user record in the user entity. FIG. 9c illustrates the creation of the requirement entity. As shown in FIG. 9c, when creating requirement, first, the requirement fixed information is input into the system, then get the type whether it's a requirement for demand or supply. Then in turn field information will be taken using field and unit entities. At the end of this process a requirement fixed information entry and one or more attribute information entries will be created. The detailed description to the related entities is in Tables 2-8. FIG. 10a and 10b shows more detail on data flow of the system according to an embodiment of the present invention of FIG. 2a and 2b, which includes a unit entity and a field entity. As described above, the field is a look-up table for name, type and length of fields that will be used in the offer and requirement entities to refer to type of specifications; and the unit is a look-up table used to show the units for figures in the offer and requirement entities. The unit entity and field entity both participate in the processes of enter offers, enter requirement in FIG. 10a and the compare process in FIG. 10b. A requirement input by a user may be also processed as an offer so that the other users may know what he needs. In the system, one user's offer is also a requirement to the other users, and his requirement is also an offer to the other users. FIG. 11 illustrates the flowchart of the procedure for creating an offer in the database generated by executing the offer creation program as shown in FIG. 1 according to an embodiment of the invention. As shown in FIG. 10, when a user inputs his offer into the system, the input offer fixed information is extracted out and it is determined whether it is a demand or a supply according to the status of the demand_supply attribute shown in Table 4. If it is a demand, this information is set to demand; and if it is a supply, it is set to supply. At the next step, an offer is created in the offer database. Then, it is judged whether there are any more attribute, if yes, get attribute information using the field and unit, then create an attribute in the offer attribute entity in the database, and return to the judging step to determine whether there are more attributes; if no more attributes, go to finish. FIG. 12 illustrates the flowchart of the procedure for creating requirements in the database according to an embodiment of the invention. As shown in FIG. 12, when a user enters his requirement, first, the input requirement fixed information is extracted, and is determined whether it is a demand or a supply, if it is a demand, this information is set to demand; and if it is a supply, set to supply. At the next step, a requirement is created to the requirement database. At the next step, it is judged whether there are any more attribute, if yes, get attribute information using the field and unit, then create attribute to the requirement attribute entity in the database, and return to the judging step; if no more attributes, go to the matching process for matching the requirement with the offers having been stored in the database by the other users FIG. 13 illustrates the flowchart of the procedure for matching the requirement input by the user with the offers stored in the offer entities of the database As shown in FIG. 13, in the matching process, first, the requirement information is taken from the procedure allowing user to input criteria, then this requirement is processed by the system in the procedure shown in FIG. 14. The next step is to get an offer from the database and start matching fields in the requirement with fields in the offer. In both cases before getting a new offer or requirement, the system checks whether there are any. Both offer and requirement have attributes and attributes are pieces of information with specific and unique ID. If the ID of an attribute in a requirement matches the ID in the offer, the system checks if the content of offer attribute matches the one in the requirement or not and based on that generates a score for this match, which indicates the satisfaction level of the user to the matching result. At the end of all cycles if the score of offer reaches the MAL value it will participate in result set. The match level of the matching result from one search may be fill match, inclusive match, partial match, or no match, also shown in FIG. 3. The procedure A for processing search criteria is shown in FIG. 14, in this process, it is judged if the criteria is a complex one. If yes, the attrib_ids are put in the input fields of the attribute, then set a relationship; if not put user specified fields in the input fields of attribute, then set a relationship Thereafter, create entry in the requirement attribute, and return to the complex judging step. Using the multi-element confidence matching system of the present invention, when a user inputs an offer, the offer creation program performs the procedure in FIG. 11 for creating offer and offer attribute in the database. When a user inputs his search criteria, the search engine creates a requirement and requirement attribute in the database, then perform the matching process in FIG. 13 and 14. Specifically, after a user specifies the criteria, the system analyses it and create entries for requirement entity Every simple criteria will have an entry in the entity, the system will also create an entry for every condition which is a result of other conditions. This will be explained more in the examples below As to the result, there are two main factors that specifies the type of the result, one is the weight the user gives to every condition he specifies and the other one is the way user arranges the criteria, mostly depend on whether there is any range specified or not. The first thing the system does is to break down the criteria to single steps and create new steps based on complex criteria. The multi-element confidence matching system and the method therefor of the present invention will be described in detail according to an embodiment of the invention, in which: the search criteria is as follows:
(A= "TEXT1" OR
B= "TEXT2") AND
C> NUMBERIC1 AND
(D>DATE1 AND
D<DATE2) AND
E like "TEXT3%
the evaluation is performed as the following sequences:
1-A "TEXT1" =
2-B "TEXT2" =
3-C NUMERIC1 >
4-D DATE1 >
5-D DATE2 <
6-E "TEXT3%" LIKE
7-1 2 OR
8-4 5 AND
9-3 7 AND
10-9 6 AND
Result-8 10 AND
The sequences and the respective operations are shown in following Table 7.
TABLE 9
Sequence Argument 1 Argument 2 Operator Weight Inclusive
1 A TEXT1 EQ
2 B TEXT2 EQ
3 C NUMERIC1 > 5
4 D DATE1 >
5 D DATE2 <
6 E TEXT3% LIKE 5
7 1 2 OR 50 Y
8 4 5 AND 40 Y
9 3 7 AND
10 9 6 AND
11 8 10 AND
The result table of the evaluation or match is shown as below.
False True
2 1
5 7
8 4
3 6 multiply by weight
9
10
Result The result of No Match is dependent on the possibility of Partial Match based on user criteria and weight, in other words, No Match becomes a relative one, which depends on the user's need. If there is no True result, it will be no match, but with any True result, the overall result will be a partial match, depend on the weight that user gives to any criteria and minimum acceptable level, thereby satisfaction on the result can be measured. In above example, (3 and (8 are True and 6 and 7 are False. According to the weight of each, the score for this search is as follow.
Weight * atrrib.result = score
7 50 * 1 = 50
8 40 * 0 = 0
3 5 * 0 = 0
6 5 * 1 = 5
score 55
if minimum acceptable score is over 55 this search result will be considered as no satisfaction, i.e., no match, but for any minimum acceptable level lower than 55 this is a partial satisfaction Of course with score of 100 the result will be FULL MATCH. If any criteria is consisting of a range and the result is False, the result is inclusive. From the above description, in the present invention, the concept of "no match" is relative, if the MAL is set to greater or lower value, the search results, i.e., the information user can get is different. In other words, the MAL is a modifiable value by user, and the system will assume a default value for MAL value, but user based on level of expectation can increase or decrease it. Therefore, the user may adjust the weights he assigned to the respective elements of the search criteria, to change the information scope available to him as he need. To show how the system of the invention works, a detailed example is provided as follows. As an example, a user specifies that he is looking for a pair of tennis shoes with a price bellow $100 and color is either "white" or "Blue", but also specifies that the color is very important by giving a weight of 80 out of 100 to the color, The system, while evaluating the criteria, accepts any white or blue tennis shoes as a partial match and those bellow $100 as a full match. FIG. 15 shows a sample of the interface which is provided for user to specify his search criteria for this example. The user of the system, a trader, searches for a supply offer and creates a requirement with the criteria shown in FIG. 15. The search criteria in this example is: (color=White OR color=Blue) AND price <100, and the weight for "color=Blue" is 80, while for "price <100" is 20. The system start dealing with this criteria in the following order: ##STR1## Entities involved in this example are:
TABLE 9
offer
Attribute content
offer_id
user_id user1
demand_supply supply
Contents for "field_id" and "field_unit_id" are from look-up tables. These tables are used when creating offer and requirement.
TABLE 13
field
field id field name field type field length
1 material text 15
2 color text 15
3 price numeric 9.2
4 length numeric 9.2
5 Width numeric 9.2
6 Size text 15
System starts to evaluate attributes of requirement in order and according to their weight. The logical result of this search is NO MATCH, because the last statement (5) generates False output, but considering the weight user has given to first condition and specifying that price range can be inclusive and also the score of the search is 80 of 1009 the system consider the result as partial match, and returns this offer to the user.
Attribute_id Result * Weight Result
1 True
2 False
3 True * 80 = 80
4 False * 20 = 0
5 False
score 80
INDUSTRIAL APPLICABILITY With the multi-element confidence matching system of the present invention, this system manages to know user's taste of choices by letting him specify a level of importance for each of the conditions and specifying that whether inclusive match is acceptable. This is also possible to be implemented in the system according to the embodiments of the invention that by storing requirements (criteria) it can notify user whenever a matching case enters to the system after a user has submitted the requirement. This way not only semi-artificial intelligence will be added to the system but also queries will stay active until the time of deactivation and do much more than instant queries. When a user inputs his requirement into the system, the matching program in the matching system is executed without the intervention of the user, and the matching results are returned to the user instantly. This system can provide custom matches, non-exact matches, and the matching results of different levels are ordered and ranked so as to be narrowed, thereby the narrowed results are returned to the user. The users of the system according to the present invention are both subject and object relative to each other. Using the multi-element confidence matching system of the present invention in the international trading field, the trader or user can conduct search more efficiently and get more useful information. The ranked and narrowed search results are returned to the user instantly, and the user can adjust his weight assignment to the respective elements in the search criteria or requirement and change the minimum acceptable level to change the information he wants to get. Apparently, the multi-element confidence matching system is a highly efficient electronic trading system, and it helps the users of this system to find useful trading information and conduct his business more effectively Furthermore, the system of the present system can be also used in the field such as library, electronic purchasing, ticket ordering etc. and increase the efficiency thereof. Having described and illustrated the principles of the invention in the preferred embodiments thereof, it should be apparent that the invention can be modified in arrangement and detail without departing from the spirit and scope of the invention. All these modifications and variations should fall in the scope defined in the appended claims.
|
Same subclass Same class Consider this |
||||||||||