JP2000099572A - 取引仲介システムにおけるベンダ候補特定方法 - Google Patents

Abstract

(57)【要約】 【課題】本発明は潜在的なベンダを含めベンダを特定す
るための方法を提供することを目的とする。 【解決手段】ベンダ候補特定装置を用いて、多量の取引
情報のなかから特定の取引関係しか有さず、一般には商
品を販売しない潜在ベンダや、クライアントが製品情報
を取得していない潜在ベンダを含めたベンダ候補を特定
する。特定されたベンダ候補の納入実績情報を付加しク
ライアントに潜在ベンダ情報を送付する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、各社の商品の取引
伝票を一元的に格納した取引情報データベースから、購
買する商品を扱う伝票データを特定し、ベンダ候補を特
定する方法に関する。

【０００２】

【従来の技術】インターネットの商用利用が解禁される
にともなって、広域VAN上で行われていた企業間の商取
引がインターネット上でもおこなうことが可能になっ
た。インターネット上で商取引をおこなうことは、セキ
ュリティが守られない危険性があったが、セキュアコマ
ースプロトコルなどの開発によってその問題も解決され
つつある。取引形態に関しては、広域VAN上での固定化
された１対多の商取引関係が、インターネットを用いた
多対多の商取引に移行することになった。

【０００３】企業間電子商取引市場におけるプロバイダ
は取引に参加できる企業と商品を管理している。プロバ
イダに許可された企業だけが商取引を行える。取引情報
はプロバイダが提供するネットワークを経由する仕組み
となっている。プロバイダが取引情報を全て蓄積するこ
とで、取引情報の信頼性の確保を行っている。企業間電
子取引市場においてはクライアントはベンダ企業が提供
する電子カタログの商品情報を照会し、各社の商品デー
タを自社のデータベースに蓄積する。または、プロバイ
ダの用意するデータベースにベンダ企業が商品情報を登
録する。これらのデータベースに対して、納入リードタ
イム、価格などの検索条件を指定し、要求にあった商品
を提供するベンダを特定する。

【０００４】

【発明が解決しようとする課題】しかしながら、従来に
おいては、クライアントが逐次各商品のデータを検索す
る手間がかかった。また、他社の取引情報は企業の営業
秘密であるため、クライアントはそれを照会することが
できず、ベンダが提供する電子カタログなどの商品情報
の比較することでしかベンダを特定する情報がない。ま
た、商品情報を提供しないベンダの情報はクライアント
は検索することができない。ベンダを指定できない公開
入札のような取引形態においては、ベンダ企業が自主的
に受注を決定してくれないとクライアントは商品が調達
できるのか、どうかの判断をたてることができない。商
品情報を提供しないベンダは商品を特定の納入先に納め
ているため新たな顧客を求めていないだけであり、商品
在庫は有している場合があり、潜在的なベンダとなって
いる。また、自社が取引していない新たなベンダの電子
カタログをクライアントは逐次収集するが、新しく発行
された電子カタログなどは収集し損なっていたりする。
製品情報が入手されていないベンダは潜在ベンダとなっ
てしまう。

【０００５】本発明の目的は、潜在的なベンダを含めベ
ンダを特定するための方法及びそのためのデータベース
作成方法を提供することにある。

【０００６】

【課題を解決するための手段】本発明は企業間電子取引
市場におけるプロバイダが蓄えた多様なフォーマットの
取引情報のデータを統一されたフォーマットのテーブル
データに変換して取引情報データベースに蓄積し、ベン
ダ候補特定装置を用いることで潜在ベンダ特定するため
の情報を作成することを特長とする。プロバイダが潜在
ベンダを含めたベンダ候補の情報をクライアントに提供
する。

【０００７】プロバイダが蓄積している取引情報は統一
的なフォーマットで蓄積されていない。取引情報にはCI
I,EDIFACT,EIAJなどの取引情報標準規格が存在する。そ
こで、プロバイダは取引情報を規格毎に分別し、共通の
データ項目のレコードに取引情報を変換し蓄積する。各
規格の取引情報をプロバイダが用意するフォーマットに
データを変換し取引情報をデータベースに蓄積する。そ
の取引情報とクライアントの入力情報を基に、プロバイ
ダはクライアントが要望する商品を類似語辞書を用いて
特定する。プロバイダはその商品が取り扱われている取
引伝票を取引情報データベースから抽出し、ベンダを特
定する。

【０００８】ベンダ特定の一例として、プロバイダは商
品の取引形態が一定期間確立しているか、取引関係が商
品の取引形態と一致するかを考慮することで潜在ベンダ
を含むベンダを特定する。この特定方法は潜在ベンダを
特定しやすいように考案されているが、他の特定方法を
用いてもベンダを特定することができる。この特定方法
では、取引されている商品が定期発注品または定量発注
品であるかを区別し取引形態が確立しているかを判定す
る。また、ベンダの取引先数、取引高を把握しベンダの
取引関係が商品の取引形態と合致するか判定することで
取引の信頼性を確保する。

【０００９】以上の判定の結果、多量の取引情報のなか
から、特定の取引関係しか有さず一般には商品を販売し
ない潜在ベンダやクライアントが製品情報を取得してい
ない潜在ベンダを含めたベンダ候補を特定する。特定さ
れたベンダ候補の納入実績情報を付加しクライアントに
潜在ベンダ情報を送付する。

【００１０】上記のベンダ候補特定方法によれば、クラ
イアントは購買したい商品を扱っているベンダを特定す
ることができる。電子カタログを発行していないベンダ
や、新たに出現したベンダを定期的にプロバイダに教え
てもらうこともできる。プロバイダは取引の実績情報を
基にベンダの特定ができるため、ベンダ企業の実情を把
握した上でベンダの優先順位づけをおこなうことができ
る。プロバイダが提供するベンダ情報はベンダの営業秘
密である数量情報、金額情報をもらさない限りにおいて
クライアントに与えることができる。プロバイダが提供
する情報はクライアントが独自に収集する情報よりも情
報の精度が高いので、情報提供の対価をクライアントか
ら徴収することもできる。

【００１１】

【発明の実施の形態】本発明のブロック図を図１に示
す。符号１の端末はクライアントが購買したい製品に関
する要求事項のデータを入力したり、プロバイダからの
ベンダ情報受け取る装置である。符号２のネットワーク
はプロバイダと端末の間のデータ通じさせる装置であ
る。符号３のプロバイダは端末から要求事項データを受
けとり、ベンダ一覧を作成し、端末に送付する装置であ
る。

【００１２】本発明を利用したビジネス全体実現図を図
２に示す。処理100において、プロバイダは要求事項の
データをクライアントから受け取る。要求事項のデータ
の内容はクライアントが購買したい商品の要求仕様や要
求納期、要求価格、要求数量、クライアント行いたい取
引の形態である。取引の形態とはプロバイダが取引の仲
介をするか否かの選択をすることである。クライアント
がベンダと直接取引を行ったり、プロバイダがクライア
ントとベンダの仲立ちをしたりする。

【００１３】処理200において、プロバイダは要求事項
データの情報を基に符号２のネットワークから取引デー
タを取得する。符号２のネットワーク上では常に取引デ
ータが送受信されており、プロバイダは取引データをプ
ロバイダが管理する取引情報データベースに常に取り込
んでいる。そのデータ書庫から要求事項データに関連す
る取引情報を取得する。処理300において、プロバイダ
はクライアントからの要求事項データと取得した取引情
報をベンダ候補を選定するための入力情報とする。プロ
バイダは入力情報を処理しベンダ候補一覧を出力する。
処理400において、プロバイダがベンダ候補を特定でき
ない場合は端末を通じてクライアントにベンダが特定で
きないことをメッセージで伝える。

【００１４】処理500において、プロバイダは一覧の中
のベンダに対してクライアントが要求した商品の仕様を
満たせるかを問い合わせる。処理600において、問い合
わせをうけたベンダはプロバイダに全ての要求に応えら
れるのか、一部の要求に応えられるのか、全く要求に応
えられないのかの情報を返送する。プロバイダは要求に
応じれないベンダを一覧の中から除外する。処理700に
おいて、クライアントの取引形態の要望に応じ処理を分
岐させる。

【００１５】処理800において、クライアントが取引の
仲介を要求している場合は、プロバイダは一覧のベンダ
の中でクライアントの要求事項を最も充足するベンダと
取引を行い、商品を調達する。処理900において、プロ
バイダはクライアントと取引を行い調達した商品を販売
し、プロバイダの処理を終了する。この取引形態ではク
ライアントからはベンダがみえなくなる。処理1000にお
いて、クライアントがプロバイダにベンダの紹介を要求
している場合は、プロバイダはベンダの一覧をクライア
ントに送付する。処理1100において、クライアントがベ
ンダと取引を開始し、プロバイダの処理を終了する。本
発明ではビジネス全体図の中で、処理100の要求事項を
クライアントから受け取る処理と処理300のプロバイダ
が要求できるベンダを特定する処理を対象にする。

【００１６】図３は本発明のベンダ選定の図である。処
理100内の処理110において、クライアントは購買したい
商品に関する情報をネットワークに繋がる自社企業の端
末からプロバイダへ送信する。クライアントの入力画面
を図５に示す。プロバイダはクライアントの企業コー
ド、企業名、購買したい商品コードや商品の仕様に関す
る情報である商品名、商品の材料名などを特定する。後
に説明するが、符号４の検索結果に含む名称の部分につ
いてもこの時点で入力する。また、クライアントがベン
ダを特定する際に重視する指標を指定する。特定された
ベンダ候補を序列化する時の指標となる。納期遵守率、
取引先数などプロバイダが提供している指標の中でどの
指標を重要視するかをクライアントが指定する。例え
ば、納期遵守率が高い順や、取引先数が多い順などであ
る。必ずしも全ての情報をクライアントが指定するわけ
ではなく、例えば商品コードと商品名だけなど限られた
情報から購買したい商品をプロバイダが特定する。ただ
し、商品コードは必須入力項目でなければならない。

【００１７】以下の処理で310,320,330,340,350,360は
処理300内、311,312,313,314は処理310内、410は処理40
0内の処理である。処理310において、プロバイダはクラ
イアントが入力した情報を基に購買したい商品を特定す
る。図４は商品特定の図である。処理311において、商
品に関する情報は取引伝票が有しているため、取引情報
データベースから購買したい商品の取引伝票を特定し、
商品に関する情報を取得し、購買したい商品を詳細に確
定できるようにする。クライアントの要求した商品コー
ドがプロバイダが管理する企業間電子商取引ネットワー
クで取引されたことがあるのかどうかを知る。取引情報
データベースのサーチを行い入力された商品コードの取
引があるかを検索する。以前に同じ商品コードの商品が
取引されていたならば、商品に関する情報が取引情報デ
ータベースから取得できる。取引情報データベースの伝
票例を図６に示す。

【００１８】処理312において、購買したい商品コード
の取引が存在しない場合、類似語辞書を用いることで、
購買したい商品の取引伝票を特定する。名称コードとは
名称を示す項目のデータ内容である。同義語とはある名
称コードに対して仕様面で代替することができる名称コ
ードである。ある名称コードの検索結果とその同義語の
検索結果は同じ仕様を示すので置換できる。下位概念語
とはある名称コードに対して仕様面で代替することがで
きない語である。ある名称コードの検索結果はその下位
概念語の検索結果を仕様面で含むことができるが、下位
概念語の検索結果は特定の用途用に専門化された仕様の
集合になるため代替することはできない。ある名称コー
ドの上位概念語とはある名称コードに対して仕様面で代
替することができる可能性がある語である。ある名称コ
ードの検索結果はその上位概念語の検索結果を仕様面で
含むことができないが、その上位概念語の検索結果はあ
る名称コードより汎用的な仕様の集合になるため代替品
を含む可能性がある。

【００１９】商品名は商品コードと違い、商品コードが
違った場合でも仕様は同じであることがある。例え
ば、"IC"と"LSI"は違うコードである。厳密には仕様は
違うが概略の仕様では商品は同じであるとする。こうす
ることにより、類似語辞書を商品仕様の検索に使用す
る。そこで、類似語辞書を用いて、商品名は違うが仕様
は同じである取引伝票を特定できるようにする。類似語
辞書を図７に示す。図５の入力画面の符号４の部分に商
品の仕様に関する情報を処理110の時点で入力してい
る。項目名には商品の仕様が同じことを特定するために
必要な項目が列挙されている。商品名、材料名、インタ
フェース形状などの名称を示す項目である。プロバイダ
は各項目について、項目内容、同義語を含むかどうか、
上位概念語を含むかどうか、下位概念語を含むかどうか
の指定を特定する。処理313において、プロバイダは入
力されたデータ項目の情報を基に類似語辞書の検索を行
い、項目名毎の同義語と下位概念語と上位概念語を特定
する。

【００２０】プロバイダは特定された項目名毎の名称コ
ードの同義語、下位概念語、上位概念語を特定されたク
ライアントの指定に基づき、類似語テーブルに格納す
る。検索結果に含むと指定された語の場合は類似語テー
ブルの"検索結果に含む検索キー"の項目に格納し、検索
結果に含まないと指定された語の場合は"検索結果に含
まない検索キー"の項目に格納する。類似語テーブルを
図８に示す。

【００２１】処理314において、プロバイダは"検索結果
に含む検索キー"の項目内のデータを類似語テーブルか
ら抽出し、仕様の項目名毎にOR条件で取引情報データベ
ースのデータ項目の検索キーに加える。また、プロバイ
ダは" 検索結果に含まない検索キー"の項目をマッチし
ない検索キーとしてNOTマッチ項目にし、仕様の項目毎
にOR条件で検索キーに加える。取引情報データベースへ
の検索キーが全てのデータ項目に関して設定し終わった
ら、検索を開始する。指定されている項目名が商品名だ
とすると、同義語だけで検索した場合は名称コードと代
替できる商品が抽出される。上位概念だけで検索した場
合は名称コードの代替品として使える商品名と使えない
商品名が混在して抽出される。下位概念だけで検索した
場合は名称コードが応用されている特定用途の商品名が
抽出され、名称コードの代替品でない商品が抽出され
る。例えば"プリンタ"を名称コードとすると、上位概念
を許して検索すると"印刷機械"が検索キーとして追加さ
れ、輪転機の商品もふくめて抽出される。下位概念だけ
で検索すると、"感熱式プリンタ""インクジェットプリ
ンタ"などが検索キーとして追加され、特定用途の商品
が抽出される。

【００２２】処理320において、取引情報データベース
を検索した結果、検索条件に合致するレコードから、受
注者製品コード毎に発注伝票を１件ずつ抽出する。伝票
中の訂正コードから伝票の情報が変更された伝票は抽出
しない。発注伝票は伝票タイプで区別する。その取引を
購買したい商品のマスタとして購買要件テーブルに保存
する。購買要件は複数商品あってもよい。購買要件テー
ブルをは取引情報データベースのテーブルと同じ項目で
ある。

【００２３】処理410において、類似語辞書を用いた商
品検索で購買したい商品を有する取引伝票が取引情報デ
ータベースに存在しなかった場合、プロバイダが運営す
る電子商取引ネットワークではクライアントが求めてい
る商品を取り扱っていないことを示す。プロバイダは求
めている商品を提供するベンダを特定することができな
いことが明らかになったため、ベンダを特定することが
できないことをクライアントに伝える。クライアントの
端末に"指定された商品を提供するベンダが存在しない"
という趣旨のメッセージを検索結果として送信する。

【００２４】取引形態が安定していると企業間の取引形
態が定期発注や定量発注の形態になる。処理330におい
て、取引がいずれかの取引形態でおこなわれていたら、
取引形態が安定していると判定する。まず、定期発注が
行われている取引を取引情報データベースから特定す
る。購買要件テーブルから項目を特定しデータ内容を検
索キーに設定する。購買要件のテーブル項目の受注者商
品コードと単価、数量単位、が合致し、単価区分のフラ
グが確定単価になっている伝票を伝票日付順に取引情報
データベースから抽出する。数量単位を変換すれば単価
が同じになる伝票を抽出するために、購買要件テーブル
の単価の変換を商品一覧マスタを通じて行う。

【００２５】商品一覧マスタを図９に示す。数量単位間
の変換比率は商品一覧マスタに10個＝１箱、1000個＝１
ロールなどと登録されている。例えば、要件レコードの数
量単位が個で単価が\10の場合、数量単位が箱で単価が\
100の伝票や数量単位がロールで単価が\10000の伝票も同じ
条件の伝票として抽出する。購買要件テーブルの全ての
受注者商品コードに対して、上記の処理を行う。

【００２６】以下に記述する一時テーブル１から５は取
引情報データベースと同じデータ項目を有する。抽出さ
れた伝票を全て一時テーブル１に保管する。この伝票は
商品と単価が購買要件と同じである。一時テーブル１か
ら、購買要件テーブルの受注者コード、発注者コード、
受注者商品コードが同じ伝票を抽出しその伝票日付の間
隔を逐一計算する。購買要件と合致する抽出された全伝
票数―１個の日付間隔が算出される。その平均値を計算
する。平均値と日付間隔との差が２日以内である伝票を
一時テーブル２に保管する。この伝票は購買要件と商
品、単価が同じで発注間隔が一定している。そうではな
い伝票を一時テーブル３に保管する。

【００２７】この伝票は購買要件と商品、単価が同じで
発注間隔が一定していない。一時テーブル２の伝票のな
かで発注者商品コード毎に伝票を抽出し、注文日付が同
じ伝票にたいして、発注者商品コード毎で発注日付毎に
注文数量を算出する。発注者商品コード間で日付毎の注
文数量の偏差値を計算する。各伝票の値が40〜60の間に
すべておさまないのであれば、抽出された伝票の取引形
態は定期発注品の取引と判断される。一時テーブル２の
全ての受注者商品コードに対して上記の処理を行う。伝
票が指標値におさまらないと判断されれば、受注者製品
コード毎に１伝票を定期発注取引テーブルに格納する。
そうでない伝票を一時テーブル４に格納する。この伝票
は購買要件と商品、単価が同じで、発注間隔が一定して
おり、発注数量が一定している伝票である。"間隔が２
日以内""偏差値が40〜60の間"のような指標は一例とし
て上げているものであり、この指標値はプロバイダで任
意に設定できる。また、偏差値でなくてもデータのばら
つきを示す尺度であればよい。

【００２８】処理340において、取引関係に関する情報
を取引情報データベースから生成する。一時テーブル３
の伝票の中で注文数量、注文金額が同じである伝票を抽
出し定量発注テーブルに登録する。登録する際に商品コ
ードが重複しないように、１件づつ登録する毎に重複が
ないかチェックする。全ての伝票が購買要件が注文数
量、注文金額と同じでない場合は処理410に進み、クラ
イアントに購買したい商品を提供するベンダが存在しな
いことを伝える。

【００２９】定期発注テーブルと定量発注テーブルに登
録されているレコードの注文番号を特定する。その注文
番号を有する入荷伝票を取引情報データベースから抽出
し一時テーブル５に保管する。一時テーブル５の注文番
号、発注者コード、受注者コードの３項目のデータ内容
を受発注関係テーブルにコピーする。受発注関係テーブ
ルを図１０に示す。受発注関係テーブルに発注者コード
と受注者コードの対が重複するレコードがないように、
１レコードづつ取引関係テーブルに検索をおこない、重
複したレコードは削除する。受発注関係テーブルを受注
者コード毎のレコード数を発注者コードが重ならないよ
うに算出する。受発注関係テーブルの取引先数の欄にレ
コード数を保管する。また、受発注関係テーブルのレコ
ードの発注者コードと受注者コードの対毎について、一
時テーブル５から納入金額の合計を算出し、受発注関係
テーブルの納入合計の欄に保管する。また、一時テーブ
ル５の納入金額を受注者コード毎に合計し、受発注関係
テーブルの受注者合計の欄に保管する。

【００３０】処理350において、まず、受発注関係テー
ブルのレコードについて取引関係の判定を行う。取引関
係の種類を設定する。それぞれのタイプ毎に取引先数と
納入金額合計の上限値と下限値を設定し、基準値として
保管する。例えば、取引関係の種類を２つの場合で説明
すると、取引関係１は特定の取引先との間での取引を行
っている関係とする。その場合、取引先数が限られてお
り、主要取引先で納入金額合計の大半をしめる。取引関
係２は取引先数が多く、納入金額合計も特定の取引先に
偏ることがないとする。この２つのタイプの判定を行
う。その際に、取引関係１を取引先数20以下で、上位５
社の入荷合計金額が全体の90％をしめ、取引関係２を取
引先数20以上で、上位５社の入荷合計金額が全体の90％
をしめないのように指標を設定する。

【００３１】指標値はプロバイダが任意に設定する。納
入金額の指標を割合にする場合は受発注関係テーブルの
出荷合計を同一発注者コード内で割合表示をする。納入
金額の指標を金額の偏りにする場合、受発注関係テーブ
ルの納入合計を同一発注者コード内で偏差値表示などデ
ータのばらつきを示す指標にする。受注関係テーブルの
レコードについて、取引関係１と判定されるレコードは
そのベンダタイプの項目に"１"を入力する、取引関係２
と判定されるレコードはそのベンダタイプの項目に"２"
を格納する。

【００３２】その上で、受発注関係テーブルのレコード
の取引形態が取引関係と合致するか判定する。受発注関
係テーブルから１レコードづつ読み取り、取引関係を判
定する。ベンダタイプ１のレコードの注文番号が定期発
注テーブル内のレコードに存在すればそのレコードをベ
ンダテーブルに格納する。ベンダタイプ２のレコードの
注文番号が定量発注品テーブルに存在すれば、そのレコ
ードをベンダテーブルに格納する。ベンダテーブルにレ
コードが存在しない場合は処理４１０に進む。ベンダテ
ーブルを図１１に示す。

【００３３】処理360において、ベンダテーブルに取引
実績情報を付加し、クライアントの指定に準じてソート
を行う。ベンダテーブルの注文番号を有する発注伝票と
入荷伝票を抽出し納期テーブルに格納する。納期テーブ
ルを図１２に示す。注文伝票と入荷伝票の対を注文番号
をキーにして特定し、注文伝票の納期日付より入荷伝票
の納入日よりあとであれば納期遅れのフラグ情報を納期
テーブルの入荷伝票の納期遅延の項目の欄につけ加え
る。また、納入日から納期日付をひくことにより納入リ
ードタイムを算出し、納期テーブルの入荷伝票の納入項
目の欄につけ加える。納期テーブルの全伝票を処理しお
わったら、納期テーブルの入荷伝票に関して、受注者商
品コード毎のレコード数と納入遅れのフラグのあるレコ
ード数とカウントし、納入遅れフラグ有りのレコード数
を受注者商品コードのレコード件数で割り納期遵守率を
算出する。算出したデータをベンダテーブルの同発注番
号の納期遵守率の欄につけ加える。

【００３４】ベンダテーブルの受注者コードをキーにし
て、受発注関係テーブルの受注者コード毎の取引先数、
受注者別納入合計金額をベンダテーブルにコピーする。
ベンダテーブルの受注者コード毎の取引数を取引情報デ
ータベースから検索して算出する。納期テーブルから受
注者商品コード納入リードタイム、納期遵守率をベンダ
テーブルの注文番号をキーにしてベンダテーブルにコピ
ーする。ベンダテーブルをクライアントが指定したソー
トキーでソートする。例えば、クライアントが納期遵守
率が降順と指定していたならば、納期遵守率の項目を降
順にソートする。その時のベンダテーブルのデータを出
力イメージを図１３に示す。さらに、ベンダテーブルの
レコード数をカウントしベンダ候補数を算出し、ベンダ
候補出力画面に"ベンダ候補が'XX'社有ります"との趣旨
のメッセージを表示することも可能である。

【００３５】

【発明の効果】本発明を利用することにより、企業間電
子商取引市場において、クライアントは商品を調達する
際に、類似語辞書を用いた商品検索を使うことで、同仕
様品はもとより代替品を販売するベンダを、ベンダが提
供するカタログ、図面、仕様書を詳細に読むことなく特
定することができる。さらに、本発明を利用することに
より、取引の実績情報を基にしたベンダ選定を選定でき
るため、クライアントは取引実績のないベンダと取引を
行うために事前調査をする必要がなくなる。

【図面の簡単な説明】

【図１】本発明のベンダ候補特定を実現する装置を示す
ブロック図である。

【図２】本発明が前提とする取引仲介システムのビジネ
ス全体実現図である。

【図３】本発明のベンダ候補を特定するフロー図であ
る。

【図４】本発明の購買したい商品を特定するフロー図で
ある。

【図５】本発明のベンダ候補を特定するための情報を入
力する画面である。

【図６】本発明の取引情報を保管している取引情報デー
タベースのテーブルを示す図である。

【図７】本発明の商品特定のための類似語辞書を示す図
である。

【図８】本発明の取引情報データベースへの検索キーを
格納する類似語テーブルを示す図である。

【図９】本発明の商品の数量の数量単位間の変換を行う
商品一覧マスタを示す図である。

【図１０】本発明の受注者と発注者の関係と取引情報を
表す受発注関係テーブルを示す図である。

【図１１】本発明の特定されたベンダと実績情報を保管
しているベンダテーブルを示す図である。

【図１２】本発明の納入実績を保管する取引情報データ
ベースを拡張した納期テーブルを示す図である。

【図１３】本発明の特定されたベンダをクライアントに
表示する出力画面である。

【符号の説明】

１…端末、 ２…ネットワーク、 ３…プロバイ
ダ、４…商品の仕様情報入力部分、１００〜１１００…
本発明が前提とする取引仲介システムの処理、１１０…
クライアントがプロバイダへ入力情報を送信する処理、
３１０〜３６０…プロバイダがクライアントの要望する
商品とそれを販売するベンダ候補を特定する処理、処理
４１０…プロバイダがクライアントにベンダが特定でき
ないことを知らせる処理、３１１〜３１４…プロバイダ
が類似語辞書を用いてクライアントの要望する商品を特
定する処理。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ▲高▼橋 直紀 神奈川県横浜市都筑区加賀原二丁目２番 株式会社日立製作所システム開発本部内 Ｆターム(参考） 5B049 AA06 BB11 CC00 CC05 EE05 GG02 GG07

Claims (3)

【特許請求の範囲】
1. 【請求項１】多様なフォーマットの取引データが使われ
   ている企業間電子商取引市場の取引仲介システムにおい
   て、データ項目の類似語辞書を用いて所望する商品の取
   引データを抽出する方法を有し、その商品を供給するベ
   ンダを特定する機能を持つことを特徴とする取引仲介シ
   ステムにおけるベンダ候補特定方法。
2. 【請求項２】請求項１において、抽出された商品の取引
   データから、商品供給ベンダを特定することにより、商
   品情報を企業間電子商取引市場に公開していない潜在ベ
   ンダについても特定することを可能とする取引仲介シス
   テムにおけるベンダ候補特定方法。
3. 【請求項３】請求項１において、商品を供給するベンダ
   について、その取引先数や取引数などによって、供給
   (取引)の可能性を順位付けすることを特徴とする取引仲
   介システムにおけるベンダ候補特定方法。