JP3607867B2

JP3607867B2 - Multi-element certainty matching system and method

Info

Publication number: JP3607867B2
Application number: JP2000514221A
Authority: JP
Inventors: フジュンビ; ランリ; ショーンブリス; レザノジョーミ; ホンヤン
Original assignee: ウェブプラスリミテッド
Priority date: 1997-09-29
Filing date: 1997-09-29
Publication date: 2005-01-05
Anticipated expiration: 2017-09-29
Also published as: DE69730057T2; HK1015900A1; DE69730057D1; JP2001518667A; AU4449797A; WO1999017224A1; US6311178B1

Description

【０００１】
発明の属する分野
本発明は、コンピュータマッチングシステム及びその方法、特に、ユーザの要求を他のユーザのオファーとマッチさせ、そのユーザにマッチング結果を返すといったデータベース上に設けられた多要素の確信度付きマッチングシステムである電子商取引システムに関連したものである。
【０００２】
発明の背景
トレーダは今日、世界取引市場で取引をおこなっており、他の国のトレーダと効率的にかつ信頼性をもって取引する必要があるので、近年国際取引業務において電子商取引システムがより広く使われてきている。
【０００３】
今のところ、いくつもの電子商取引システムが国際取引において使用されているが、例えばＥＤＩ（電子的データ交換）は、トレーダが特定の取引相手とのオファーのやりとりをするために使用されるが、トレーダが興味のあるオファーを見つけるために使用することはできない。
【０００４】
トレーダが他のトレーダから必要な商品を見つけるための取引システム、あるいは彼らの商品のバイヤを見つけるための取引システム、及び多数のビジネス関連事項に対処するための取引システムもある。
取引システムの業務は、電子商取引システムを介して他のトレーダが公表したオファーと、トレーダの要求をマッチさせることである。このことは通常、有効なオファーのユーザクライテリアの直接サーチ及び単なるサーチ結果のみを一般的な順位でディスプレーすることによって達成される。
【０００５】
情報技術において、ユーザによって特定された条件（クライテリア）に対する返答に最良の結果をだす試みは、古くからの課題である。質疑及びマッチングシステムのいくつもの異なる方法が履行され、日々進歩している。そのシステムのほとんどが技術的な標準化ツールをその目的のために使用しており、その柔軟性はそれらのツールが何をできるかにかかっている。標準化サーチエンジンは主にサーチクライテリアを調査し、それが出す結果は、クライテリアの丁度全ての条件にマッチするゼロ、１あるいは複数のケースとなっている。一つのケースがいくつの条件を満たすかにかかわらず、もしその中のうち一つの条件が満たされない場合、その条件が他の条件の中で最も重要でない条件であっても、そのケースは結果セットに含まれない。範囲に関しては特に、主にユーザは彼らの欲求に完全に合致するものではなく、彼らの欲求に近いものを欲している。言い換えると、Ｉｎｆｏｍｉｘ、Ｏｒａｃｌｅ、Ｓｙｂａｓｅ、Ｉｎｇｒｅｓ及び他のデータベースエンジンは、マッチングケースにおいて「マッチ」及び「ノーマッチ」というたった二つの選択（チョイス）しか有していない。
【０００６】
従来の取引システムでは、ユーザがサーチクライテリアを示すと、通常膨大な量の情報が返却され、ユーザはその中から自分の興味のあるものを見つけなければならない。そして、もし必要ならば、ユーザはクライテリアにさらに多くの条件を追加し、または、さらなるサーチクライテリアあるいは論理式（フォーミュラ）を入力し、返却される情報量を削減するようもう一度サーチをおこなわなければならない。どうやら彼は、満足な結果を得るまで、結果を彼自身によって絞り込まなければ（狭めなければ）ならないらしい。彼は一つのカテゴリーから次のカテゴリーをサーチしなければならず、そして、毎回新しいサーチクライテリアを選択する前にスクリーンにディスプレーされる情報を読まなければならず、サーチするプロセスの間ユーザによる介入なくしてはサーチは連続的におこなえない。一方で、もしサーチクライテリアに含まれる条件が少なすぎると、返却される情報は多すぎて、そのうちのほとんどが彼の興味のあるものではない。他方、もしサーチクライテリアに含まれる条件が多すぎると、上述したようにあまり重要でない条件を満たさなかったという理由で、ユーザは彼にとって最も重要な情報を得られない可能性もある。
【０００７】
従って、従来のサーチシステムはユーザが使用する際便利ではなく、サーチを効率的におこなえない。ユーザがそのようなシステムを使用すると、サーチプロセスにかかる時間とコストが増大する。
【０００８】
発明の概要
本発明の目的は、多要素の確信度付きマッチングシステムを供給することであり、それは、ユーザあるいはトレーダにトレーダの介入なくして彼の興味ある情報を自動的に供給できるものであり、ユーザに彼らの要求に合致し得るオファーの情報を最大量与えるものであり、そうすることによってトレーダが彼らのクライテリアに完全に合致するオファーのみならずそれに近いものあるいはその一部分、あるいは彼らに必要なもの以上のものを見ることができ、従ってトレーダはサーチを効率的に行うことができるものである。
【０００９】
有利なことに、本発明はスタンダードなツールの洗練性を高めたもので、ケースを享受（アクセプト）あるいは拒否（リジェクト）する際にユーザの考えに沿うものである。それは、ユーザのチョイスにさらなるパラメーターを介在させることによって、システムは結果の許容範囲を広げることができ、ユーザの好みに基づいて最も重要な条件に合致し、重要でない条件のみを満たさないケースをアクセプトするようになすことができる。
【００１０】
上記の目的及び利点を達成するために、本発明は複数のユーザに使用されるデータベースからなるコンピュータマッチングシステム及びその方法を供給する；各ユーザによってデータベースに入力されたオファーのエンティティを生成し、前記オファーをデータベースに保存するためのオファー生成プログラム手段；ユーザによって入力された要求をデータベースに保存してある他のユーザのオファーと比較し及びマッチングし、前記ユーザにマッチング結果を返却するサーチエンジンを備える。
【００１１】
本発明のコンピュータマッチングシステムにおいては、前記要求がサーチクライテリアとして複数の要素を含んでいること、前記各要素に重要性の重みつけがおこなわれており前記ユーザの満足度を示すサーチ得点を各マッチング結果が有すること、前記サーチエンジンがさらにそれぞれのサーチ得点に従って前記マッチング結果を順位付けおよびランキング付けすること、並びにサーチ得点を有するマッチング結果についてのみ前もって決められた満足度が前記ユーザに返却されること、が好ましい。
【００１２】
また、前記マッチングシステムに対する前記ユーザ側インターフェイスはインターネットを介することが好ましい。
本発明の以上及び他の目的、態様及び利点は、図面を参照しながら、以下の発明の好ましい具体例の詳細な説明よりさらにあきらかになる。
【００１３】
好ましい具体例の詳細な説明
以下、本発明の好ましい具体例の説明を、図示された添付図面を参照して詳細に行う。
図１は本発明に係る多要素の確信度付きマッチングシステムの基本構造を示している。図１に示されるとおり、多要素の確信度付きマッチングシステムは複数のユーザによって使用され、データベース、データベースにおいてオファーエンティティを生成するためのオファー生成プログラム、及びユーザによって入力されたサーチ条件（クライテリア）あるいは要求とデータベース内に存在するオファーとを比較するためのサーチエンジンを有している。ユーザによってオファーが入力されると、そのオファーはオファー生成プログラムによって処理されデータベースにおけるオファーエンティティに保存される。ユーザから要求を受け取ると、サーチエンジンはその要求と他の全てのユーザのデータベースにおけるオファーエンティティに保存され存在しているオファーとをマッチさせるために作動する。マッチング結果は確信度に従ってランク付けされることができ、すなわち、マッチングレベルあるいはサーチ得点、並びにマッチング結果が対応するユーザに返却される。
【００１４】
ユーザは多要素の確信度付きマッチングシステムにインターネットを介してインターフェイスすることができる。そしてデータベースは仮想となりうる要求エンティティを含むことができる。
【００１５】
図２ａ及び図２ｂは、本発明に係る多要素の確信度付きマッチングシステムにおいて履行される方法の図の原理を示している。図２ａに示されるとおり、各ユーザによって入力されたオファーの詳細はオファーデータベースに書き込まれ、サーチクライテリア、すなわち、そのユーザによって入力された要求はマッチングプログラムあるいは図１のサーチエンジンの作動によっておこなわれるマッチング処理に送られ、そのマッチング処理はその要求と他の全てのユーザからのオファーデータベースに保存されているオファーの詳細とを比較し、それによってそのユーザにマッチングオファーリストが返却される。
【００１６】
マッチング処理においておこなわれるマッチングプロセスは図２ｂにおいて詳細に示されている。図２ｂに示されるとおり、まず最初に、サーチクライテリア、すなわち、ユーザによって入力された複数の条件あるいは要素を含んだ要求は、オファーデータベースからのオファーと比較される。各条件はその重要度を示す重み付けがなされているので、各マッチング結果はユーザの満足度を示したサーチレベルを有する。比較結果は５レベルあり、フルマッチオファー、サブセットマッチオファー、パーシャルマッチオファー、スーパーセットマッチオファーおよびノーマッチオファーといったものである。比較結果は順番に一致度が低くなり、ユーザによって設定されたミニマムアクセプタブルレベル（ＭＡＬ）より高いレベルを持つマッチング結果がユーザに返却される。上記のプロセスはユーザが要求を入力すると多要素の確信度付きマッチングシステムにより自動的におこなわれ、マッチング結果がユーザに返却され、それによってユーザは瞬時に彼の要求を満たすオファーを得ることができ、そしてさらに有利なことには、そのマッチング結果はユーザのクライテリアを１００％満たす完全なマッチであるだけでなくパーシャルマッチあるいは包含的マッチの結果を含むのである。
【００１７】
取引の分野では、オファーはバイ（需要）あるいはセル（供給）となり得ると同時に、要求もバイあるいはセルとなり得る。従って、もし要求が需要であった場合、データベースにおいて供給オファーと比較される；もし要求が供給であった場合、データベースにおいて需要オファーと比較されることとなる。
【００１８】
図３は本発明の具体例に係るシステムにおけるサーチ結果のマッチングレベルを示している。図３に示されるとおり、マッチング結果はそのレベルに従って順位付け及びランク付けされ、マッチング結果セットは順序及びレベルによって構築可能であり、そこではレベル１は完全なマッチ、すなわち、フルマッチであり、それはすなわち入力された需要Ａは供給セットと完全に同じであったことを意味する；レベル２は包含的マッチであり、供給セットＢは入力された需要Ａを内包している、すなわち、セットＢはセットＡの一部のみ含んでいる；レベル３はパーシャルマッチであり、セットＡ及びセットＢはお互いにオーバーラップする部分を有している；レベル４も包含的マッチであるが、供給セットＢが入力された需要Ａを外包している；そしてレベル５はノーマッチであり、セットＡおよびセットＢ間に共通部分はない。
【００１９】
各サーチクライテリアあるいは要求は、商品、マーケットポジション（バイヤあるいはセラー、または両方）オファーの日付、配達日付、オファーする者、値段及び量といった多数の要素を含むことができる。オファーは要求と比較されるために要求と同じ要素を含むことができる。要求の各要素はデータベースにおけるオファーのそれと比較され、対応する要素をマッチさせるプロセスの各流れはユーザによって重み付けすることができる。上記のマッチの５レベルはそれぞれユーザによって重み付けされた結果の得点を有しており、レベル１のフルマッチから、レベル５のノーマッチまで、得点は１００％から０％まで減少する。
【００２０】
図４ａは本発明に係るデータベースにおけるデータエンティティの構造を示している。データベースにおいては、ユーザエンティティがあり、それはシステムのメンバーであり要求及びオファーを生成及び所有する。ユーザエンティティに保存されているユーザ情報は主にフラット、加工されないユーザデータであり、ユーザに使用可能なインターフェイスによって得られる。要求は仮想的エンティティであり、また上記のようにサーチクライテリアとしても参照される。伝統的な活動においては、ユーザによって入力されたクライテリア情報はデータベース内に保存されないが、もしその情報が後の告知及びトリガーシステムに使用されるものであれば、クライテリアは現実的エンティティに保存されたであろう。図４ａに示されるとおり、要求エンティティはＩＤ、並びに要求ＩＤ、データ、及び関係を含む属性を有している。要求−属性は要求の個々の部分についての情報を保存するために使用される。要求を生成するプロセスの間、システムはコンプレックス属性と呼ばれるこのエンティティの新しいエントリを生成することができ、それは前の一つの属性の結果によって構成されている。オファーエンティティは供給あるいは需要のユーザのオファーを保存し、このエンティティはＩＤ及びオファーの固定部分を保存し、それすなわち商品の説明あるいはクライテリア及びサーチプロセスに関係しないいかなる他の部分の情報であり、そしてオファー属性はオファーの変数部分を保存し、オファーの属性を示すものである。ここで変数部分とは、値段、色、素材等といった属性及びクライテリアに関係するものである。
【００２１】
加えて、データベースはフィールド情報を保存するフィールド及びユニット情報のためのユニットエンティティを含んでいる。
上記のエンティティの定義を、以下の表１にて示す。
【００２２】
【表１】

【００２３】
要求及びオファーエンティティが同様の情報を含むにもかかわらず、それらの作用は異なっている。オファーエンティティは固定された需要あるいは供給、ユーザ供給あるいは要求についての情報を保存する。この情報は要求（サーチクライテリア）が提出される度にシステムによってテストされる。要求はユーザにより特定された条件を含み、範囲を含んでいる。要求は仮想的エンティティであり、それはプロセスが終了した後、現実的エンティティに保存される必要はないということである。
【００２４】
フィールド及びユニットエンティティはオファー及び要求の属性を生成するのに使用される表である。
【００２５】
図４ｂは本発明の具体例に係るデータベースにおけるエンティティ間の関係を示すものである。図４ｂに示されるとおり、各ユーザはユーザエンティティに記録を持っており、各ユーザは一つより多いエントリを持たない。各ユーザは０、１あるいはより多くの要求を持っており、これらの要求はユーザのエントリと結びついている。各ユーザは０、１あるいはより多くの需要あるいは供給オファーを生成することができる。各オファー／要求は１あるいはより多くの属性を持っている。全ての属性はフィールドエンティティのエントリをポイントして、フィールドのタイプを示す。そして全ての属性はユニットエンティティのエントリをポイントしてユニットタイプを特定する。
【００２６】
図４ｃは図４ｂに示されているエンティティのキーとなる関係の詳細を示しており、別々のエンティティの対応する属性の詳細な説明は以下の表２−８に示される。
【００２７】
【表２】

【００２８】
【表３】

【００２９】
【表４】

【００３０】
【表５】

【００３１】
【表６】

【００３２】
【表７】

【００３３】
【表８】

【００３４】
図５は本発明の具体例に係るインターネットを通じて情報サーバにコミュニケーションするウェブ基礎クライエントを示している。本発明によるマッチングシステムはオープン構造を有しており数々の環境にて使用することができるが、国際取引市場においてはインターネットが使用される。マッチングシステムはインターネット上のサーバ内に位置しており、ユーザは、図５に示されているとおりウェブブラウザを通してマッチングシステムを有するサーバにつなげることができる。サーバはサンマイクロシステムズ社のユニックスによるものでも、インテルマイクロソフト社のＮＴによるものでもよい。クライエントはマイクロソフトウィンドウズ９５オペレーティングシステムが動作するパーソナルコンピュータ、アップルマックＯＳが動作するアップルマッキントッシュ、あるいはユニックスが動作するサンマイクロシステムズワークステーションとなりうる。本発明のデータベースに使用される拡張可能なデータベース管理システムは、インフォミックスあるいはオラクルの商品でよい。上記のデータベースに使用できるプラグ−インモジュールは、ヴェリティ、エクスカリバーあるいはヴィラージュを含むことができる。
【００３５】
図６は図５における本発明の具体例に係るクライエント及びサーバにおけるコンポーネントの詳細を示している。図６に示されるとおり、各クライエントはオペレーティングシステム、ローカル情報及びアプリケーションの基礎貯蓄内容、ウェブ基礎アプリケーションをおこなう及びＨＴＭＬフォーマットにおけるページをブラウズするためのウェブブラウザ、並びにグローバルネットワークにつなげるためのネットワーク転送部を有している。多要素の確信度付きマッチングシステムを有するサーバはオペレーティングシステム、データベース及び共通の情報やアプリケーションを保存する大容量記録装置、データベースサービスを供給する及びクライエントからの要求に答える拡張可能なデータベースエンジン、並びにウェブサービス及びネットワーク転送部を供給するウェブサーバを含んでいる。拡張可能なデータベースエンジンは、クライエントの質疑及びデータベースサービス要求に関係したクライエントに対するサービスに使用され、データベース表、ＳＱＬ機能及び拡張可能なモジュールによって構成されている。前記の拡張可能なモジュールは、第三者マッチング（他のソフトウェア会社によってつくられたアプリケーションによるデータマッチング）エンジン、既存のスタンダードサービスを利用するためのウェブ展開／転送モジュール、並びに臨時の多要素の確信度付きマッチングシステム機能を追加するためのコア技術モジュールにて成り立っている。
【００３６】
図７はコア技術モジュール並びにそれが第三者マッチングエンジン及びＳＱＬ機能につながる構造を示している。コア技術モジュールは要求とオファーデータベースに保存されているオファーとを比較するためのマッチングエンジン、カスタムマッチングコンポーネント、並びに順序付け及びランク付けするモジュールを含んでいる。ここで、カスタムマッチングとは、既存の機能及び第三者技術、例えば、包含的マッチすなわち供給アイテムが要求よりも量が多いといったものに加えて履行されてきたデータマッチングである。
【００３７】
図７に示されているとおり、要求及びオファーの詳細はマッチングエンジンに送られ、マッチングエンジン及びカスタムマッチングコンポーネントは要求と第三者マッチングエンジンの手段によるオファーとを比較する。第三者マッチングエンジンは、ヴェリティテキスト及びエクスカリバーテキスト、並びに同等（＝）、類似、より少ない（＜）、及びより大きい（＞）といったＳＱＬ機能を含んでいる。その後、マッチングエンジンにより出されたマッチング結果は順序付け及び絞込みモジュールに送られ、各マッチング結果が持つ確信度あるいは得点に従ってランク付けされ、彼ら自身の絞込みクライテリア、例えば、完全マッチ及び値段順の最初の５つに限定したデータのみ見せてくれといったものに基づいてデータの量が絞り込まれ、ユーザに送られる。マッチング得点が最低の受入レベルに達しなかった場合の結果は捨てられ、ランク付けされ絞り込まれたマッチングオファーセットがユーザに送り返される。
【００３８】
図７は、独立のインターフェイスである。この図は、実行がクライエントサーバ、ウェブベースあるいは単なるターミナルキャラクターインターフェイスを介していることに係わらず同じである。ユーザインターフェイスの全てのタイプは要求を生み出し、存在するオファーとマッチさせ、結果セットをつくりだすことができる。
【００３９】
以上のプロセスの全ては、コア技術拡張モジュール及びインターフェイス内から、コアデータベースエンジン及びいかなる他のインストールされた拡張モジュールまででおこなわれる。
【００４０】
図８は本発明による多要素の確信度付きマッチングシステムの典型的ウェブにおける実行技術及びそれをサポートするために必要とされる追加のコンポーネントを示している。図８に示されているとおり、図６に示されているウェブサーバは、サーバの行動を特定するための構造詳細、基礎サービスを供給するための内部機能、ユーザのためのカスタム機能及びアプリケーション特定サービス及び標準ＨＴＭＬデータ、並びに標準ＨＴＭＬページとサーチエンジンの結果を統合する転送エンジンからなっている。ユーザからの要求を含むＨＴＭＬフォームは転送エンジンに送られる。転送エンジンは要求の全てのデータを他のモジュールに送る。ウェブ展開及び転送モジュールはウェブページ保存及びウェブページ転送を含んでいる。これらのモジュールはアプリケーションの論理、標準ＨＴＭＬの不変内容（コンテンツ）及び実際のデータの可変内容（コンテンツ）、データベースに対する質疑の結果、並びに変数を担っている。ウェブページ転送は内部機能及びモジュールとＳＱＬを使ってコミュニケートする。
【００４１】
図９ａ、９ｂ、及び９ｃは本発明の具体例に係る図４に示されるデータベース内におけるエンティティの生成を示している。図９ａにおいては、オファーエンティティの生成の際、まず最初に、オファーの固定情報がオファーエンティティにおいてオファーを生成するシステムに入力される。属性情報もまたフィールド及びユニットエンティティより導入され、オファー属性エンティティにおいて属性を生成する。
【００４２】
図９ｂにおいては、ユーザエンティティを生成する際、まず最初に、ユーザ情報がシステムに入力され、ユーザプロファイルもまた入力され、その後ユーザエンティティにおいてユーザレコードが生成される。各ユーザはユーザエンティティにおいてユーザレコードを保存している。
【００４３】
図９ｃは要求エンティティの生成を示している。図９ｃに示されるように、要求を生成する際、まず最初に、要求固定情報がシステムに入力され、それが需要かあるいは供給の要求かタイプ付けされる。その後、代わりにフィールド情報がフィールド及びユニットエンティティを使って取り出される。このプロセスの最後には、要求固定情報エントリ及び一つあるいはより多くの属性情報エントリが生成される。
【００４４】
関連するエントリの詳細な説明は表２−８にある。
【００４５】
図１０ａ及び図１０ｂは、図２ａ及び図２ｂにおける本発明の具体例に係るシステムのデータフローのさらなる詳細を示しており、ユニットエンティティ及びフィールドエンティティを含んでいる。上述したとおり、フィールドはフィールドの名前、タイプ及び長さのルックアップ表であり、明細のタイプを参照するためにオファー及び要求エンティティにおいて使用される；そしてユニットはオファー及び要求エンティティにおいて数字の単位を表すために使用されるルックアップ表である。ユニットエンティティ及びフィールドエンティティは双方共に、オファー入力プロセス、図１０ａの要求入力プロセス、並びに図１０ｂの比較プロセスに関与している。ユーザにより入力された要求は、オファーとして処理することもでき、それによって他のユーザは彼のニーズを知ることができる。システムにおいて、ユーザのオファーは他のユーザにとっては、要求でもあり、また、彼の要求は他のユーザにとってオファーでもある。
【００４６】
図１１は本発明の具体例に係る図１に示されたオファー生成プログラムを実行することによって生まれたデータベースにおけるオファーを生成する手順のフローチャートを示している。図１０に示されるように、ユーザがオファーをシステムに入力する際、入力されたオファー固定情報が抽出され図４において示される需要−供給属性のステータスに従って需要かあるいは供給かが決定される。もしそれが需要であれば、その情報は需要としてセットされる；そしてもしそれが供給であれば、それは供給としてセットされる。次のステップでは、オファーがオファーデータベースにおいて生成される。その後、それはさらに多くの属性があるかどうか判断され、もしあれば、フィールド及びユニットを使用して属性情報が得られ、データベースのオファー属性エンティティにおいて属性が生成され、そしてまたさらなる属性があるかどうか決定する判断段階にもどる；もしさらに属性がなかった場合は、終了する。
【００４７】
図１２は本発明の具体例に係るデータベースにおける要求生成のための手順のフローチャートを示している。図１２に示されるとおり、ユーザが彼の要求を入力する際、まず最初に、入力された要求固定情報が抽出され、それが需要かあるいは供給か決定され、もしそれが需要である場合は、この情報は需要としてセットされる；そしてもしそれが供給である場合は、供給としてセットされる。次のステップでは、要求は要求データベースに生成される。次のステップでは、それはさらに多くの属性があるかどうか判断され、もしあれば、フィールド及びユニットを使用して属性情報が得られ、データベースの要求属性エンティティにおいて属性が生成され、そしてまた判断段階にもどる；もしさらに属性がなかった場合は、要求と他のユーザによってデータベース内に保存されているオファーとをマッチさせるためのマッチング処理に行く。
【００４８】
図１３はユーザによって入力された要求とデータベースのオファーエンティティに保存されているオファーとをマッチさせるための手順のフローチャートを示している。図１３に示されているとおり、マッチングプロセスにおいては、まず最初に、ユーザがクライテリアを入力することができる手続きから要求情報が取り出され、図１４に示された手順により、システムによってこの要求が処理される。次のステップはデータベースよりオファーを得て、要求におけるフィールドをオファーにおけるフィールドとマッチさせ始めることである。新しいオファーあるいは要求を得る前の両方のケースにおいて、システムは何かあるかどうかチェックする。オファー、要求共に属性を有しており、属性は特定及び個別のＩＤをともなう情報のかけらである。もし要求の属性のＩＤがオファーのＩＤにマッチすると、システムはオファー属性が要求のなかの一つにマッチするかどうかチェックし、それに基づいてこのマッチの得点が生み出され、マッチング結果に対するユーザの満足度が示される。全てのサイクルの最後にもしオファーの得点がＭＡＬ値に達した場合、それは結果セットに入ることであろう。図３に示されるとおり、一つのサーチのマッチング結果のマッチレベルは、フルマッチ、包含的マッチ、パーシャルマッチ、あるいはノーマッチとなることができる。
【００４９】
サーチクライテリアを処理するための手順Ａは図１４に示されており、この手順においては、クライテリアがコンプレックスなものかどうか判断される。もしそうであれば、属性−ＩＤは属性の入力されたフィールドに入れられ、関係をセットされる；もしそうでなければ、属性の入力されたフィールドにおけるユーザ特定フィールドに入れられ、関係をセットされる。その後、要求属性においてエントリが生成されコンプレックス判断段階へ返される。
【００５０】
本発明の多要素の確信度付きマッチングシステムを使用し、ユーザがオファーを入力すると、データベースにおいてオファー及びオファー属性を生成するためにオファー生成プログラムが図１１の手順を実行する。ユーザが彼のサーチクライテリアを入力すると、サーチエンジンがデータベース内に要求及び要求属性を生成し、図１３及び１４のマッチング処理を実行する。特に、ユーザがクライテリアを特定した後は、システムはそれを分析し要求エンティティのエントリを生成する。各単一のクライテリアはエンティティにおいてエントリを有し、システムもまた他の条件の結果である各条件にエントリを生成する。このことは以下の例においてさらに説明される。結果については、結果のタイプを特定する二つの主な要素があり、一つはユーザが特定する全ての条件に与える重みであり、もう一つは、特定される範囲があるかどうかにほとんど依存している、ユーザがクライテリアをアレンジする方法である。システムが最初にすることは、クライテリアを単一のステップに分解し、コンプレックスクライテリアに基づいた新しいステップを生成することである。
【００５１】
本発明による多要素の確信度付きマッチングシステム及びその方法は、本発明の具体例に従って詳細に以下のように説明される：
【００５２】
サーチクライテリアは次のようである：

次の順序のように評価がおこなわれる：

【００５３】
手順及び対応する演算は次の表９に示されている。
【００５４】
【表９ａ】

【００５５】
評価あるいはマッチの結果表は以下に示されている。

【００５６】
ノーマッチの結果はユーザクライテリア及び重みに基づいたパーシャルマッチの可能性に依存しており、言い換えれば、ノーマッチはユーザのニーズにより関係のあるものとなる。
【００５７】
もし正の結果が出なければ、それはノーマッチとなるが、正の結果が出れば、ユーザが全てのクライテリア及び最低受入可能レベルに与える重みによって、全ての結果はパーシャルマッチとなり、結果の満足度が測られる。
【００５８】
上記の例において、「３」及び「８」は誤であり「６」及び「７」は正である。それぞれの重みに従って、このサーチの得点は次のようになる。

【００５９】
もし、許容最低得点が５５以上である場合、このサーチ結果は不満足、すなわち、ノーマッチとなるであろう。しかし、許容最低得点が５５以下であるような他の基準では、部分的な満足となる。もちろん、得点が１００であるならば、その結果はフルマッチとなるであろう。
【００６０】
もし、いずれかの基準が範囲を含むものである場合、その結果は誤、あるいは、その結果は包含的となる。
【００６１】
上記の記載から分かる通り、本発明においては、「ノーマッチ」の概念は相対的なものであり、もし、許容最低レベルがより大きい値、又は、小さい値に設定されるならば、サーチ結果、すなわち、ユーザが獲得する情報は異なるものとなる。言い換えると、許容最低レベルはユーザによって修正可能なものであり、そして、システムは許容最低レベル値としてデフォルト値を採るであろうとしても、期待のレベルによって、ユーザがそれを増加したり、あるいは、減少したりすることができる。従って、ユーザは、サーチ基準の各要素に対してユーザが付与した重みを調節して、ユーザが必要とするものとしてユーザが利用することができる情報を変化させることができる。
【００６２】
本発明のシステムがどのように動作するのかを示すため、以下に、詳細な実例を紹介する。
【００６３】
例えば、ユーザが、価格が＄１００以下で、色が白又は青であるテニスシューーズを探しているものと特定したものとする。そして、さらに、色がとても重要であるので、色に対して重みを１００中８０を与えると特定したものとする。システムは、条件を評価しながら全ての白又は青のシューズをパーチャルマッチとして許容し、＄１００以下のものをフルマッチとして許容する。
【００６４】
図１５は、本実例に対するユーザ条件を特定するため、当該ユーザに対して与えられたインターフェイスの一例を示している。システムのユーザであるトレーダが供給オファーを探しており、図１５に示されたような条件を含む要求を作成したとする。
【００６５】
この実例におけるサーチ条件は：
（色＝白又は色＝青）且つ価格＜１００、で（色＝白又は色＝青）の重みが８０、そして、価格＜１００の重みが２０である。
【００６６】
システムは、この条件を以下のような順序で処理し始める。

この実例に関係するエンティティは：
【００６７】
【表９ｂ】

【００６８】
【表１０】

【００６９】
【表１１】

【００７０】
【表１２】

【００７１】
「フィールド−ＩＤ」及び「フィールド−ユニット−ＩＤ」の内容はルックアップ表から得られる。これらの表は、オファー及び要求を作成する時に使用される。
【００７２】
【表１３】

【００７３】
【表１４】

【００７４】
システムは、要求の属性を順番に且つそれらに与えられた重みに従って評価し始める。このサーチの論理上の結果は、最後のステートメント（５）が誤の出力であるからノーマッチである。しかしながら、最初の条件にユーザが付与した重み、価格範囲が包含的であることが特定されていること、さらに、サーチの得点が１００中８０であることを考慮に入れ、システムはその結果をパーシャルマッチと認定し、ユーザにこのオファーを送信する。
【００７５】

【００７６】
産業上の利用可能性
本発明の多要素の確信度付きマッチングシステムによれば、このシステムは、個々の条件の重要度レベルをユーザに特定させ且つ包含的マッチングを許容するか否かを特定させることにより、ユーザの選択上の好みを知ることができる。これは、また、本発明の好ましい実施例に係るシステムにおいて、要求（条件）を記録しておくことにより、ユーザが要求を出した後、システムにマッチしたケースが入力された度にユーザに知らせることを実現できる。このように、システムに半人工的な理知を与えるだけでなく、検索の要求が中断されるまで生き続けることとなり、瞬時的な検索要求以上の機能を果たす。
【００７７】
ユーザがシステムに要求を入力すると、マッチングシステムのマッチングプログラムは、ユーザの介在無しに実行し、マッチング結果を瞬時にユーザに返却する。このシステムは、カスタムマッチや非完全なマッチを提供することができ、異なるレベルのマッチング結果を、絞り込みを行うために順番に並べ且つランキングする。これにより、絞り込みされた結果が、ユーザに返却される。本発明システムのユーザは、相互に主体にも客体にもなりうる。国際的な商取引に本発明に係る多要素の確信度付きマッチングシステムを用いることにより、トレーダ又はユーザは調査をより効率的に行うことができ、より有用な情報を獲得することができる。ランク付けされ且つ絞り込みされたサーチ結果は瞬時にユーザに返却される。ユーザはサーチ条件又は要求の各要素に付与される重みを調節することにより、ユーザが必要とする情報を変えることができる。明らかに、多要素の確信度付きマッチングシステムは極めて高効率の電子商取引システムである。そして、システムのユーザが有用な商取引情報を得る助けとなると共に、ユーザのビジネスをより効率的に行うようにする。
【００７８】
さらに、本発明のシステムは、図書館、電子的購買、チケットの予約等の分野でも使用できるものであり、また、その効率を向上させる。
【００７９】
本発明の原理を好ましい実施例に基づいて記載し図示してきたが、本発明はその精神を逸脱することなくその構成・詳細において修正され得るものであることは理解されるべきである。これら全ての修正及び変形は、添付の請求項に含まれるものである。
【図面の簡単な説明】
【図１】本発明に係る多要素の確信度付きマッチングシステムの基本構造を示している。
【図２ａ】図２ａは本発明に係るメインデータのフローチャートを示している。
【図２ｂ】図２ｂは本発明に係るメインデータのフローチャートを示している
【図３】本発明に係るシステムのサーチ結果におけるマッチングレベルを示している。
【図４ａ】本発明に係るデータベースにおけるデータエンティティの構造を示している。
【図４ｂ】本発明に係るデータベースにおけるエンティティ間の関係を示している。
【図４ｃ】図４ｂに示されるキーとなる関係の詳細を示している。
【図５】本発明の具体例に係るインターネットを通じて情報サーバにコミュニケーションするウェブ基礎クライエントを示している。
【図６】本発明の具体例に係るクライエント及びサーバにおけるコンポーネントの詳細を示している。
【図７】本発明の具体例に係るメインオファー選択プロセス中に、技術モジュールがどのように他の拡張可能なデータベースコンポーネントにインターフェイスするのかの詳細を示している。
【図８】本発明の具体例に係る典型的ウェブにおける実行技術及び実行をサポートするために必要とされる追加のコンポーネントを示している。
【図９ａ】図９ａは本発明の具体例に係り図４に示されるデータベース内におけるエンティティの生成を示している。
【図９ｂ】図９ｂは本発明の具体例に係り図４に示されるデータベース内におけるエンティティの生成を示している。
【図９ｃ】図９ｃは本発明の具体例に係り図４に示されるデータベース内におけるエンティティの生成を示している。
【図１０ａ】図１０ａは図２ａ及び２ｂの本発明の具体例に係るシステムのデータフローのさらなる詳細を示している。
【図１０ｂ】図１０ｂは図２ａ及び２ｂの本発明の具体例に係るシステムのデータフローのさらなる詳細を示している。
【図１１】本発明の具体例に係るデータベース内においてオファーを生成する手順のフローチャートを示している。
【図１２】本発明の具体例に係るデータベース内において要求を生成する手順のフローチャートを示している。
【図１３】データベース内においてユーザによって入力された要求とオファーエンティティに保存されたオファーとをマッチングさせるサーチエンジンの手順のフローチャートを示している。
【図１４】図１３のサーチクライテリアを処理するための手順Ａを示している。
【図１５】この例のサーチにおけるユーザのクライテリアを特定するためにユーザに供給されたインターフェイスの例を示している。[0001]
Field of Invention
The present invention is a computer matching system and method thereof, and in particular, a multi-element certainty matching system provided on a database for matching a user request with an offer of another user and returning a matching result to the user. It is related to the electronic commerce system.
[0002]
Background of the Invention
Today, traders are trading in the global trading market and need to trade efficiently and reliably with traders in other countries, so in recent years electronic commerce systems have become more widely used in international trading operations. .
[0003]
At present, a number of electronic commerce systems are used in international trading. For example, EDI (electronic data exchange) is used by traders to exchange offers with specific trading partners. Can not be used to find offers that interest you.
[0004]
There are also trading systems for traders to find the goods they need from other traders, or trading systems to find buyers for their goods, and trading systems to deal with many business-related matters.
The business of the trading system is to match the trader's request with offers published by other traders via the electronic commerce system. This is usually achieved by direct search of user criteria for valid offers and display only simple search results in a general order.
[0005]
In information technology, an attempt to produce the best result in response to a condition (criteria) specified by a user is an old problem. A number of different methods of question and matching systems are being implemented and progressing daily. Most of the systems use technical standardization tools for that purpose, and their flexibility depends on what they can do. Standardized search engines mainly search for search criteria, and the result is zero, one, or multiple cases that match exactly all criteria. Regardless of how many conditions a case meets, if one of the conditions is not met, the case is the result set even if the condition is the least important of the other conditions. Not included. Especially in terms of scope, mainly users want something close to their desires, not exactly matching their desires. In other words, Infomix, Oracle, Sybase, Ingres and other database engines have only two choices (choices) “match” and “no match” in the matching case.
[0006]
In a conventional transaction system, when a user indicates a search criterion, usually a huge amount of information is returned, and the user has to find what he / she is interested in. And if necessary, the user must add more criteria to the criteria, or enter additional search criteria or formulas (formulas) and perform another search to reduce the amount of information returned. . Apparently he has to refine (narrow down) the results by himself until he gets a satisfactory result. He must search from one category to the next, and must read the information displayed on the screen before selecting a new search criterion each time, without user intervention during the search process. The search cannot be performed continuously. On the other hand, if there are too few conditions included in the search criteria, too much information is returned, and most of them are not of interest to him. On the other hand, if there are too many conditions included in the search criteria, the user may not be able to obtain the most important information for him because the unimportant conditions are not satisfied as described above.
[0007]
Therefore, the conventional search system is not convenient for the user to use, and the search cannot be performed efficiently. When a user uses such a system, the time and cost of the search process increases.
[0008]
Summary of the Invention
The purpose of the present invention is to provide a multi-factor certainty matching system, which can automatically provide his or her information of interest to the user or trader without intervention of the trader. Provides the maximum amount of offer information that can meet the requirements of the trader, so that the trader not only offers an exact match to their criteria, but also is close to or part of it, or more than they need You can see things, so the trader can search efficiently.
[0009]
Advantageously, the present invention enhances the sophistication of standard tools and is in line with the user's mind when accepting or rejecting a case. By interposing additional parameters in the user's choice, the system can extend the acceptable range of results, accepting cases that meet the most important conditions based on user preferences and do not meet only unimportant conditions Can be made to do.
[0010]
To achieve the above objects and advantages, the present invention provides a computer matching system and method comprising a database for use by a plurality of users; generating an offer entity entered into the database by each user; Offer generation program means for storing offers in a database; comprising a search engine that compares and matches requests entered by a user with offers from other users stored in the database and returns matching results to the user .
[0011]
In the computer matching system according to the present invention, the request includes a plurality of elements as search criteria, and each element is weighted with importance, and a search score indicating the satisfaction degree of the user is matched with each request. The results have, the search engine further ranks and ranks the matching results according to their respective search scores, and a predetermined satisfaction is only returned to the user for the matching results with search scores Are preferred.
[0012]
The user interface for the matching system is preferably via the Internet.
These and other objects, aspects and advantages of the present invention will become more apparent from the following detailed description of preferred embodiments of the invention with reference to the drawings.
[0013]
Detailed description of preferred embodiments
Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.
FIG. 1 shows a basic structure of a multi-element certainty matching system according to the present invention. As shown in FIG. 1, a multi-factor certainty matching system is used by a plurality of users, a database, an offer generation program for generating offer entities in the database, and a search condition (criteria) input by the user or It has a search engine for comparing requests with offers that exist in the database. When an offer is entered by the user, the offer is processed by the offer generator and stored in an offer entity in the database. Upon receiving a request from a user, the search engine operates to match the request with an offer stored and present in an offer entity in all other users' databases. Matching results can be ranked according to certainty, ie matching level or search score, and matching results are returned to the corresponding user.
[0014]
Users can interface to the multi-factor matching system via the Internet. The database can then include requesting entities that can be virtual.
[0015]
2a and 2b show the diagrammatic principle of the method implemented in the multi-element certainty matching system according to the present invention. As shown in FIG. 2a, the details of the offer entered by each user are written to the offer database, and the search criteria, i.e. the request entered by that user is matched by the operation of the matching program or the search engine of FIG. Sent to the process, the matching process compares the request with the details of the offers stored in the offer database from all other users, thereby returning the matching offer list to the user.
[0016]
The matching process performed in the matching process is shown in detail in FIG. 2b. As shown in FIG. 2b, first of all, a search criteria, ie a request containing a plurality of conditions or elements entered by a user, is compared with an offer from an offer database. Since each condition is weighted to indicate its importance, each matching result has a search level indicating the user's satisfaction. The comparison result is 5 There are levels, such as full match offer, subset match offer, partial match offer, super set match offer and no match offer. The comparison results have a lower matching degree in order, and a matching result having a level higher than the minimum acceptable level (MAL) set by the user is returned to the user. The above process is performed automatically by a multi-factor confidence matching system when a user enters a request, and the matching result is returned to the user, so that the user can instantly get an offer that satisfies his request. And more advantageously, the matching results include not only perfect matches that meet the user's criteria 100% but also partial match or inclusive match results.
[0017]
In the field of trading, offers can be buys (demand) or cells (supply), while requests can be buys or sells. Thus, if the request is a demand, it is compared to the supply offer in the database; if the request is a supply, it is compared to the demand offer in the database.
[0018]
FIG. 3 shows the matching level of the search result in the system according to the specific example of the present invention. As shown in FIG. 3, the matching results are ranked and ranked according to their levels, and the matching result set can be constructed by order and level, where level 1 is a perfect match, ie a full match, that is Means that the input demand A was exactly the same as the supply set; level 2 is an inclusive match, supply set B contains the input demand A, ie set B is a set Contains only part of A; level 3 is a partial match, set A and set B have overlapping parts; level 4 is also an inclusive match, but supply set B is input Level 5 is no match and there is no intersection between set A and set B.
[0019]
Each search criteria or request may include a number of factors such as product, market position (buyer or seller, or both) offer date, delivery date, offerer, price and quantity. The offer can contain the same elements as the request to be compared with the request. Each element of the request is compared to that of the offer in the database, and each flow of the process of matching the corresponding element can be weighted by the user. Of the above match 5 Each level has a weighted result score by the user, from a full level 1 match, 5 Until no match, the score decreases from 100% to 0%.
[0020]
FIG. 4a shows the structure of the data entity in the database according to the invention. In the database, there is a user entity, which is a member of the system and generates and owns requests and offers. User information stored in the user entity is mainly flat, unprocessed user data, and is obtained by an interface usable by the user. The request is a virtual entity and is also referred to as a search criterion as described above. In traditional activities, criteria information entered by the user is not stored in the database, but if that information is used for later announcement and trigger systems, the criteria is stored in a real entity. Will. As shown in FIG. 4a, the request entity has an ID and attributes including the request ID, data, and relationship. Request-attributes are used to store information about individual parts of the request. During the process of generating a request, the system can create a new entry for this entity called the complex attribute, which is configured by the result of the previous one attribute. The offer entity stores the offer of the user for supply or demand, this entity stores the ID and a fixed part of the offer, ie product description or information of any other part not related to the criteria and search process, and The offer attribute stores the variable part of the offer and indicates the attribute of the offer. Here, the variable part relates to attributes such as price, color, material, and criteria.
[0021]
In addition, the database includes fields for storing field information and unit entities for unit information.
The definitions of the above entities are shown in Table 1 below.
[0022]
[Table 1]

[0023]
Despite the request and offer entities containing similar information, their actions are different. The offer entity stores information about fixed demand or supply, user supply or request. This information is tested by the system each time a request (search criteria) is submitted. The request includes conditions specified by the user and includes a range. The request is a virtual entity, which does not need to be stored in the real entity after the process is finished.
[0024]
Field and unit entities are tables used to generate offer and request attributes.
[0025]
FIG. 4b shows the relationship between entities in a database according to an embodiment of the present invention. As shown in FIG. 4b, each user has a record in the user entity, and each user has no more than one entry. Each user has 0, 1 or more requests, and these requests are tied to the user's entry. Each user can generate 0, 1 or more demand or supply offers. Each offer / request has one or more attributes. All attributes point to field entity entries to indicate the type of field. All attributes then point to unit entity entries to identify the unit type.
[0026]
FIG. 4c shows details of the key relationships of the entities shown in FIG. 4b, and a detailed description of the corresponding attributes of the different entities is shown in Tables 2-8 below.
[0027]
[Table 2]

[0028]
[Table 3]

[0029]
[Table 4]

[0030]
[Table 5]

[0031]
[Table 6]

[0032]
[Table 7]

[0033]
[Table 8]

[0034]
FIG. 5 shows a web basic client communicating with an information server through the Internet according to an embodiment of the present invention. The matching system according to the present invention has an open structure and can be used in various environments, but the Internet is used in the international trading market. The matching system is located in a server on the Internet, and the user can connect to a server having the matching system through a web browser as shown in FIG. The server may be from Sun Microsystems Unix or Intel Microsoft NT. The client can be a personal computer running a Microsoft Windows 95 operating system, an Apple Macintosh running an Apple Mac OS, or a Sun Microsystems workstation running Unix. The extensible database management system used for the database of the present invention may be Infomix or Oracle products. Plug-in modules that can be used for the above databases can include Verity, Excalibur or Village.
[0035]
FIG. 6 shows the details of the components in the client and server according to the embodiment of the invention in FIG. As shown in FIG. 6, each client has an operating system, local information and application basic savings content, a web browser for performing web basic applications and browsing pages in HTML format, and network transfer to connect to a global network. Has a part. A server having a multi-factor certainty matching system includes an operating system, a database and a mass storage device that stores common information and applications, a scalable database engine that provides database services and responds to client requests, and It includes a web server that provides web services and a network forwarding unit. The extensible database engine is used for services to clients related to client questions and database service requests, and consists of database tables, SQL functions, and extensible modules. The extensible modules include third party matching (data matching by applications created by other software companies) engines, web deployment / transfer modules for using existing standard services, and ad hoc multi-factor confidence It consists of core technology modules to add matching system functions with degree.
[0036]
FIG. 7 shows the core technology module and the structure that leads to the third party matching engine and the SQL function. The core technology module includes a matching engine for comparing requests with offers stored in the offer database, a custom matching component, and an ordering and ranking module. Here, custom matching is data matching that has been implemented in addition to existing functionality and third party technology, such as inclusive matching, ie, the amount of items supplied is greater than required.
[0037]
As shown in FIG. 7, the details of the request and offer are sent to the matching engine, and the matching engine and custom matching component compare the request with the offer by means of a third party matching engine. The third-party matching engine includes verity text and excalibur text, as well as SQL features such as equal (=), similar, less (<), and greater (>). The matching results issued by the matching engine are then sent to the ordering and refinement module, ranked according to the confidence or score each matching result has, and their own refinement criteria, for example, the first 5 in the exact match and price order. The amount of data is narrowed down based on things such as showing only limited data, and sent to the user. If the matching score does not reach the lowest acceptance level, the results are discarded and the ranked and refined matching offer set is sent back to the user.
[0038]
FIG. 7 shows an independent interface. This figure is the same whether execution is via a client server, web-based or just a terminal character interface. All types of user interfaces can generate requests, match existing offers, and create result sets.
[0039]
All of the above processes take place from within the core technology extension module and interface to the core database engine and any other installed extension module.
[0040]
FIG. 8 illustrates a typical web execution technique of a multi-element certainty 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 includes structural details for identifying server behavior, internal functions for providing basic services, custom functions for users, and application identification. It consists of a service and standard HTML data, and a transfer engine that integrates standard HTML pages and search engine results. The HTML form containing the request from the user is sent to the transfer engine. The transfer engine sends all requested data to other modules. The web deployment and transfer module includes web page storage and web page transfer. These modules are responsible for application logic, standard HTML invariant content (contents) and actual data variable content (contents), results of questions to the database, and variables. Web page transfer communicates using internal functions and modules and SQL.
[0041]
Figures 9a, 9b and 9c illustrate the generation of entities in the database shown in Figure 4 according to an embodiment of the invention. In FIG. 9a, during the creation of an offer entity, firstly, the fixed information of the offer is entered into the system that creates the offer at the offer entity. Attribute information is also introduced from the field and unit entities to generate attributes in the offer attribute entity.
[0042]
In FIG. 9b, when creating a user entity, first the user information is entered into the system, the user profile is also entered, and then a user record is created at the user entity. Each user stores a user record in the user entity.
[0043]
FIG. 9c shows the generation of the request entity. As shown in FIG. 9c, when generating a request, first, request fixing information is entered into the system and typed as either a demand or supply request. Thereafter, field information is retrieved instead using field and unit entities. At the end of this process, a request fixed information entry and one or more attribute information entries are generated.
[0044]
A detailed description of the relevant entries is in Table 2-8.
[0045]
FIGS. 10a and 10b show further details of the data flow of the system according to the embodiment of the invention in FIGS. 2a and 2b, including unit entities and field entities. As mentioned above, the field is a lookup table of field names, types and lengths, used in the offer and request entity to refer to the type of specification; and the unit is a numeric in the offer and request entity unit Is a lookup table used to represent Both the unit entity and the field entity are involved in the offer input process, the request input process of FIG. 10a, and the comparison process of FIG. 10b. The request entered by the user It can also be processed as an offer, which allows other users to know his needs. In the system, the user's offer is also a request for other users, and his request is also an offer for other users.
[0046]
FIG. 11 shows a flowchart of a procedure for generating an offer in a database born by executing the offer generation program shown in FIG. 1 according to an embodiment of the present invention. As shown in FIG. 10, when a user inputs an offer to the system, the input offer fixed information is extracted to determine whether it is demand or supply according to the status of the demand-supply attribute shown in FIG. If it is demand, the information is set as demand; and if it is supply, it is set as supply. In the next step, an offer is generated in the offer database. It is then determined if there are more attributes, if any, attribute information is obtained using fields and units, attributes are generated in the offer attribute entity of the database, and if there are more attributes Return to the decision stage to determine; if there are no more attributes, exit.
[0047]
FIG. 12 shows a flowchart of a procedure for request generation in a database according to a specific example of the present invention. As shown in FIG. 12, when the user enters his request, first the entered request fixed information is extracted to determine whether it is demand or supply, and if it is demand, This information is set as a demand; and if it is a supply, it is set as a supply. In the next step, a request is generated in the request database. In the next step, it is determined whether there are more attributes, if any, attribute information is obtained using fields and units, attributes are generated in the request attribute entity of the database, and also in the decision stage. If there are no more attributes, go to the matching process to match the request with the offer stored in the database by another user.
[0048]
FIG. 13 shows a flowchart of a procedure for matching a request entered by a user with an offer stored in an offer entity in the database. As shown in FIG. 13, in the matching process, first, request information is extracted from a procedure in which a user can input criteria, and the request is processed by the system according to the procedure shown in FIG. Is done. The next step is to get the offer from the database and start matching the fields in the request with the fields in the offer. In both cases before getting a new offer or request, the system checks for something. Both offers and requests have attributes, which are pieces of information with specific and individual IDs. If the ID of the request attribute matches the ID of the offer, the system checks whether the offer attribute matches one of the requests, and based on that, a score for this match is generated and the user's satisfaction with the matching result Degree is shown. At the end of every cycle, if the offer score reaches the MAL value, it will enter the result set. As shown in FIG. 3, the match level of a search result of one search can be full match, inclusive match, partial match, or no match.
[0049]
A procedure A for processing the search criteria is shown in FIG. 14, and in this procedure, it is determined whether or not the criteria is complex. If so, the attribute-ID is placed in the attributed field and the relationship is set; otherwise, it is placed in the user specific field in the attributed field and the relationship is set. The Thereafter, an entry is generated in the request attribute and returned to the complex determination stage.
[0050]
Using the multi-factor certainty matching system of the present invention, when the user enters an offer, the offer generation program performs the procedure of FIG. 11 to generate offers and offer attributes in the database. When the user enters his search criteria, the search engine generates a request and request attributes in the database and performs the matching process of FIGS. In particular, after the user has identified the criteria, the system analyzes it and generates an entry for the requesting entity. Each single criterion has an entry in the entity, and the system also creates an entry for each condition that is the result of other conditions. This is further illustrated in the following example. For results, there are two main elements that specify the type of result, one is the weight given to all conditions specified by the user, and the other is largely dependent on whether there is a specified range. This is a way for users to arrange criteria. The first thing the system does is break down the criteria into a single step and generate a new step based on the complex criteria.
[0051]
The multi-element certainty matching system and method according to the present invention will be described in detail as follows according to an embodiment of the present invention:
[0052]
The search criteria are as follows:

Evaluation is done in the following order:

[0053]
procedure And corresponding Calculation Is shown in Table 9 below.
[0054]
[Table 9a]

[0055]
The evaluation or match results table is shown below.

[0056]
The result of no match depends on the possibility of partial match based on user criteria and weight, in other words, no match is more relevant to the user's needs.
[0057]
If there is no positive result, it will be a no match, but if a positive result is obtained, all the results will be a partial match depending on the weight given to all criteria and minimum acceptable levels by the user, and the satisfaction of the result will be Measured.
[0058]
In the above example, "3" and "8" are incorrect And "6" and "7" are positive It is. According to each weight, the score of this search is as follows.

[0059]
If the minimum acceptable score is 55 or more, this search result will be unsatisfactory, ie no match. However, other criteria where the minimum acceptable score is 55 or less are partially satisfactory. Of course, if the score is 100, the result will be a full match.
[0060]
If any criterion includes a range, the result is false or the result is inclusive.
[0061]
As can be seen from the above description, in the present invention, the concept of “no match” is relative, and if the allowable minimum level is set to a larger or smaller value, the search result, ie The information acquired by the user is different. In other words, the minimum acceptable level can be modified by the user, and even if the system will take the default value as the minimum acceptable level value, depending on the level of expectation, the user may increase it, or It can be reduced. Therefore, the user can change the information that the user can use as what the user needs by adjusting the weight given by the user to each element of the search criteria.
[0062]
In order to show how the system of the present invention operates, a detailed example is introduced below.
[0063]
For example, it is assumed that the user specifies that he / she is looking for tennis shoes with a price of $ 100 or less and a color of white or blue. Further, since the color is very important, it is assumed that 80/100 is given a weight for the color. The system will allow all white or blue shoes as a partial match while evaluating the conditions, and allow a full match if it is $ 100 or less.
[0064]
FIG. 15 shows an example of an interface given to the user in order to specify the user condition for this example. Assume that a trader who is a user of the system is looking for a supply offer and has created a request that includes the conditions as shown in FIG.
[0065]
The search conditions in this example are:
(Color = white or color = blue) and price <100, weight of (color = white or color = blue) is 80, and weight of price <100 is 20.
[0066]
The system begins to process these conditions in the following order:

The entities involved in this example are:
[0067]
[Table 9b]

[0068]
[Table 10]

[0069]
[Table 11]

[0070]
[Table 12]

[0071]
The contents of “Field-ID” and “Field-Unit-ID” are obtained from the lookup table. These tables are used when creating offers and requests.
[0072]
[Table 13]

[0073]
[Table 14]

[0074]
The system begins to evaluate the attributes of the request in order and according to the weights given to them. The logical result of this search is no match because the last statement (5) is an erroneous output. However, taking into account that the weight and price range given by the user to the first condition are specified to be inclusive, and that the search score is 80 out of 100, the system will return the result to partial Authenticate a match and send this offer to the user.
[0075]

[0076]
Industrial applicability
According to the multi-factor certainty matching system of the present invention, this system allows the user to specify the importance level of each condition and whether to allow inclusive matching or not. You can know the taste above. This is also because in the system according to the preferred embodiment of the present invention, by recording a request (condition), a case that matches the system was input after the user made a request. Every time To the user Realize to inform it can. In this way, not only gives the system a semi-artificial intelligence, Stay alive until search request is interrupted That means More than an instant search request .
[0077]
When the user inputs a request to the system, the matching program of the matching system is executed without user intervention, and the matching result is instantly returned to the user. The system can provide custom matches or incomplete matches, and the different levels of matching results are ordered and ranked for refinement. Thereby, the narrowed-down result is returned to the user. Users of the system of the present invention can be both subjects and objects. By using the multi-factor certainty matching system according to the present invention for international business transactions, a trader or a user can conduct a survey more efficiently and obtain more useful information. The ranked and refined search results are immediately returned to the user. The user can change the information required by the user by adjusting the weight given to each element of the search condition or request. Clearly, the multi-element matching system with confidence is an extremely efficient electronic commerce system. And it helps the user of the system to obtain useful business transaction information and makes the user's business more efficient.
[0078]
Furthermore, the system of the present invention can be used in the fields of libraries, electronic purchases, ticket reservations, etc., and improves its efficiency.
[0079]
While the principles of the invention have been described and illustrated with reference to a preferred embodiment, it is to be understood that the invention can be modified in construction and detail without departing from the spirit thereof. All these modifications and variations are intended to be included within the scope of the appended claims.
[Brief description of the drawings]
FIG. 1 shows the basic structure of a multi-element certainty matching system according to the present invention.
FIG. 2a shows a flowchart of main data according to the present invention.
FIG. 2b shows a flow chart of main data according to the present invention.
FIG. 3 shows matching levels in search results of the system according to the present invention.
FIG. 4a shows the structure of a data entity in a database according to the invention.
FIG. 4b shows relationships between entities in the database according to the present invention.
FIG. 4c shows details of the key relationships shown in FIG. 4b.
FIG. 5 shows a web basic client communicating to an information server through the Internet according to an embodiment of the present invention.
FIG. 6 shows details of components in a client and server according to an embodiment of the invention.
FIG. 7 shows details of how the technology module interfaces to other extensible database components during the main offer selection process according to an embodiment of the present invention.
FIG. 8 illustrates an exemplary web execution technique and additional components required to support execution according to an embodiment of the present invention.
9a shows the creation of entities in the database shown in FIG. 4 according to an embodiment of the invention.
9b shows the creation of entities in the database shown in FIG. 4 according to an embodiment of the present invention.
9c illustrates the creation of entities in the database shown in FIG. 4 according to an embodiment of the present invention.
FIG. 10a shows further details of the data flow of the system according to the embodiment of the invention of FIGS. 2a and 2b.
FIG. 10b shows further details of the data flow of the system according to the embodiment of the invention of FIGS. 2a and 2b.
FIG. 11 shows a flowchart of a procedure for generating an offer in a database according to an embodiment of the present invention.
FIG. 12 shows a flowchart of a procedure for generating a request in a database according to an embodiment of the present invention.
FIG. 13 shows a flow chart of a search engine procedure for matching a request entered by a user in a database with an offer stored in an offer entity.
14 shows a procedure A for processing the search criteria of FIG.
FIG. 15 shows an example of an interface provided to the user to identify the user criteria in the search of this example.

Claims

A computer commerce matching system used by multiple users,
An offer database that stores a plurality of user offers that are input by the plurality of users and each include a plurality of elements, and a field entity that stores data for identifying the names of the plurality of elements, and the plurality of fields An offer database in which a unit entity in which data for specifying each unit of the elements is stored is created ;
Creating an offer entity in the offer database for each of the input user offers, identifying the names and units of the plurality of elements using the field entity and the unit entity, and An offer generator means for associating an offer with one of a supply and a supply and storing it in said offer entity ;
Request input program means for receiving, as a search condition, a user request including a plurality of elements that specify whether inclusive matching is permitted or not, which is input from a user via a user-side interface. Request input program means for assigning importance weights to each of the elements and associating said user request with one of demand and supply ;
A search engine that receives the user request from the request input program means and compares and matches the user request with the plurality of user offers stored in the offer database, the search engine comprising a demand request and a supply The user request and the plurality of user offers are compared by offer matching and supply request and demand offer matching, and based on satisfaction of each element set by the user adjusting the importance of each element in advance. A search engine that returns only matching results having a search score exceeding a set matching level to the user ,
The offer generation program means processes the user request as a user offer and stores it in the offer database;
The user request is searched by the search engine as a user offer Computer commerce matching system.

Each user offer or user request is selected from a group consisting of at least (a) demand, (b) supply, (c) product name, (d) product quantity, and (e) product price. The computer commerce matching system according to claim 1, comprising at least one item.

The computer commerce matching of claim 1 , wherein after the user inputs the user request, a search request according to the user request is kept valid in the search engine and is communicated to the user when a match occurs. system.

A computer commerce matching method for matching a request of one user with an offer from another user,
(A) A field entity in which an offer database for storing a plurality of user offers input by a plurality of users is provided, and data for specifying names of a plurality of elements included in each of the user offers is stored Creating a unit entity in which data for specifying each unit of the plurality of elements is stored in the offer database ;
(B) For each entered user offer, create an offer entity in the offer database, identify the names and units of the plurality of elements using the field entity and the unit entity, Associating a user offer with one of supply and demand and storing in the offer entity ;
One user through (c) user-side interface entered, the user request including a plurality of elements to identify whether tolerate an inclusive matching, takes as a search condition, the plurality of in the user request Weighting each of the elements with importance and associating said user request with one of supply and demand ;
(D) comparing and matching the user request with a plurality of user offers stored in the offer database by matching a demand request with a supply offer and matching a supply request with a demand offer ;
(E) Only one matching result having a search score exceeding a preset matching level based on the satisfaction level of each element set by adjusting the importance of each element by the one user is given to the one user. Including the step of returning,
The user request is processed as a user offer in step (b), stored in the offer database, and searched in step (d) .

A computer commerce matching method for matching a request of one user with an offer from another user,
(A) A field entity in which an offer database for storing a plurality of user offers input by a plurality of users is provided, and data for specifying names of a plurality of elements included in each of the user offers is stored Creating a unit entity in which data for specifying each unit of the plurality of elements is stored in the offer database ;
(B) For each entered user offer, create an offer entity in the offer database, identify the names and units of the plurality of elements using the field entity and the unit entity, Associating a user offer with one of supply and demand and storing in the offer entity ;
(C) receiving, as a search condition, a user request that includes a plurality of elements that specify whether inclusive matching is permitted, input by a single user via a user-side interface, and the plurality of elements in the user request Weighting importance of each and associating said user request with one of supply and demand ;
(D) comparing and matching the user request with a plurality of user offers stored in the offer database by matching a demand request with a supply offer and matching a supply request with a demand offer ;
(E) Only one matching result having a search score exceeding a preset matching level based on the satisfaction level of each element set by adjusting the importance of each element by the one user is given to the one user. Including the step of returning,
Step (d) further includes ranking and ranking the matching results according to a search score,
The user request is processed as a user offer in step (b), stored in the offer database, and searched in step (d) .

The user request includes a plurality of elements each weighted with importance as a search condition, and each matching result has a search score indicating satisfaction of the user,
6. The computer commerce matching method according to claim 5, wherein step (d) further comprises ranking and ranking the matching results according to a search score.

Each user offer or user request is at least one selected from the group consisting of (a) demand, (b) supply, (c) product name, (d) product quantity, and (e) product price. The computer commerce matching method according to claim 5, comprising items.

The computer commerce matching according to claim 5 , wherein after the user inputs the user request, a search request according to the user request is effectively maintained in the search engine and the user is notified when a match occurs. Method.