JPWO2003003268A1 - 取引制約解決装置 - Google Patents

Abstract

電子市場に売買注文として出せなかったような多様な制約を一挙に解決し、異なる種類や属性の取引を同一のマーケットにおいても取扱い得るようにするとともに、売り手や買い手といった取引者が取引相手と約定する可能性を飛躍的に高めて電子市場における取引をより一層促進させる。そのために、取引に係る制約内容、制約の解決度合いの値の型、制約の強度等を定義付けておき、その定義に従って受け付けた注文データを、解決度合い値及び制約の強度に基づいて処理することによって、一つ以上の制約を解決し、約定させるようにした。

Description

技術分野
本発明は、電子市場における取引の一つ以上の制約を解決することができる取引制約解決装置や、それら一つ以上の制約を解決するためのデータ構造、及びそのデータ構造を用いた取引制約解決支援装置、取引制約解決システムに関するものである。
背景技術
インターネットに代表される通信システムやコンピュータの発達で、近時、インターネットの情報性及びリアルタイム性を利用したネットオークション等と呼ばれる通信回線を介した取引が脚光を浴びつつある。このようなものとして、一つの商品又は役務（サービス）に関して、複数の買い手がインターネットを利用して買値を提示し、最も高い価格を提示したものが商品を購入することができるといった通常のオークションシステムや、逆に一つの商品又は役務に関する買い希望について、複数の売り手がインターネットを利用して売り価格を提示し、その中から最も安い価格を提示したものが販売できるといった逆オークションシステム、さらにこれらのバリエーションに係る種々のものが考えられている。
ところでこのような取引は、何れもある定まったの商品や役務に対して価格の高低によって最終的な約定相手が決まるという形態を有している。換言すれば、コンピュータやインターネットを利用して行われている取引は、取引相手の約定に際して「価格」というただ一つの制約を解決するようにしたものといえる。
しかしながら、現実の商取引について考えてみると、解決すべき制約が一つのみであるというような態様の取引は実際には少なく、価格、数量、時間、場所、質、決済等々といった数々の制約が存在する。さらには例えば価格については総価格や単価、質については色やサイズなどの各制約にはその属性ともいうべき制約が付随するのが通常であり、取引数量や納期によって単価が変動するなど制約同士が密接に関係していてそれらが相対的に決定されることもある。従って、上述のようなオークションシステムなどでは、多様な制約を一挙に解決することは到底できず、異なる種類や属性の商品や役務を同一のマーケットに載せることもできないのが現状であり、いわゆる電子市場において売買注文として取り扱うことは現実問題として不可能であった。もちろん、多様な制約を人手で解決しようとするのは著しく困難であるのはいうまでもない。このようなことから、売り手や買い手が相手方と約定する可能性も低い水準に留まらざるを得ない。
発明の開示
そこで本発明は、電子市場に売買注文として出せなかったような多様な制約を一挙に解決し、異なる種類や属性の取引を同一のマーケットにおいても取扱い得るようにするとともに、売り手や買い手といった取引者が取引相手と約定する可能性を飛躍的に高めて電子市場における取引をより一層促進することを目的とするものである。
すなわち、本発明の取引制約解決装置は、電子市場において取引に係る一つ以上の制約を解決するために、解決すべき一つ以上の制約要素をそれぞれ定義付けて格納する制約要素格納部と、前記定義付けられた制約要素に従って受け付ける売り注文データと買い注文データとを仮約定させた場合における各制約要素の解決度合いの値の型を制約要素毎の属性として定義付けて格納する約定タイプ格納部と、指定された解決度合いの値の型に基づいて解決処理を行う際の制約の強度を制約要素毎の属性として定義付けて格納する約定レベル格納部と、取引に係る売り注文データと買い注文データとを前記制約要素に従って受け付ける注文データ受付部と、それぞれ格納された解決度合いの値の型及び前記約定レベル格納部に格納された制約の強度に基づいて一つ以上の制約を解決する処理を行う解決処理部に対して前記注文データ受付部で受け付けた売り注文データ及び買い注文データを出力する注文データ出力部とを具備することを特徴としている。
すなわち、取引に係る解決すべき一又は複数の制約要素の定義と、売り注文データと買い注文データとを仮約定させた場合の制約要素の解決度合いを示す値の型と、その解決度合いの値の型に対応する解決の強度とを予め定義付けて格納しておき、定義された制約要素に従って受け付けた売買の注文データを解決処理部に出力することによって、その解決処理部において各制約を定義された前記解決度合いの値の型及び解決強度に基づいて解決するようにしている。したがって、制約要素ごとに解決度合いを所定の方式で数値化するとともに、その数値のタイプに強度を付与した上でそれらに従って制約要素を解決すれば、取引に多様な制約要素が含まれるようなこれまでなし得なかった複雑な売買の注文を取り扱い、売り注文データと買い注文データとを約定させる可能性を飛躍的に向上することができるようになる。
なお、制約要素格納部に格納される制約要素、約定タイプ格納部に格納される解決度合いの値の型、約定レベル格納部に格納される制約の強度等は、ＸＭＬスキーマやデータベースのスキーマ定義、プログラム言語による独自の言語等によって定義することができる。
また、前記解決度合いの値の型及び制約の強度に従って制約要素を解決するための具体的な処理としては、売り手と買い手とが存在する取引を成立させるものであれば、一般的なオークション方式やいわゆる逆オークション方式等の売買の取引価格を一致させて約定させるものや、両者の価格が不一致でもそれぞれの提示価格で約定させるものなど、あらゆる方式を適用することができる。また、売り手と買い手の提示した条件すなわち制約要素の一部又は全部を開示するようにしたり一切非公開とするようにしてもよい。
具体的に、解決度合いの値の型は、多値又は二値のいずれかの解決度合い値を取るようにしておけば、制約要素の解決度合いを点数化して表現したり、解決したか否かのいずれかで表現することができるので、解決度合いを容易に把握することができる。
また、制約の強度については、絶対的に解決すべき制約であることを表す強制約という制約レベル値で表すか、「なるべく解決できればよい」という希望的な制約を表す善処（ベストエフォート）制約という制約レベル値のいずれかの属性値を取るようにすることが、現実の取引により良く対応しているといえる。
特に、少なくとも一の制約要素が所定の幅を有している場合、解決度合いの値を定めるには、その制約の幅の上限又は加減のいずれかの方が望ましいということがある。このような場合に解決度合いの値を好ましいものとして処理できる要にするためには、解決度合いの値が制約要素の幅のうちいずれかの値を指し示す指向性を定義付けて格納しておくとよい。
解決度合いの値の型と制約の強度に従って制約が解決され約定された結果である約定結果データをさらに格納するようにしていると、約定した個別の売り手と買い手との間でその後に行われる現実の取引の根拠を明確にしておくことができる。また、制約が解決できず約定しなかった注文データも格納しておくと、そのデータを後の取引のチャンスに回すことも容易となり、数多くの取引を約定させることにも貢献することができる。
さらに、取引には手数料や税金、装置の使用料などの様々な課金が伴うものであるため、制約が解決され約定された際に課金すべき情報を示す課金情報データを格納するようにするとなお好ましい。
また、本発明の取引制約解決装置は、電子市場における取引に係る約定に必要な一つ以上の制約要素の定義を蓄積する制約要素蓄積部と、文字データ及びその文字データに対する付加情報を区別して記述し得る言語で記述され前記制約要素蓄積部で蓄積した制約要素の定義によって特定される電子商取引専用ランゲージを用いて受け付けた買い注文データ及び売り注文データとを格納する第１の格納部と、第１の格納部で格納した買い注文データ及び売り注文データを、前記制約要素の定義に従って解析する解析部と、解析部で解析された買い注文データ及び売り注文データを、前記制約要素の定義に従って約定させるための候補を生成する約定候補生成部とを具備していることを特徴とするものでもある。
このようなものであれば、定義付けて蓄積した一つ以上の制約要素で構成される電子用取引専用ランゲージを作成すれば、後はそれに従って売買の注文データを受け付けて格納し、さらにそのランゲージの解釈に基づいて注文データを解析した上で約定させる候補を生成することができるので多様で複雑な制約を容易に解決して取引を約定させやすくすることができる。このことから、共通の電子商取引専用ランゲージを有している電子市場であれば、それらが異なる方式で約定候補を生成するようにしていても、売り手や買い手が注文を出すことができるようになるという従来にないメリットを得ることができる。さらに制約の定義付けをして蓄積しておくことで、この種の装置の開発期間を短期化し、大幅なコストダウンを図ることもできるようになる。
特に、電子商取引専用ランゲージは、タグ及びタグで囲んだ文字データからなる一つ以上の要素の名前及びそれらの構造を表す要素の内容モデルを記述し得る言語を用いて記述され前記蓄積部で蓄積した制約要素の定義によって特定されるものとすることができるうえに、制約要素の定義についても同様に、タグ及びタグで囲んだ文字データからなる一つ以上の要素の名前及びそれらの構造を表す要素の内容モデルを記述し得る言語を用いて記述して蓄積することができる。
また、制約要素蓄積部には、定義付けた解決すべき一つ以上の制約要素と、その各制約要素毎の属性として定義されそれら制約要素に従って受け付ける売り注文データと買い注文データとを仮約定させた場合における各制約要素の解決度合いの値の型と、各制約要素毎の属性として定義され前記解決度合いの値の型に基づいて解決処理を行う際の制約の強度とを少なくとも蓄積するようにしていると、各制約を定義された前記解決度合いの値の型及び解決強度に基づいて解決することで、前述のように取引の約定の可能性及び約定数を飛躍的に高めることができる。
なお、制約要素蓄積部で蓄積される制約要素の定義と第１の格納部で格納される注文データは同一の記憶領域内に明確に区別して蓄積・格納してもよいし、同一の記憶領域内に明確に区別することなく混在させて蓄積・格納してもよく、別個の記憶領域にそれぞれ記憶するようにすることもできる。
約定候補を生成する前処理として、効率的に候補数を絞り込み演算処理の負荷を有効に軽減するためには、この取引制約解決装置に、一つ以上の制約要素、制約要素に含まれる一つ以上の属性、又は一つ以上の属性を含む一つ以上の制約要素のうち、解決すべき制約要素又は属性の解決順序を決定する制約解決順序決定手段をさらに設けるとよい。
約定候補生成部で約定候補として生成された買い注文データと売り注文データを実際に約定させるには、それら候補である一つ以上の買い注文データと一つ以上の売り注文データとを前記定義された制約要素に従って約定させる処理を行うマッチング部をさらに設けるとともに、第２の格納部に少なくともマッチング部で約定された買い注文データ及び売り注文データを格納するようにすることが好ましい。なお、この第２の格納部には、マッチング部で約定しなかったものも格納するようにすることができる。この場合もマッチング部による約定の処理は、一般的なオークション方式やいわゆる逆オークション方式等の売買の取引価格を一致させて約定させるものや、両者の価格が不一致でもそれぞれの提示価格で約定させるもの等、あらゆる方式を適用することができる。
また、第２の格納部において、約定候補生成部又はマッチング部の少なくともいずれか一方の処理において従った制約要素のうち、利用された制約要素と利用されなかった制約要素とを区別して格納するようにしておくと、約定が構成に行われたという法的な根拠を明確に残しておくことができる。
さらに、マッチング部の処理に基づいて制約が解決され約定された際に課金すべき情報を示す課金情報データを格納する第３の格納部を設けることも有用である。
特に第１の格納部において、買い注文データ及び売り注文データを提示した需要者及び提供者のそれぞれが他者の提示したデータを知ることができない状態で受け付けたデータを格納するようにすれば、売り手や買い手がそれぞれの制約を加えた注文を行う際に、競合する取引者や取引相手となる者が提示した条件が分からないため、過当な競争を防止することができる。なお、約定後も現実の取引に必須の制約を除いて各者の提示した制約条件を他者に開示しないようにすれば、後の取引においても過剰で不公正なな競争を招かないようにすることができる。また、各取引者がより約定しやすくするために、過去の標準的な約定価格や当初に提示された制約からどれくらい譲歩すれば約定する可能性が高まるかなどの一定の示唆を各者に提示することは、約定数を増加させるためには有効となる。
また、これまでの商取引の常識は、売り手と買い手の約定価格を一致させることにあるが、このことが却って約定成立数が少なくなってしまう原因となっている。そこで、このような従前の取引における常識を根底から覆し、約定成立数を飛躍的に高めるには、マッチング部において、買い注文データに含まれる制約要素の一つである価格と、売り注文データに含まれる制約要素の一つである価格とが一致しない場合でも、買い注文データと売り注文データとを約定させるようにするとよい。このようにすると、いずれの売り手も買い手も自分が提示した価格で約定することになるので、納得した取引を行うことができる。なお、この場合は不公平感を払拭するためにも、各者が提示した制約の少なくとも一部は他者に開示しないようにすることが望ましい。
以上のような取引制約解決装置を実現するためのデータ構造として、電子市場における取引に係る約定に必要な一つ以上の制約要素の定義と、前記各制約要素毎の属性として定義されそれら制約要素に従って受け付ける売り注文データと買い注文データとを仮約定させた場合における各制約要素の解決度合いの値の型と、前記各制約要素毎の属性として定義され前記解決度合いの値の型に基づいて解決処理を行う際の制約の強度とを少なくとも格納し、さらに前記制約の定義、解決度合いの値の型及び制約の強度に基づいて受け付けた買い注文データ及び売り注文データとを付加的に格納し得るように構成した第１のデータ部を少なくとも有し、第１のデータ部における約定タイプ定義データの解決度合い及び約定レベル定義データの解決条件に従って約定された買い注文データと売り注文データの約定結果を格納する第２のデータ部、又は前記約定に際して課金すべき課金情報を格納する第３のデータ部のうち、いずれか一方又は両方を付加的に設け得るように構成した取引制約解決データ構造を構築すると、前記取引制約解決装置への実装を容易化し、開発期間の短縮化や人件費を含むコスト低減を図ることができる。なお、このデータ構造の各部を独立ファイルとしてそれぞれ保存したり、データベースの独立レコードとして保存した場合も同様のロジックを実現することができる。
このようなデータ構造を利用して、電子市場におけるＢ２Ｂ（企業対企業）、Ｂ２Ｃ（企業対消費者）、Ｃ２Ｃ（消費者対消費者）、Ｍ２Ｍ（市場対市場）等の取引を現実に行う際に、取引に参加する一般消費者やディーラ、マーケット運営者等から受け付けた情報に基づいて約定処理等を行う装置の付加を軽減し、妥当な約定処理が行えるようにした取引支援装置には、電子市場における取引に係る売り注文データ又は買い注文データの少なくとも一方を読み込む注文データ読込部と、前記取引制約解決データ構造のうち少なくとも第１のデータ部における制約要素の定義、解決度合いの値の型及び制約の強度からなる定義データを格納する定義データ格納部と、注文データ読込部で読み込んだ注文データを前記定義データ格納部に格納した定義データに基づいて解析し、売り注文データと買い注文データとを約定させる処理を行うマッチング部に出力する注文データ出力部とを具備するものが挙げられる。なお、定義データ格納部には、前記取引制約解決データ構造におけるデータの全てを格納するようにしても構わない。
また、ディーラやマーケット運営者、一般消費者等の取引に参加する者が、標準化されたインタフェースからそれぞれが提供する若しくは希望する商品や役務の登録を容易に行い得るようにして、その後の約定処理をスムーズに行うようにする取引支援装置には、前記取引制約解決データ構造のうち少なくとも第１のデータ部における制約要素の定義、解決度合いの値の型及び制約の強度からなる定義データに基づいて、電子市場における取引の取引内容を受け付けるための取引受付インタフェース（例えばコンピュータに表示される画面や音声入力用インタフェース）を生成するインタフェース生成部と、インタフェース生成部で生成した取引受付インタフェースを出力するインタフェース出力部と、インタフェース出力部で出力した取引受付インタフェースに基づいて入力された取引内容データを、前記定義データに従った取引内容データファイルに変換するデータ変換部とを具備するものが挙げられる。なお、取引内容データファイルには、取引内容データと共にそのデータを解析するのに必要な制約要素の定義や解決度合いの値の型、制約の強度等も記録するようにしてもよいし、取引内容データを解析するのに必要なこれらの情報が格納されているネットワーク上の位置を示唆する情報と当該取引内容データとを記録するようにしてもよい。
さらに、過去に電子市場において取り引きしたことがあったり、何度も繰り返して取り引きしている顧客であるディーラや消費者をプロファイリングして、それらの者の取り引きへの参加をより便利なものとするとともに、マーケット運営者にとっても顧客の情報を収集し取引動向の把握を容易化するためには、前記取引受付インタフェースで受け付けた取引データ内容に基づいて、当該取引に係る顧客である売り手又は買い手個別の顧客プロファイルデータを作成し格納する顧客プロファイル格納部と、顧客プロファイル格納部に格納した顧客プロファイルデータに基づいて、前記定義データの一部又は全部について顧客毎のデフォルト定義データを設定するデフォルト設定部をさらに設け、前記インタフェース生成部が、前記定義データ及びデフォルト定義データに基づいた取引受付インタフェースを生成するようにするとよい。
また、ある電子市場で約定しきれなかった売買取引や、得手不得手の取引を一時的なプロファイルとして作成し、そのプロファイルを異なる電子市場同士で融通し合い、約定数を増加させるとともに、Ｍ２Ｍの取引市場を活性化するようにした取引支援装置には、前記取引制約解決データ構造のうち少なくとも第１のデータ部における制約要素の定義に基づいて作成された、電子市場における取引の取引内容データを受け付ける取引内容データ受付部と、取引内容データ受付部で受け付けた取引内容データを格納する取引内容データ格納部とを具備するものが挙げられる。このようなものを利用すれば、取引者にとっても自己の取引をより一層約定させる可能性を向上することができる。
発明を実施するための最良の形態
以下、本発明の実施形態を図面を参照して説明する。
＜第１実施形態＞ 第１図は、本発明の第１実施形態における取引制約解決装置の機能構成を表すブロック図である。この取引制約解決装置は、制約要素格納部１、約定タイプ格納部２、約定レベル格納部３、指向性格納部４、注文データ受付部５、注文データ出力部６、約定結果格納部８、課金情報格納部９とを有している。解決処理部７は、この取引制約解決装置の機能の一部として含めてもよいし、別の装置にその機能を発揮させるようにしてもよい。ここで制約要素格納部１は、電子市場において取り引きされる商品や役務について定義された「価格」「納期」「数量」「商品や役務の質」「（納品、出荷等の）場所」「決済方法」等の制約要素の名前や構造をスキーマに格納するものである。約定タイプ格納部２は、前記各制約要素についてその属性として定義された、売り注文データと買い注文データとを個別に仮約定させた場合の解決度合いの値の型をスキーマに格納するものである。約定レベル格納部３は、各制約要素について指定された解決度合いの値の型ごとに制約要素の属性として定義された、その制約を解決するための制約の強度をスキーマに格納するものである。指向性格納部４は、ある制約についていくらかの幅を持った条件での取引を売り手や買い手が希望した場合に、その幅の上限又は加減の何れに近い条件を希望するのかを定義付けてスキーマに制約要素の属性として格納するものである。そして、これら各部で定義付けて格納された制約、解決度合いの値の型、制約の強度、指向性等に基づいた画面等のユーザインタフェースが各売り手や買い手が使用するコンピュータに表示された場合、その画面表示しに従って入力された情報を、売り注文データＤａ及び買い注文データＤｂとして注文データ受付部５で受け付けるようにしている。
ここで、第２図に買い注文データＤｂにおける一部のデータ構造の一例を示す。第２図は、買い注文データＤｂについて、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いて記述した文書であり、ある商品についての買い手が、「価格が６７０００〜７００００（円、ドル等の通貨単位）の範囲内で安く、納期ができれば２００１年８月３１日まで、２００１年９月３日までには絶対買いたい」という制約（注文）を出した場合について示している。同図に基づいて詳述すると、このような注文の内容は、＜ｏｒｄｅｒ ｔｙｐｅ＝−−−−＞…＜／ｏｒｄｅｒ＞という要素内に記述される。そして＜ｏｒｄｅｒ＞要素内のデータ構造は、「価格」という制約を表す＜ｐｒｉｃｅ＞要素と、「納期」という制約を表す＜ｔｉｍｅ＞要素から構成されている。これら制約要素は、前記制約要素格納部１で格納された制約要素の定義に基づくものである。なお、ここでは説明の簡単化のため価格と納期の二つの制約要素について示しているが、これら以外の制約要素も＜ｏｒｄｅｒ＞要素内に記述することができる。
まず、＜ｐｒｉｃｅ＞要素は、「解決度合いの値の型（ｃｏｎｓｔｒａｉｎｔＴｙｐｅ）」、「制約の強度（ｃｏｎｓｔｒａｉｎｔＬｅｖｅｌ）」、「指向性（ｄｉｒｅｃｔｉｏｎ）」、価格幅の「下限（ｍｉｎ）」、価格幅の「上限（ｍａｘ）」という複数の属性から構成されている。これらの属性は、それぞれ約定タイプ格納部２、約定レベル格納部３及び指向性格納部４で格納された内容に基づくものである。さらに、「価格」についての「解決度合いの値の型」の属性値は、連続する数値（ｎｕｍｅｒｉｃ）で表すことが予め設定されている。また、価格についての「制約の強度」の属性値を「強制約（ａｂｓｏｌｕｔｅ）」とすることや、「価格６７０００〜７００００の範囲内で安く」という条件を示す「ｄｏｗｎ」、「６７０００」、「７００００」は、買い手が画面等に入力した情報をＸＭＬに変換された上で記述されることになる。例えば、「６７０００〜７００００」という制約を満たす売り注文データがあれば、その売り注文データが前記下限値「６７０００」に近いほど高い数値（スコア）をその売り注文データとの組み合わせについて付与し（例えば「６８０００円で売りたい」という売り注文データとの組み合わせには「７５」というスコアを付与する）、当該制約を満たす売り注文データがない場合はこの買い注文データを約定させることはできないことを示している。
なお、前記「指向性（ｄｉｒｅｃｔｉｏｎ）」に対応する属性値としては、上述した「ｄｏｗｎ」の他にも、当該「ｄｏｗｎ」と同じく下限値を示す「ｄｏｗｎｗａｒｄ」、上限値を示す「ｕｐ（又は）ｕｐｗａｒｄ）」、範囲の中央値を示す「ｍｅｄｉａｎ」等を適用することができる。さらにその他にも、範囲の下限をゼロ、上限を１と正規化した場合に、例えば０．２５の位置を目指すことを示す「ｓｐｅｃｉｆｉｅｄ０．２５」等も適用できる。
また、＜ｔｉｍｅ＞要素は、「解決度合いの値の型（ｃｏｎｓｔｒａｉｎｔＴｙｐｅ）」、「制約の強度（ｃｏｎｓｔｒａｉｎｔＬｅｖｅｌ）」、納期の「下限（ｍｉｎ）」、納期の「上限（ｍａｘ）」という複数の属性から構成されている。ここで、買い手が注文した納期に関する条件には、「できれば２００１年８月３１日まで、２００１年９月３日までには絶対」という二つの期限に係る条件が含まれているので、＜ｔｉｍｅ＞要素も並列的な二つの構造を有している。まず、「なるべく８月３１日まで」という条件に関しては、「解決度合いの値の型」の属性値として二値（１又は０）を示す「ｂｏｏｌｅａｎ」が設定され、さらに「制約の強度」の属性値として、その強度が善処すべきものであることを示す「ｂｅｓｔ−ｅｆｆｏｒｔ」が設定される。また期限の「下限」には無制限（本例では処理日時以降）であることを示す「ｕｎｂｏｕｎｄ」、「上限」には「２０００−０８−３１」が設定される。すなわち、この制約（８月３１日までに納品可）を満たす売り注文データがあった場合には、当該制約が解決されたものとして解決度合い値「１」が設定されることになり、当該制約を満たす売り注文データがなかった場合には、解決されなかったものとして解決度合い値「０」が設定される。一方、「９月３日までに絶対」という条件に関しては、「解決度合いの値の型」の属性値として「ｂｏｏｌｅａｎ」が設定され、さらに「制約の強度」の属性値として絶対制約であることを示す「ａｂｓｏｌｕｔｅ」が設定される。期限の下限上限については上述と同様に設定される。すなわち、この「９月３日」というのが絶対制約であるため、この期日までに納品できる売り注文データがなければ、この買い注文データを約定させることはできないことを示している。
なお、「ｃｏｎｓｔｒａｉｎｔＴｙｐｅ」以外の属性値は、買い手が取引条件を入力するたびに記述する他に、当該買い手が過去にこの電子市場で取り引きしたことがある場合など、この買い手についての顧客プロファイルが作成されている場合にはデフォルトとして予め設定しておいて、ユーザの入力の労を軽減するようにしておいてもよい。また、売り注文データについては、上述した買い注文データとほぼ同様のデータ構造を有しているため、ここでは説明を省略する。
このような構造を有する売り注文データＤａ及び買い注文データＤｂを上述のように注文データ受付部５で受け付け、さらに注文データ出力部６によって解決処理部７に出力する。解決処理部７は、前記売り注文データＤａ及び買い注文データＤｂそれぞれの制約を解決して約定させる処理を行うものである。ここで、解決処理部の動作を、第３図に示すフローチャートを用いて簡単に説明する。
まず、入力された売り注文データＤａ及び買い注文データＤｂそれぞれについて、各制約要素の「制約の強度（ｃｏｎｓｔｒａｉｎｔＬｅｖｅｌ）」を参照し、強制約（ａｂｓｏｌｕｔｅ）という属性値を有する制約要素の全ての制約を満たすマッチング候補のみを残して選出する（ステップＳ１）。その際、「解決度合いの値の型（ｃｏｎｓｔｒａｉｎｔＴｙｐｅ）」が「ｎｕｍｅｒｉｃ」である制約について解決スコアを算出する。そして、選出され売り注文データＤａ及び買い注文データＤｂのうち、マッチング数が最大になる解（組み合わせ）を全て求める（ステップＳ２）。そして、その解が一つである場合は（ステップＳ３；ｎｏ）、その組み合わせで売り注文データＤａと買い注文データＤｂとを約定させる。また、解（組み合わせ）が複数ある場合は（ステップＳ３；ｙｅｓ）、「制約の強度（ｃｏｎｓｔｒａｉｎｔＬｅｖｅｌ）」が「ｂｅｓｔ−ｅｆｆｏｒｔ」という属性値を有する制約要素について、解決したか否かをその「解決度合いの値の型（ｃｏｎｓｔｒａｉｎｔＴｙｐｅ）」の属性値「ｂｏｏｌｅａｎ」が１又は０で表現し、それらの合計値が最高でない解（組み合わせ）を除外する（ステップＳ４）。この段階で、解（組み合わせ）が一つとなるものがあれば（ステップＳ５；ｎｏ）、それらの組み合わせで売り注文データＤａと買い注文データＤｂとを約定させる。一方、解（組み合わせ）がいまだ複数ある場合には（ステップＳ５；ｙｅｓ）、前記ステップＳ１で算出された解決スコアの合計と、ステップＳ４で１又は０で表現された解決数との組み合わせからなるｂｅｓｔ−ｅｆｆｏｒｔ善処スコアを、例えば次式
ｂｅｓｔ−ｅｆｆｏｒｔ善処スコア＝（ｎｕｍｅｒｉｃ型の解決スコアの合計＋ｂｏｏｌｅａｎ型の解決数ｘ１００）／制約数
により算出し、最高の値となった解（組み合わせ）からいずれか一つを選ぶことによって、その組み合わせで売り注文データＤａと買い注文データＤｂとを約定させる（ステップＳ６）。
以上のような解決処理部７の処理の結果である約定結果データＤｃを約定結果格納部８に格納するとともに、約定に際して課金されるべき情報である課金情報データＤｄを課金情報格納部９に格納する。
ここで第４図に、格納される約定結果データＤｃ及び課金情報データＤｄからなるデータ構造の一例を示す。このデータ構造は、第２図に示した買い注文データＤｂが約定した場合について示したものである。同図では、約定結果データＤｃ及び課金情報データＤｄを一つのＸＭＬ文書に記述した状態を示している。すなわちこのデータ構造は、大きく分けて約定結果データを表す＜ｃｏｎｔｒａｃｔｕａｌ＞要素と、課金情報データを表す＜ｃｈａｒｇｅ＞要素とから構成される。
詳述すると、＜ｃｏｎｔｒａｃｔｕａｌ＞要素は、個別の約定結果（約定結果ＩＤ）ごとに、買い注文データを示す＜ｏｒｄｅｒ＞要素（＜ｏｒｄｅｒ ｔｙｐｅ＝”ｂｕｙ”＞）と、売り注文データを示す＜ｏｒｄｅｒ＞要素（＜ｏｒｄｅｒ ｔｙｐｅ＝”ｓｃｌｌ”＞）とを並列的に記述した構造を有している。買い注文及び売り注文の要素はさらに、それぞれ制約ごとの約定結果である＜ｐｒｉｃｅ＞要素、＜ｔｉｍｅ＞要素…、約定に際して解決した制約要素の内訳を示す＜ｃｈｅｃｋｅｄＣｏｎｓｔｒａｉｎｓ＞要素、解決しなかった（無視した）制約要素の内訳を示す＜ｉｇｎｏｒｅｄＣｏｎｓｔｒａｉｎｓ＞要素を並列的に記述した構成を有している。例えば前記買い注文データが、「価格６７０００で納期２００１年９月１日」という条件で約定した場合についてみると、同図に示すように約定結果は、＜ｐｒｉｃｅ ｖａｌｕｅ＝”６７０００”／＞、＜ｔｉｍｅ ｖａｌｕｅ＝”２００１−９−０１”／＞というように表される。また、解決した制約＜ｃｈｅｃｋｅｄＣｏｎｓｔｒａｉｎｓ＞要素については、第２図に示した強制約である価格の条件及び強制約である絶対納期が、それぞれ＜ｐｒｉｃｅ＞要素及び＜ｔｉｍｅ＞要素に表される。一方、解決しなかった制約＜ｉｇｎｏｒｅｄＣｏｎｓｔｒａｉｎｓ＞要素については、善処制約である「できれば８月３１日」という条件が満たされなかったので、その制約が＜ｔｉｍｅ＞要素に表される。なお、売り条件の要素についても、同様に解決した制約と解決しなかった制約が表されることになるので、詳細な図示及び説明を省略する。
また、＜ｃｈａｒｇｅ＞要素については、売り手、買い手、マーケット運営者等に対してそれぞれ課金すべき情報を示す＜ｓｕｐｐｌｉｅｒ＞要素、＜ｂｕｙｅｒ＞要素、＜ｍ−ｍａｋｅｒ＞要素から構成される。
なお、上述した第１実施形態では、各制約について「解決度合いの値の型＜ｃｏｎｓｔｒａｉｎｔＴｙｐｅ＞」と「制約の強度＜ｃｏｎｓｔｒａｉｎｔｌｅｖｅｌ＞」に対応する属性値の組み合わせは、「ｎｕｍｅｒｉｃ」と「ａｂｓｏｌｕｔｅ」、「ｂｏｏｌｅａｎ」と「ｂｅｓｔ−ｅｆｆｏｒｔ」、「ｂｏｏｌｅａｎ」と「ａｂｓｏｌｕｔｅ」の３態様を説明したが、これ以外に「ｎｕｍｅｒｉｃ」と「ｂｅｓｔ−ｅｆｆｏｒｔ」の組み合わせや、「いずれかの属性値の指定なし」という態様等も許容することができる。
＜第２実施形態＞ 第５図は、本発明の第１実施形態における取引制約解決装置の機能構成を表すブロック図である。この取引制約解決装置は、制約要素蓄積部１１、第１の格納部１２、解析部１３、制約解決順序決定部１４、約定候補生成部１５、マッチング部１６、第２の格納部１７、第３の格納部１８を有している。ここで制約要素蓄積部１１は、電子市場において取り引きされる商品や役務について定義された「価格」「納期」「数量」「商品や役務の質」「（納品、出荷等の）場所」「決済方法」等の制約要素（それらに付随する属性も含む）の名前や構造をスキーマに格納するものである。なお、この制約要素蓄積部１１には、売り注文データと買い注文データとを個別に仮約定させた場合の解決度合いの値の型（約定タイプ）や、各制約要素について指定された解決度合いの値の型ごとの制約を解決するための制約の強度（約定レベル）や、前記第１実施形態で述べたような指向性等の定義をスキーマに蓄積するものである。これらの定義を記述する言語は、ＸＭＬやＳＧＭＬ等、種々のもののうち所定の言語を適用することができる。第１の格納部１２は、売り手や買い手のコンピュータから受信して受け付けた売り注文データＤａ及び買い注文データＤｂを格納するものである。ここで、売り注文データＤａ及び買い注文データＤｂは、前記制約要素蓄積部１１に蓄積された制約要素等の定義によって特定される電子商取引専用ランゲージ（同図中、「ｅｄｅａｌＭＬ」と表記している）に基づくものであり、具体的には前記第１実施形態において第２図に示したようなデータ構造を有している。なお、売り注文データＤａ及び買い注文データＤｂを各売り手や買い手が入力する際には、解析部１３は、第１の格納部１２に格納した売り注文データＤａ及び買い注文データＤｂを、前記制約要素蓄積部１１に蓄積されている定義に従って解析し、構造化するものである。制約解決順序決定部１４は、各売り注文データＤａ及び買い注文データＤｂにそれぞれ含まれる複数の制約要素のうち、優先順位を付けて解決すべき制約要素の順序を決定するものである。約定候補生成部１５は、複数の売り注文データＤａ及び複数の買い注文データＤｂについて制約解決順序決定部１４によって決定された順番に制約を解決し、個別に約定させる候補（組み合わせ）を生成するものである。マッチング部１６は、制約解決順序決定部１４によって生成された約定候補のなかから、一対一で売り注文データＤａと買い注文データＤｂとを約定させるものである。第２の格納部１７は、マッチング部１６で処理された約定結果データＤｃを格納するものであり、第３の格納部１８は、当該約定結果に基づく課金情報データＤｄを格納するものである。ここで、格納される約定結果データＤｃ及び課金情報データＤｄからなるデータ構造は、例えば前記第１実施形態において第４図に示したようなものである。
次に、この取引制約解決装置の動作の一部について、第６図に示すフローチャートを用いて説明する。まず、前記第１の格納部１１で受け付けて格納し、解析部１３で解析した売り注文データＤａ及び買い注文データＤｂについて、制約解決順序決定手段１４によって解決すべき制約要素の順番を決定したうえで、強制約（ａｂｓｏｌｕｔｅ）という属性値を有する制約要素の全ての制約を満たすマッチング候補のみを残して選出する（ステップＳ１１）。なお、解決すべき順序が低い制約要素を含む注文データは除外するようにすることができる。次に、ステップＳ１１で全ての強制約を満たしたマッチング候補について、マッチング数が最大になる解（組み合わせ）を全て求める。具体的には、制約要素が複数ある場合には、「２部グラフの作成」処理を行うプログラム等に従った処理を行い、制約要素同士が適合する売り注文データＤａと買い注文データＤｂとを組み合わせるようにするうよい。そして、２部グラフの作成によってもなお解が複数ある場合、すなわち、ある売り注文データＤａ又は買い注文データＤｂが複数の買い注文データＤｂ又は売り注文データＤａと組み合わされた場合は、例えばそれらの「価格」という制約要素同士を比較し、所定のアルゴリズムに従って売り注文データＤａと買い注文データＤｂとを一対一で個別に約定させるようにする。ここで、所定のアルゴリズムとは、例えば買い注文データＤｂの価格が売り注文データＤａの価格よりも大きくなるようにすることを原則として（価格が一致する場合も含まれる）、買い注文データＤｂの価格と売り注文データＤａの価格との差額が最大になるデータ同士を約定させたり、複数の組み合わせについて差額を所定の値に近づくようになるデータ同士を約定させるようにすることなどを意味している。
このような処理によって、売り注文データＤａと買い注文データＤｂとが一対一でマッチングした場合、すなわち買いが一つになった場合は（ステップＳ１３；ｎｏ）、それら売り注文データＤａ及び買い注文データＤｂを約定させるようにする。一方、上述のようなアルゴリズムに従ってもなお、解が複数となった場合には（ステップＳ１３；ｙｅｓ）、前記第１実施形態で説明したフローチャート（第４図）におけるステップＳ４〜ステップＳ６と同様に、「制約の強度（ｃｏｎｓｔｒａｉｎｔＬｅｖｅｌ）」が「ｂｅｓｔ−ｅｆｆｏｒｔ」という属性値を有する制約要素について、解決したか否かをその「解決度合いの値の型（ｃｏｎｓｔｒａｉｎｔＴｙｐｅ）」の属性値「ｂｏｏｌｅａｎ」が１又は０で表現し、それらの合計値が最高でない解（組み合わせ）を除外して（ステップＳ１４）、解（組み合わせ）が一つとなるものがあれば（ステップＳ１５；ｎｏ）、それらの組み合わせで売り注文データＤａと買い注文データＤｂとを約定させる。一方、解（組み合わせ）がいまだ複数ある場合には（ステップＳ１５；ｙｅｓ）、ｂｅｓｔ−ｅｆｆｏｒｔ善処スコアの合計が最高の値となった解（組み合わせ）からいずれか一つを選ぶことによって、その組み合わせで売り注文データＤａと買い注文データＤｂとを約定させる（ステップＳ１６）。
以上のような制約要素の解決方法を適用した取引の例を、特に解決する制約要素の順序決定から２部グラフの作成を経て約定結果が得られるまでについて、第７図〜第９図に示す具体例を利用して説明する。
この例は、あるメーカーの所定の靴について複数の売り手と買い手が取引を行う場合について示したものである。第７図に示すように、この靴の取引では、「価格」、「品質」、「期日」の３つの制約要素が設定されており、さらに「品質」については「色」及び「サイズ」の２つの属性が設定されているものとする。第７図〜第９図において、売り注文データ（売ａ、売ｂ…）及び買い注文データ（買１、買２…）の制約要素（属性も含む）は、それぞれ各データの横に、「価格」、「色」、「サイズ」、「期日」の順で示している。ここで、これら制約要素（属性も含む）の制約の強度は、各売り手及び買い手が強制約（ａｂｓｏｌｕｔｅ）とするように注文の際に入力したものとする。なお、制約要素が「＊」で示されているものについては、該当する売り手や買い手が条件を設定しなかったこと、すなわち対応する制約要素について特に限定せずに取引を行うことを希望していることを表している。なお、各売り注文データ及び買い注文データは、該当する売り手や買い手が自分の制約を入力して注文する際に、他者が入力した制約を一切知ることができない状態にしているものとする。
ここで、第７図に示した５つの買い注文データ及び５つの売り注文データは、例えば取り引き可能な靴の「色」が１００色あると仮定して、その属性値である「白」、「青」、「黒」、「赤」の４つを売買したい売り手や買い手が多数であった場合、「色」について前記４色に該当するか否かをまず第一に解決すべき制約要素であると決定したうえで、その制約要素が解決された注文データであるとする。そして、これらの注文データについて２部グラフの作成処理を行うと、同図に直線で結んだような組み合わせで各制約要素が解決されたことが分かる。すなわち、「買１」と「売ａ」及び「売ｂ」、「買２」と「売ａ」及び「売ｃ」、「買３」と「売ｄ」、「買４」と「売ａ」及び「売ｂ」がそれぞれマッチング候補として選出される。また、「買５」と「売ｅ」については制約要素が解決する相手がないため、今回の約定処理の対象外として除外される。なお、除外された注文データは、次回の約定処理に際して候補として挙げるようにするとよい。
次に第８図に示すように、前記２部グラフの作成結果の組み合わせを維持したまま、買い注文データ及び売り注文データそれぞれについて価格の高いものから順に並べ替える。そして第９図に示すように、ここでは買い注文データの価格と売り注文データの差額が最大となるようなアルゴリズムに従って、買い注文データと売り注文データとを一対一で約定させる。具体的には、「買２」と「売ａ」、「買３」と「売ｄ」、「買１」と「売ｂ」とが約定することになる。「買４」と「売ｃ」は直線で結ばれないので約定しない。このように、各売り手や買い手が提示した制約を満たした約定結果が得られることになるが、ここで約定した注文データ同士の価格に注目してみると、何れの組み合わせについても買い注文データの価格が売り注文データの価格よりも高くなっている。すなわち、価格が不一致でも約定させることがあるから、従来の価格一致（提示価格が幅を持つ場合もある）による約定システムと比較して、約定数を格段に増加させることができる。しかも約定した価格は各売り手や買い手が自ら提示した価格であるので各者が納得した価格で取り引きできることになる。その上、売り手や買い手が自己の制約を入力する際には、競合相手や将来の約定相手の制約条件を知ることがない状態であるため、約定に際して不公平感が生じることもない。さらに、約定成立後にも、各者が提示した条件を他者に開示しないようにすれば、なお一層不公平感が生じることをなくし、次回以降の取引の際に過剰な競争が起こることもなくすことができる。
なお、上述した具体例において、約定結果は第９図に示したものに限られるものではない。例えば買い注文データと売り注文データの価格の差額を各約定結果について一定の値に近づけるように約定させるアルゴリズムを採用すれば、第１０図に示すような４組の約定結果が得られ、第９図の場合よりもより多くの取引を成立させることができる。また以上の説明は、買い注文データを基準として売り注文データと約定するようにした場合であるが、その他にも、売り注文データを基準にしたり、価格について降順で並べ替えを行うなどの方法を採用すると、第９図や第１０図とは異なる約定結果が得られる場合がある。
また、マッチング候補を生成する際には、上述した基本的な２部グラフ作成理論に基づくアルゴリズムの他にも、グラフ理論の「重み付き２部グラフ最大マッチング算出」アルゴリズムなど、種々のものを適用することができる。
＜第３実施形態＞ 第１１図は、本発明の第３実施形態における取引制約解決支援装置及び取引制約解決装置からなる装置の機能構成を表すブロック図である。この装置は、製品プロファイル格納部２１、画面生成部２２、画面配信・入力解析部２３、制約設定出力部２４、顧客認証部２５、顧客プロファイル格納部２６、デフォルト設定部２７、商品選択部２８等を有している。
製品プロファイル格納部２１は、取引商品（又は役務）ごとに指定できる制約の種類（名前等）、制約の解決度合いの値の型（ｃｏｎｓｔｒａｉｎｔＴｙｐｅ）、制約の強度（ｃｏｎｓｔｒａｉｎｔＬｅｖｅｌ）、解決度合い値や制約強度のバリエーション（ｎｕｍｅｒｉｃ又はｂｏｏｌｅａｎ，ａｂｓｏｌｕｔｅ又はｂｅｓｔ−ｅｆｆｏｒｔ等）等を定義した定義データファイルを格納するものである。この定義データファイルは、ＸＭＬ文書とすることが望ましいが、必ずしもこの限りではない。画面生成部２２は、前記定義データに基づいて売り手や買い手（顧客）が使用する端末コンピュータのユーザインタフェースとなる制約設定画面を生成するものである。画面配信・入力解析部２３は、生成された制約設定画面を顧客の端末コンピュータに送信するとともに、入力された顧客ごとの制約内容を受信するものであり、本発明のインタフェース出力部及び注文データ読込部の機能を兼ねている。この機能は、具体的には一般的なＷｅｂサーバ等により実現することができる。また、顧客は端末コンピュータにおいて一般的なブラウザに前記制約設定画面を表示させて制約内容などの必要事項を入力・送信するようにするとよい。制約設定出力部２４は、前記解析された制約内容を前記定義データに基づいて解析しＸＭＬで記述した注文データに変換したうえで、売買の注文データを約定させるマッチング部へ出力するものである。
また、顧客認証部２５は、顧客のブラウザからのアクセスを受け付けた場合、顧客ごとのＩＤやパスワード等によって顧客を認証するものである。顧客プロファイル格納部２６は、認証された顧客が入力した制約内容に基づいて、顧客ごとのプロファイルを作成しそれを格納するものである。デフォルト設定部２７は、前記格納された顧客プロファイルに基づいて、顧客ごとの制約デフォルトを設定して、制約デフォルトファイル（望ましくはＸＭＬ文書）を作成するものである。しかして、前記画面生成部２２では、この制約デフォルトファイルと前記定義データファイルの両方の内容に基づいて、顧客ごとの制約設定画面を生成するようにしている。このようにすることで、２回目以降に顧客がアクセスした場合には、前回までの取引内容に基づいたデフォルト値が予め記載された画面を利用することができるので、取引内容に相違がなければ少ない操作で制約内容を入力することができる。さらにまた、商品選択部２８は、前記顧客認証部２５で認証された顧客が選択した取引商品を受け付けるものである。そして、前記画面生成部２２において選択された商品の制約画面を、製品プロファイル格納部２１で格納されている商品の定義データに基づく当該製品に特化した制約画面を生成するようにすると、顧客が制約内容を入力する際の利便性をさらに向上することができる。
なお、電子市場（マーケット）の管理者側が独自に取扱商品ごとの定義データを編集する際には、第１２図に示すような取引制約解決支援装置を利用すればよい。この取引制約解決支援装置は、製品プロファイル格納部２１、画面配信・入力解析部２３、管理者認証部２９、プロファイル編集部３０を備えている。製品プロファイル格納部２１、及び画面配信・入力解析部２３は、概ね第１１図に示したものと同様の機能を有するものである。管理者認証部２９は、管理者が自己の端末コンピュータのブラウザ等からのアクセスを画面配信・入力解析部（Ｗｅｂサーバ）２３で受け付けた場合、管理者ごとのＩＤやパスワードによって当該管理者を認証するものである。プロファイル編集部３０は、認証された管理者のブラウザにプロファイル編集関連画面が表示された場合、その画面に入力された製品の定義データに対する追加、変更、削除、閲覧等を受け付けて、定義データを編集するものである。編集された定義データは製品プロファイル格納部２１に改めて格納されることになる。このようにすることで、管理者は外部の汎用コンピュータからこの取引制約解決支援装置にアクセスすることができるので、管理者が個別に製品のプロファイル（定義データ）を直接管理するという負担を軽減することができる。
＜第４実施形態＞ 第１３図は、本実施形態における取引制約解決システムの構成図を示すものである。同図中、Ｍ１，Ｍ２は、それぞれ別の電子市場における取引支援装置を示している。また「Ｍ２Ｍ ＢｒｏｋｅｒＡｇｅｎｔ」は、前記取引支援装置Ｍ１，Ｍ２間に介在するエージェント装置である。各取引支援装置Ｍ１，Ｍ２は、例えば前記第１実施形態や第２実施形態に説明したようなものが該当し、共に取引における制約等を定義付けたＸＭＬで特定される電子商取引専用ランゲージ（ｅＤｅａｌＭＬ）を解析・解読することができ、当該ｅＤｅａｌＭＬに基づいてそれぞれ受け付けた買い注文データと売り注文データとを約定させる機能を有している。
このシステムでは、各取引制約解決装置Ｍ１，Ｍ２は、約定させることができなかった注文データについてＸＭＬで記載した約定不成立データを作成する。この約定不成立データは、当該注文データに係る制約内容を示す＜ｏｒｄｅｒ＞要素、約定結果（約定したものだけでなく、約定しなかったものが含まれる場合もある）を示す＜ｃｏｎｔｒａｃｔｕａｌ＞要素、課金情報に係る＜ｃｈａｒｇｅ＞要素を並列的に有するデータ構造を備えたものである。そして各取引制約解決装置Ｍ１，Ｍ２は、この約定不成立データに基づいて、その内容を要約した一時的プロファイルを作成して格納する。この一時的プロファイルもＸＭＬで記述された文書ファイルである。なお、前記データ構造における＜ｏｒｄｅｒ＞要素、＜ｃｏｎｔｒａｃｔｕａｌ＞要素、＜ｃｈａｒｇｅ＞要素は、それぞれ独立ファイルとして保存したり、データベースの独立レコードとして保存することもできる。また、＜ｏｒｄｅｒ＞要素は必須の要素であるが、＜ｃｏｎｔｒａｃｔｕａｌ＞要素及び＜ｃｈａｒｇｅ＞要素は付加的な要素であるためこれらを含まない注文データを利用することも可能である。さらには＜ｏｒｄｅｒ＞要素を、制約等の定義部分とその定義に基づく属性値を有する具体的な注文内容部分とを別個の独立ファイルに保存しておくこともできる。
一方、エージェント装置は、各取引制約解決装置Ｍ１，Ｍ２で格納されている一時的プロファイルを読み込み、その読み込んだ一時的プロファイルに基づく注文データを他の各取引制約解決装置で約定させられるか否かを判断し、約定可能と判断した場合には、約定しなかった注文データをそれを格納している取引支援装置から抽出し、その注文データを約定可能と判断された取引支援装置へ移送する。このようにすることで、単一のマーケットでだけで約定処理を行うよりも遙かに約定可能性を高めることができる。このことにより、電子市場の活性化にも大きく貢献することができる。
なお、本発明は上記各実施形態に限られるものではなく、各実施形態を組み合わせて適用したり、各部の具体的構成を本発明の趣旨を逸脱しない範囲で種々変更するなど、様々な態様とすることが可能である。
産業上の利用可能性
本発明によれば、以上に詳述したように、これまで電子市場に売買注文として発注することができなかったような多様な制約を有する商取引について、それらの制約の解決を図ることが可能である。すなわち、従前は電子市場になじまなかった複雑な条件を有する取引も電子市場上で取り扱うことができるようになる。また、取り引きされる異なる種類や属性の商品や役務を、同一の電子市場で同時に取り扱うことや、その電子市場では約定させられなかったような商品や役務を他の電子市場と融通しあったり、顧客毎や取扱い商品・役務毎のプロファイルを作成して次回以降の取引をさらに円滑に行うことなど、これまで人手やコンピュータの処理ではなし得なかったことも実現することができる。
【図面の簡単な説明】
第１図は、本発明の第１実施形態における機能構成を示すブロック図である。
第２図は、同実施形態における買い注文データのデータ構造を示す説明図である。
第３図は、同実施形態における取引制約解決装置の動作の一部を示すフローチャートである。
第４図は、同実施形態における約定結果データ及び課金情報データの構造を示す説明図である。
第５図は、本発明の第２実施形態における機能構成を示すブロック図である。
第６図は、同実施形態における取引制約解決装置の動作の一部を示すフローチャートである。
第７図は、同実施形態における２部グラフの作成による約定過程の具体例を示す説明図である。
第８図は、同実施形態における２部グラフの作成による約定過程の具体例を示す説明図である。
第９図は、同実施形態における２部グラフの作成による約定結果の具体例を示す説明図である。
第１０図は、同約定結果の他の具体例を示す説明図である。
第１１図は、本発明の第３実施形態における機能構成を示すブロック図である。
第１２図は、同実施形態における他の機能構成を示すブロック図である。
第１３図は、本発明の第４実施形態におけるシステム全体を示す概略説明図である。

Claims (22)

1. 電子市場において取引に係る一つ以上の制約を解決するための装置であって、
   解決すべき一つ以上の制約要素をそれぞれ定義付けて格納する制約要素格納部と、前記制約要素に従って受け付ける売り注文データと買い注文データとを仮約定させた場合における各制約要素の解決度合いの値の型を制約要素毎の属性として定義付けて格納する約定タイプ格納部と、前記約定タイプ格納部において指定された解決度合いの値の型に基づいて解決処理を行う際の制約の強度を制約要素毎の属性として定義付けて格納する約定レベル格納部と、取引に係る売り注文データと買い注文データとを前記制約要素に従って受け付ける注文データ受付部と、前記約定タイプ格納部に格納された解決度合いの値の型及び前記約定レベル格納部に格納された制約の強度に基づいて一つ以上の制約を解決する処理を行う解決処理部に対して前記注文データ受付部で受け付けた売り注文データ及び買い注文データを出力する注文データ出力部とを具備してなることを特徴とする取引制約解決装置。
2. 電子市場において取引に係る一つ以上の制約を解決するための装置であって、
   解決すべき一つ以上の制約要素をそれぞれ定義付けて格納する制約要素格納部と、前記制約要素格納部に格納された制約要素に従って受け付ける売り注文データと買い注文データとを仮約定させた場合における各制約要素の解決度合いの値の型を制約要素毎の属性として定義付けて格納する約定タイプ格納部と、前記約定タイプ格納部において指定された解決度合いの値の型に基づいて解決処理を行う際の制約の強度を制約要素毎の属性として定義付けて格納する約定レベル格納部とを具備してなることを特徴とする取引制約解決装置。
3. 前記制約タイプ格納部に格納された解決度合いの値の型が、多値又は二値のいずれかの解決度合い値を取るようにしていることを特徴とする請求の範囲第１項又は第２項記載の取引制約解決データ構造。
4. 前記制約レベル格納部に格納された制約の強度が、絶対的な制約を表す強制約又は希望的な制約を表す善処制約のいずれかの制約レベル値を取るようにしていることを特徴とする請求の範囲第１項乃至第３項記載の取引制約解決データ構造。
5. 少なくとも一の制約要素が所定の幅を許容されている場合、制約要素の属性として、前記解決度合いの値を定める指向性を定義付けて格納する指向性格納部をさらに有し、前記指向性格納部に格納された指向性が、前記所定の幅のうちいずれかの値を取るようにしていることを特徴とする請求の範囲第１項乃至第４項記載の取引制約解決装置。
6. 前記約定タイプ格納部に格納した解決度合いの値の型と前記約定レベル格納部に格納した制約の強度に従って制約が解決され約定された結果を示す約定結果データを格納する約定結果格納部をさらに具備していることを特徴とする請求の範囲第１項乃至第５項記載の取引制約解決装置。
7. 前記約定タイプ格納部に格納した解決度合いの値の型と前記約定レベル格納部に格納した制約の強度に従って制約が解決され約定された際に課金すべき情報を示す課金情報データを格納する課金情報格納部をさらに具備していることを特徴とする特徴とする請求の範囲第１項乃至第６項記載の取引制約解決装置。
8. 電子市場における取引に係る約定に必要な一つ以上の制約要素の定義を蓄積する制約要素蓄積部と、文字データ及びその文字データに対する付加情報を区別して記述し得る言語で記述され前記制約要素蓄積部で蓄積した一つ以上の制約要素の定義によって特定される電子商取引専用ランゲージを用いて受け付けた買い注文データ及び売り注文データとを格納する第１の格納部と、第１の格納部で格納した買い注文データ及び売り注文データを、前記制約要素の定義に従って解析する解析部と、解析部で解析された買い注文データ及び売り注文データを、前記制約要素の定義に従って約定させるための候補を生成する約定候補生成部とを具備してなることを特徴とする取引制約解決装置。
9. 電子市場における取引に係る約定に必要な一つ以上の制約要素の定義を蓄積する制約要素蓄積部と、タグ及びタグで囲んだ文字データからなる要素の名前及びそれらの構造を記述し得る言語を用いて記述され前記蓄積部で蓄積した制約要素の定義によって特定される電子商取引専用ランゲージに基づいて受け付けた買い注文データ及び売り注文データとを格納する第１の格納部と、第１の格納部で格納した買い注文データ及び売り注文データを、前記制約要素の定義に従って解析する解析部と、解析部で解析された買い注文データ及び売り注文データを前記制約要素の定義に従って約定させるための候補を生成する約定候補生成部とを具備してなることを特徴とする取引制約解決装置。
10. 制約要素蓄積部が、定義付けた解決すべき一つ以上の制約要素と、前記各制約要素毎の属性として定義され、それら制約要素に従って受け付ける売り注文データと買い注文データとを仮約定させた場合における各制約要素の解決度合いの値の型と、前記各制約要素毎の属性として定義され、前記解決度合いの値の型に基づいて解決処理を行う際の制約の強度とを少なくとも蓄積していることを特徴とする請求の範囲第８項又は第９項記載の取引制約解決装置。
11. 一つ以上の制約要素、制約要素に含まれる一つ以上の属性、又は一つ以上の属性を含む一つ以上の制約要素のうち、解決すべき制約要素又は属性の解決順序を決定する制約解決順序決定手段をさらに具備してなることを特徴とする請求の範囲第８項乃至第１０項記載の取引制約解決装置。
12. 前記約定候補生成部で生成された買い注文データと売り注文データに基づいて、それら買い注文データと売り注文データとを前記定義された制約要素に従って約定させる処理を行うマッチング部と、少なくともマッチング部で約定された買い注文データ及び売り注文データを格納する第２の格納部とをさらに具備してなることを特徴とする請求の範囲第８項乃至第１１項記載の取引制約解決装置。
13. 前記第２の格納部が、約定候補生成部又はマッチング部の少なくともいずれか一方の処理において従った制約要素のうち、利用された制約要素と利用されなかった制約要素とを区別して格納することを特徴とする請求の範囲第８項乃至第１２項記載の取引制約解決装置。
14. 前記マッチング部の処理に基づいて制約が解決され約定された際に課金すべき情報を示す課金情報データを格納する第３の格納部をさらに具備してなることを特徴とする請求の範囲第８項乃至第１３項記載の取引制約解決装置。
15. 第１の格納部は、買い注文データ及び売り注文データを提示した買い手及び売り手のそれぞれが他者の提示したデータを知ることができない状態で受け付けたデータを格納するものであることを特徴とする請求の範囲第８項乃至第１４項記載の取引制約解決装置。
16. 前記マッチング部が、買い注文データに含まれる制約要素の一つである価格と、売り注文データに含まれる制約要素の一つである価格とが一致しない場合でも、買い注文データと売り注文データとを約定させるものであることを特徴とする請求の範囲第８項乃至第１５項記載の取引制約解決装置。
17. 電子市場における取引に係る約定に必要な一つ以上の制約要素の定義と、前記各制約要素毎の属性として定義されそれら制約要素に従って受け付ける売り注文データと買い注文データとを仮約定させた場合における各制約要素の解決度合いの値の型と、前記各制約要素毎の属性として定義され前記解決度合いの値の型に基づいて解決処理を行う際の制約の強度とを少なくとも格納し、さらに前記制約の定義、解決度合いの値の型及び制約の強度に基づいて受け付けた買い注文データ及び売り注文データとを付加的に格納し得るように構成した第１のデータ部を少なくとも有し、前記第１のデータ部における約定タイプ定義データの解決度合い及び約定レベル定義データの解決条件に従って約定された買い注文データと売り注文データの約定結果を格納する第２のデータ部、又は前記約定に際して課金すべき課金情報を格納する第３のデータ部のうち、いずれか一方又は両方を付加的に設け得るように構成していることを特徴とする取引制約解決データ構造。
18. 電子市場における取引に係る売り注文データ又は買い注文データの少なくとも一方を読み込む注文データ読込部と、請求の範囲第１７項記載の取引制約解決データ構造のうち少なくとも第１のデータ部における制約要素の定義、解決度合いの値の型及び制約の強度からなる定義データを格納する定義データ格納部と、前記注文データ読込部で読み込んだ注文データを前記定義データ格納部に格納した定義データに基づいて解析し、売り注文データと買い注文データとを約定させる処理を行うマッチング部に出力する注文データ出力部とを具備してなることを特徴とする取引制約解決装置。
19. 請求の範囲１７項記載の取引制約解決データ構造のうち少なくとも第１のデータ部における制約要素の定義、解決度合いの値の型及び制約の強度からなる定義データに基づいて、電子市場における取引の取引内容を受け付けるための取引受付インタフェースを生成するインタフェース生成部と、前記インタフェース生成部で生成した取引受付インタフェースを出力するインタフェース出力部と、インタフェース出力部で出力した取引受付インタフェースに基づいて入力された取引内容データを、前記定義データに従った取引内容データファイルに変換するデータ変換部とを具備してなることを特徴とする取引制約解決支援装置。
20. 前記取引受付インタフェースで受け付けた取引データ内容に基づいて、当該取引に係る顧客である売り手又は買い手個別の顧客プロファイルデータを作成し格納する顧客プロファイル格納部と、前記顧客プロファイル格納部に格納した顧客プロファイルデータに基づいて、前記定義データの一部又は全部について顧客毎のデフォルト定義データを設定するデフォルト設定部をさらに具備し、前記インタフェース生成部が、前記定義データ及びデフォルト定義データに基づいた取引受付インタフェースを生成するようにしていることを特徴とする請求の範囲第１９項記載の取引制約解決支援装置。
21. 請求の範囲第１７項記載の取引制約解決データ構造のうち少なくとも第１のデータ部における制約要素の定義に基づいて作成された、電子市場における取引の取引内容データを受け付ける取引内容データ受付部と、取引内容データ受付部で受け付けた取引内容データを格納する取引内容データ格納部とを具備してなることを特徴とする取引制約解決装置。
22. 請求の範囲第１７項記載の取引制約解決データ構造のうち少なくとも第１のデータ部における制約要素の定義に基づいて作成され受け付けた注文データを受け付ける注文データ受付部と、注文データ受付部で受け付けた注文データを格納する注文データ格納部と、注文データ格納部で格納した注文データを前記第１のデータ部における制約要素の定義に従って約定させる処理を行うマッチング部と、マッチング部において約定しなかった注文データを格納する約定不成立データ格納部と、前記約定不成立データ格納部で格納した注文データに基づく一時的なプロファイルを格納するプロファイル格納部とを具備してなる、電子市場における取引の取引内容データ取引制約解決データ構造を解析し得る複数の電子市場それぞれの取引制約解決装置と、前記取引制約装置におけるプロファイル格納部に格納されたプロファイルを読み込み、その読み込んだプロファイルに基づく注文データを他の取引制約解決装置で約定可能か否かを判断する判断機能と、前記判断機能によって前記注文データが他の取引支援装置で約定可能と判断された場合に、その注文データを前記取引制約解決装置における約定不成立データから抽出し、当該他の取引支援装置の注文データ受付部に移送して受付させるデータ移送機能を有するエージェント装置とから構成してなることを特徴とする取引制約解決システム。

Images