JPWO2002027575A1 - 電子取引仲介方法、組合せ候補生成方法、電子取引仲介装置および記録媒体 - Google Patents

Abstract

複数の項目からなる複数の取引希望条件をネットワークを介して複数のユーザの端末から収集し、この複数の取引希望条件を組み合わせて、各ユーザの取引希望条件のうちの複数の項目を満足する複数の取引候補を生成する。この生成された取引候補をその取引候補に係る取引希望条件を提出した取引の当事者としての各ユーザの端末に提示する。複数の取引候補のうちの特定の取引候補に対して、その取引候補に係る取引の当事者としてのユーザ全員の端末から承認を得られて取引が成立したとき、その成立した取引の当事者としてのユーザ全員の端末に取引が成立した旨を通知することにより、三者以上の当事者間の複雑な取引の仲介を可能にする。

Description

技術分野
この発明は、例えば、インターネットを媒体として複数当事者間の取引を仲介する電子取引仲介方法および電子取引仲介システムに関する。
背景技術
最近、インターネット技術の開発に支えられた電子商取引の普及がめざましい。例えば、インターネット上の仲介ビジネスとしては、仲介者（仲介サーバ）が、消費者により登録された購入条件に合う販売業者を見つけるという逆オークション方式（プライスライン特許　米国特許第５，７９４，２０７号）がある。この方式は、例えば、消費者は、「東京−ニューヨーク間の往復航空券を３０万円以内で購入したい」という、希望する商品の購入条件を仲介者に送信する。仲介者は、上記購入条件を各社（Ａ社、Ｂ社、Ｃ社）に伝達する。各社は上記条件から見積もりを仲介者に提示する。各社見積もりは、Ａ社は３２万円、Ｂ社は３１万円、Ｃ社は２９万円であったとする。仲介者は各社見積もりを対比して、消費者の希望条件に合致する商品を選択し、その内容を消費者に連絡するというものである。
また、販売業者が提示した商品情報を仲介者が収集蓄積しておき、消費者に提供する仲介ビジネス（通信販売のインターネット版のようなもの）もある（特開平１０−３２０４７０号公報、特開平１０−２４０８２３号公報）。これは、予め各社の商品情報をサーバに蓄積しておき、消費者はその中から希望条件に合致するものを選ぶ。商品情報は各社が提示した内容で固定されているため、消費者は希望条件についてある程度の妥協を余儀なくされる。
このように、従来の電子商取引は、業者側と消費者側との１対１の取引を成立させるためのものであり、複数の業者を組み合わせて１つの取引を成立させたり、複数の業者と複数の顧客とを組み合わせて複数の取引を成立させたりといったサービス提供側とそのサービスを受ける側の少なくとも一方が複数いるような複雑な取引を仲介するものはなかった。
そこで、本発明は、業者側と消費者側との１対１の２当事者間の取引のみならず、従来にはない、業者側と消費者側の少なくとも一方が複数いるような３者以上の当事者間の複雑な取引も仲介可能な電子取引方法および電子取引装置を提供することを目的とする。
発明の開示
この発明の電子取引仲介方法および電子取引仲介装置は、複数の項目からなる複数の取引希望条件をネットワークを介して複数のユーザの端末から収集し、この複数の取引希望条件を組み合わせて、各ユーザの取引希望条件のうちの複数の項目を満足する複数の取引の組合せ方の候補を生成する。この生成された取引候補は、その取引候補に係る取引希望条件を提出した取引の当事者としての各ユーザの端末に提示される。この複数の取引候補のうちの特定の取引候補に対して、その取引候補に係る取引の当事者としてのユーザ全員の端末から承認を得られて取引が成立したとき、前記成立した取引の当事者としてのユーザ全員の端末に取引が成立した旨を通知することにより、三者以上の当事者間の複雑な取引の自動的な仲介を可能にする。
また、特定の取引候補に係る取引が成立したとき、その特定の取引候補に含まれる取引希望条件を少なくとも１つ含む他の取引候補を削除して、取引可能な取引候補のみをユーザの端末に提示することにより、ユーザに提示した取引候補に取引が成立したものがあれば、ユーザへの提示内容に、それを直ちに反映させる。好ましくは、削除した取引候補を承認していたユーザに対し、その承認が無効になった旨を通知する。
また、前記取引候補をその取引の当事者としてのユーザに提示する際、そのユーザの端末から提出された取引希望条件の満足度を数値化し、その満足度の高いものを優先して提示することにより、ユーザが最も承認し易い取引候補を効果的に提示する。
発明を実施するための最良の形態
以下、この発明の実施の形態について図面を参照して説明する。
図１は、本発明の実施形態に係る電子取引仲介システムの全体の構成例を示したもので、取引仲介者により運営されるサービスセンターの取引仲介装置１と、複数（ここでは、例えば３つ）の顧客端末２と、複数（ここでは、例えば２つ）の業者端末３とが、例えばインターネット等の通信ネットワーク４を介して、互いに通信可能なように接続されている。
取引仲介装置１には、業者登録部１１、顧客登録部１２、組合せ候補閲覧・選択部１３、組合せ候補消去部１４、属性・取引希望条件データベース１５（以下、簡単にデータベース１５と呼ぶこともある）、スケジューリング部１６、組合せ候補データベース１７（以下、簡単にデータベース１７と呼ぶこともある）、組合せ候補消去・変更通知部１８、組合せ候補契約成立通知部１９から構成されている。
顧客端末２は、例えば、顧客属性と取引希望条件等のデータを入力したり、取引仲介装置１から送られてきた情報を提示したり等するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）２１、通信ネットワーク４に接続して、取引仲介装置１にアクセスするためのアクセス部２２から構成されている。
業者端末３、業者属性と取引希望条件等のデータを入力したり、取引仲介装置１から送られてきた情報を提示したり等するためのＧＵＩ３１、通信ネットワーク４に接続して、取引仲介装置１にアクセスするためのアクセス部３２から構成されている。なお、顧客用および業者用端末の機能は、インターネット端末の汎用のブラウザにより実現され、取引仲介装置１へのアクセス時にユーザＩＤとパスワードなどでユーザ認証を行う形式であってもよい。
業者登録部１１は、業者端末３のＧＵＩ３１を用いて入力された業者属性と取引希望条件等のデータを通信ネットワーク４を介して受信し、取引への参加権利を持つ不特定多数の業者からの業者属性と取引希望条件等のデータを業者エントリーデータとして収集し、属性・取引希望条件データベース１５に登録するためのものである。
業者端末３からは、既にデータベース１５に登録された自らの取引希望条件等を閲覧し、変更することも可能である。なお、業者登録部１１は、業者端末３に設けることも可能である。
顧客登録部１２は、顧客端末２のＧＵＩ２１を用いて入力された顧客属性と取引希望条件等のデータを通信ネットワーク４を介して受信し、取引への参加権利を持つ不特定多数の顧客からの顧客属性と取引希望条件等のデータを顧客エントリーデータとして収集し、属性・取引希望条件データベース１５に登録するためのものである。
顧客端末２からは、既にデータベース１５に登録した自らの取引希望条件を閲覧し、変更することも可能である。顧客登録部１２は、顧客端末２に設けることも可能である。
業者登録部１１、顧客登録部１２からデータベース１５に登録される取引希望条件は、例えば、業務内容、希望料金に関する条件を含み、さらに、例えば、業務を開始する場所、業務を終了する場所、業務を開始する時間帯、業務を終了する時間帯などが含まれていてもよい。例えば、取引の対象となる業務が共同輸送業務であれば、各業者と各顧客は、取引希望条件として、荷物の種類、積載量、さらに業務を開始する場所としてピッキング場所、業務を終了する場所として目的地、業務を開始する時間帯としてピッキング希望時間、業務を終了する時間帯として荷物到着時間などのデータを登録することになる。
属性・取引希望条件データベース１５は、業者と顧客の属性、取引希望条件などのデータを、属性や取引希望条件を検索キーとして検索可能なように保存する。
スケジューリング部１６は、属性・取引希望条件データベース１５に保存されている取引希望条件を基に、業者と顧客との双方の希望取引条件が同時に満足するように、複数の組合せ候補を作成する。この組合せ候補としては、複数の業者の取引希望条件と１つの顧客の取引希望条件との組合せ、１つの業者の取引希望条件と複数の顧客の取引希望条件との組合せ、複数の業者の取引希望条件と複数の顧客の取引希望条件との組合せとがあり得る。
これらの組合せ候補の作成は、例えば、データベース１５の登録内容が更新される度に実施され、作成された組合せ候補は、取引希望条件組合せ候補データベース１７に蓄積される。重複する組合せ候補は作成せず、全ての可能な取引希望条件組合せ候補を作成し終えた場合は、例えば、属性・取引希望条件データベース１５の登録内容が更新されるまで、スケジューリング部１６は停止する。
スケジューリング部１６は、例えば、取引の対象となる業務が共同輸送業務であれば、複数の運送業者のそれぞれが取引希望条件として登録した輸送ルートを複数組合せることで、ある顧客が取引希望条件として登録した荷物輸送ルートと指定時間帯、輸送料金を満足できる組合せを作成する。逆に、複数の顧客が取引希望条件として登録した荷物輸送業務を複数組合せることで、ある業者が希望取引条件として登録した荷物輸送ルートの希望積載率を満足できる組合せを作成する。
また、取引の対象となる業務が旅行ツアーであれば、複数の鉄道運輸・輸送業者のそれぞれが登録した交通機関の前売りチケットや、複数の旅館・ホテル業者のそれぞれが登録した宿泊チケットなどを複数組合せることで、ある顧客の希望した観光ルート、期間、料金を満足できる組合せを作成する。
もちろん、複数の業者の取引希望条件と複数の顧客の取引希望条件とを組合せる場合も有り得る。
スケジューリング部１６のスケジューリング方法としては、ここでは特に限定しないが、各業者及び各顧客の満足度を定量的に見積もる基準となる演算式を定義し、組合せ候補に含まれる業者及び顧客の満足度がなるべく均等になる公平な組合せ候補を抽出することが望ましい。公平な組合せ候補を作成することにより、これらの組合せ候補を業者及び顧客に提示した際に、その組合せ候補に関連する全ての業者及び顧客の承諾が同時に得られる可能性が高くなる。
例えば、組合せに含まれる全ての業者と顧客の満足度の総和を大きくすることを最適化の目的関数として各組合せ候補について評価値を求め、その値が上位から一定数の組合せ候補を探索により列挙し、さらにこれらの組合せ候補の中から各業者及び各顧客の満足度のうちの最小値が閾値以上になる組合せ候補だけを抽出する方法などが有る。
組合せ候補閲覧・選択部１３は、業者端末３や顧客端末２からの組合せ候補閲覧希望要求を受けた際に、当該業者や当該顧客の登録した取引希望条件の含まれる組合せ候補を、組合せ候補データベース１７より抽出し、その抽出した組合せ候補のデータを閲覧可能なように当該端末へ送信したり、業者端末３、顧客端末２にて閲覧された組合せ候補中から、その業者や顧客が承認できる組合せ候補を少なくとも１つ選択させるためのものである。なお、組合せ候補閲覧・選択部１３は、業者端末３や顧客端末２に設けることも可能である。
組合せ候補契約成立通知部１９は、組合せ候補のうち、業者側、顧客側の双方から承認が得られ、取引の成立した組合せに係る取引希望条件を満足した全ての業者、顧客へその旨を通知するためのものである。
組合せ候補消去部１４は、取引が成立した組合せに係る取引希望条件のうちのいずれか１つでも含む他の組合せ候補の全てを、組合せ候補データベース１７から抹消し、また抹消された組合せ候補を閲覧中の顧客端末２および業者端末２に対し、組合せ候補消去・変更通知部１８を用いて、抹消された組合せ候補の情報を通知し、各閲覧内容に反映させる。
次に、図１の取引仲介装置１の処理動作について、説明する。なお、顧客および業者は双方ともユーザと呼ぶ。
図２は、取引仲介装置１がユーザの端末２、３から新たな取引希望条件を受け付ける際の処理動作を説明するためのフローチャートである。取引希望条件は、ユーザのＩＤ、契約対象となる業務の内容に関して、その情報を含み、さらに業務を開始する場所、業務を終了する場所、業務を開始可能な時間帯、業務を終了可能な時間帯などのデータを含む。
ユーザが端末２、３のＧＵＩ２１、３１を利用してサービスセンターの取引仲介装置１に接続し、新たな取引希望条件のデータを送信すると、取引仲介装置１の業者登録部１１、顧客登録部１２にて、それを受信し（ステップＳ１０１）、当該取引希望条件を識別するためのエントリーＩＤを発行する（ステップＳ１０２）。
そして、その取引希望条件を送ってきたユーザＩＤ（属性）と合わせて属性・取引希望条件データベース１５に登録し（ステップＳ１０３）、当該ユーザに登録完了の旨通知する（ステップＳ１０４）。
さらに、属性・取引希望条件データベース１５を検索し、新規に登録された取引希望条件と、それぞれの取引希望条件の一部を相互に満足し、１対１の組合せが可能な他の取引希望条件を全て発見し（ステップＳ１０５）、後にスケジューリング部１６が組合せ候補を作成する際の効率化のため利用可能なように、新規に登録された取引希望条件と、それと組合せ可能な他の取引希望条件とが相互に参照可能にするためのリンク情報として、その発見された組合せ可能な他の取引希望条件のエントリーＩＤを、データベース１５に記録する（ステップＳ１０６）。なお、エントリーＩＤ以外に取引希望条件の記憶アドレス情報等でもリンク情報になり得る。
図３、図４は、属性・取引希望条件データベース１５に蓄積された登録内容の一例を示したもので、例えば、運送業者と顧客をユーザとした場合を示している。図３は、業者側の登録内容（業者セグメント）で、図４は顧客側の登録内容（顧客セグメント）である。なお、説明の簡単のために、取引希望条件から時間に関する条件は省いてある。また、１つの業者や顧客がそれぞれ複数の取引希望条件をエントリーする場合もあり得る。
この例では、運送業者の予定経路と顧客の指定した荷物の経路の間で重複する経路がある場合、両者は同じ組合せ候補に含まれる可能性があるため、相互にリンク情報を付加する。例えば、図３のエントリーＩＤ「Ｂ４」が新規に登録された取引希望条件であるとすると、それに対応して、図３のエントリーＩＤ「Ｂ４」のリンク情報には、新規登録の取引希望条件にある経路が静岡、大阪であるので、その経路を含む顧客側の希望取引条件であるエントリーＩＤ「Ｓ２」「Ｓ３」が追加され、図４の顧客セグメントの、エントリーＩＤ「Ｓ２」「Ｓ３」のそれぞれのリンク情報にエントリーＩＤ「Ｂ４」が追加されている。
次に、図５を参照して取引仲介装置１がユーザから組合せ候補の閲覧要求を受け付けた際の処理動作について説明する。ユーザが端末２、３のＧＵＩ２１、３１を用いて、取引仲介装置１に接続し、所望の取引希望条件のエントリーＩＤとともに閲覧要求を送信すると、それを取引仲介装置１の組合せ候補閲覧・選択部１３にて受信し（ステップＳ２０１）、指定された取引希望条件を含む組合せ候補を組合せ候補データベース１７から検索し、抽出する（ステップＳ２０２）。この抽出した組合せ候補を要求元のユーザに返信するとともに（ステップＳ２０８）、どのユーザがどの組合せ候補を閲覧中かを閲覧履歴情報として記憶する（ステップＳ２０４）。当該ユーザから閲覧終了の通知を受信する（ステップＳ２０５）まで当該履歴情報は保存する。なお、ステップＳ２０４とステップＳ２０５の処理は省略し得る。
次に、図６を参照して、スケジューリング部１６が組合せ候補を作成するための処理の一部である、可能性のある組合せを効率良く列挙するための処理動作について説明する。ここで列挙された組合せ候補のうち、前述した方法により満足度を数値化し、業者と顧客の満足度の高い候補が、組合せ候補データベース１７に記録される。
まず、属性・取引希望条件データベース１５に登録された取引希望条件を優先順位に従い選択し、基点とする（ステップＳ４０１）。優先順位は、重要なユーザ順でも良いし、利用率の高いユーザを優先する方法や既に閲覧要求のあるユーザを最優先にするなど幾つかの決定方法が考えられる。また、未だ基点として選択されていない取引希望条件や新規に登録された取引希望条件を優先的に基点として選択してもよい。
次に、基点として選択された取引希望条件のリンク情報を辿った探索により、予め定めた上限の範囲内で可能な組合せ候補を列挙する（ステップＳ４０２）。
ここで、図７に示した、図４のエントリーＩＤ「Ｓ３」の取引希望条件を基点とした場合の探索木を参照して、ステップＳ４０２の組合せ候補の列挙方法について説明する。図７の探索木の各ノードは、その時点で親ノードに追加される取引希望条件を示す。また、１つの組合せ候補として組合せ可能な取引希望条件の数の上限値は、顧客側が３つ、業者側が２つであるとする。
エントリーＩＤ「Ｓ３」の取引希望条件に付加されているリンク情報は、図４より｛Ｂ１、Ｂ２、Ｂ３、Ｂ４｝である。すなわち、このリンク情報の集合の部分集合の取引希望条件の組合せであれば、エントリーＩＤ「Ｓ３」の取引希望条件と組み合わせることが可能である。
ここで、上記上限から、１つのノードの要素数を２以下とする。すなわち、エントリーＩＤ「Ｓ３」の取引希望条件を基点とした場合、それから展開されるノードとして、集合｛Ｂ１、Ｂ２、Ｂ３、Ｂ４｝の要素が２以下の全ての部分集合｛Ｂ１｝｛Ｂ２｝…｛Ｂ１、Ｂ３｝…｛Ｂ２、Ｂ４｝…｛Ｂ３、Ｂ４｝が列挙される。すなわち、これらの取引希望条件の部分集合はいずれもその親ノードであるエントリーＩＤ「Ｓ３」の取引希望条件と組み合わせて、１つの組合せ候補を構成し得る。
さらに、ノード｛Ｂ１、Ｂ３｝を展開する、すなわち、ノード｛Ｂ１、Ｂ３｝に繋がるノードを求める。図３からエントリーＩＤ「Ｂ１」「Ｂ３」の取引希望条件のそれぞれのリンク情報の和集合が｛Ｓ１、Ｓ２、Ｓ３｝であるので、ここからノード｛Ｂ１、Ｂ２｝の組合せ要素の１つである「Ｓ３」を除いた取引希望条件の集合｛Ｓ１、Ｓ２｝の部分集合｛Ｓ１｝｛Ｓ２｝｛Ｓ１、Ｓ２｝が列挙される。すなわち、これらの取引希望条件の部分集合はいずれもその親ノードの取引希望条件の集合｛Ｂ１、Ｂ３｝に追加して、エントリーＩＤ「Ｓ３」の取引希望条件と組み合わせて、１つの組合せ候補を構成し得る。本例では、｛Ｓ１、Ｓ２｝のノードは、取引に絡む顧客が上限の「３」に達したので、それ以上の展開は行わない。
以上のようにして、各ノードに対し、そのノードから展開される取引希望条件の集合を列挙していき、各ノードの取引希望条件の部分集合をその親ノードの取引希望条件の部分集合に追加していくことを各ノードから基点方向に辿ることで、展開したノードの個数分の組合せ候補をもれなく列挙できる。これらの展開の際には、探索中に既に列挙された組合せとの重複チェックを行うことで探索枝刈りを行う。
なお、この探索は、詳細な制約チェックと前述したような顧客と業者の満足度に基づく評価値の演算に先立って独立して実施されても良いが、取引希望条件やリンク情報の数が多い場合、組合せ爆発が生じる。効率化のため探索中に各ノードの組合せについて評価値演算を行ない、評価値の高いノードを優先的に展開していく探索方法が有り得る。この場合は最良優先探索アルゴリズムやＡ＊探索アルゴリズムなどを利用して、全てを列挙することなく、より取引の成立の高い組合せ候補を発見できる。
組合せ候補が列挙された後に、各組合せ候補について、それを構成する各取引希望条件のうち、最低限必要な条件の項目を全て満足しているか否か、顧客間あるいは業者間の競合がないか否か、等の各組合せ候補に依存する条件により詳細な制約チェックを行い（ステップＳ４０３）、組合せ候補データベース１７に登録する（ステップＳ４０４）。
次に、図８を参照して、組合せ候補を閲覧したユーザ（説明を容易にするため、これをユーザＡとする）から、組合せ候補（説明を容易にするため、これを組合せ候補Ｘとする）の承認を得られた場合の処理動作について説明する。
ユーザＡが、端末２、３のＧＵＩ２１、３１を用いて、取引仲介装置１に接続し、組合せ候補ＸのＩＤとともに承認通知を送信すると、それを、組合せ候補閲覧・選択部１３にて受信する（ステップＳ３０１）。組合せ候補閲覧・選択部１３は、この承認通知を受けて、組合せ候補データベース１７から組合せ候補Ｘを抽出する（ステップＳ３０２）。組合せ候補Ｘを構成する全ての取引希望条件について、その各取引希望条件を登録したユーザＡ以外のユーザ（説明を簡単にするために、これをユーザＢ、Ｃとする）のいずれかの承認が得られていない場合は、ユーザＡが組合せ候補Ｘを承認した旨をデータベース１７に記録する（ステップＳ３０３、ステップＳ３１１）。
組合せ候補Ｘについて、ユーザＡ以外の全てのユーザＢ、Ｃの承認が得られている場合は（ステップＳ３０３）、組合せ候補契約成立通知部１９は、ユーザＡ、Ｂ、Ｃ全員に、全関係者の承認が得られた旨通知し（ステップＳ３０４）、以後はこれらのユーザ間で詳細契約を交してもらう。
組合せ候補Ｘが関係者全員に承認された時点で、この組合せ候補Ｘを構成する取引希望条件は、他の組合せ候補で重複して使用することが不可能になるため、ステップＳ３０５以降のステップではこれに伴う処理を実施する。
まず、組合せ候補消去部１４は、組合せ候補Ｘを構成する全ての取引希望条件を列挙し（ステップＳ３０５）、その列挙された取引希望条件を属性・取引希望条件データベース１５より削除する（ステップＳ３０６）。また、列挙された取引希望条件のいずれかを１つでも含む組合せ候補を組合せ候補データベース１７より全て削除する（ステップＳ３０７、ステップＳ３１０）。さらに、組合せ候補消去・変更通知部１８は、前述した閲覧履歴情報を参照して、削除された組合せ候補を閲覧中のユーザにその旨通知し（ステップＳ３０８）、これら削除された組合せ候補を既に承認していたユーザに対しても、承認が無効になった旨通知する（ステップＳ３０９）。なお、ステップＳ３０４以降の処理は必ずしもこの順序で実行する必要はない。また、ステップＳ３０８、ステップＳ３０９は省略することもあり得る。
なお、業者または顧客に、閲覧した取引希望条件組合せ候補の中から、組合せ候補を承認させる処理において、一部のの業者または顧客が組合せ候補を閲覧し承認操作をすることなくデフォルトで承認扱いにすることも可能である。
この場合、業者あるいは顧客は、いちいち組合せ候補の閲覧を行わずに、取引希望条件さえ満足されればデフォルトで承認扱いするように、取引仲介装置１に事前通知すればよい。
また、ユーザ（業者および顧客）が閲覧した取引希望条件組合せ候補の中から、組合せ候補を承認する際、承認する条件を予め指定しておき、この条件を満たす複数個の組合せ候補が自動的に承認されるようにしてもよい。
さらに、例えば、顧客側で取引可能な業者のリストを作成し、このリストを取引仲介装置１に予め通知する。このリスト内に含まれる業者のみで組合せが構成される場合は、デフォルトで承認扱いにするようにしてもよい。
当事者が三者以上の取引の仲介を行う場合、特定の業者や顧客が特に不利益を被ることのない組合せ候補を仲介業者が提案しないと、関連する業者や顧客の全員の承諾を得るのが難しく、不特定多数のユーザをアイ邸にする電子商取引においては、取引が容易に成立しない。このような組合せ候補の作成は、従来は仲介業者が人手にて行なっていた作業であるが、本発明はこれを含めた一連の仲介業務を自動化するものであり、あらゆる業種の自由参加形式の業務取引仲介の自動化に活用可能である。
例えば、旅行代理店がパッケージツアーを企画する場合には、旅行代理店では、交通機関、ホテル、レストラン等の複数の業者を、時間、場所等の条件に応じて組み合わせて、顧客の要望に合うようなパッケージツアーを作成できる。従来の単なるチケットの逆オークションと異なり、このようにして作成されたパッケージツアーは業者側からみても必ず採算のとれるものになっている。
また、老人介護のためのヘルパーの派遣サービス業務においては、異なるエリアに住む複数の顧客からのそれぞれ異なる要求時間帯に、手の空いたヘルパーを迅速に派遣するためには、複数の顧客の要望と複数のヘルパーの空き状況とを組み合わせて効率のよいスケジュールをタイムリーに作成して顧客に提供することができる。このようにして提案されたスケジュールは、業者側にも都合のよいものとなっている。例えば、１人のヘルパーが同じ地域に住む介護対象者を効率よく回れるスケジュールとなっている。
次に、共同輸送の複数の物流業者及び顧客間の自由参加形式の取引を例として、具体的に説明する。
共同輸送の自由参加形式の電子取引で従来提案されている方式は、物流業者が輸送条件と希望価格を提示し、複数顧客が競り落すオークション形式か、顧客が先に条件提示する逆オークション形式のいずれかである。この場合、１つの業者と１つの顧客の仲介ではあるが、双方の希望輸送条件が完全に一致する場合は少なく、業者が顧客のどちらか一方が譲歩する場合が多い。
本発明によれば、複数輸送業者と複数顧客にまたがる複雑な取引の仲介を自動化できるため、幾つかの希望条件を組合せることで、業者と顧客の双方の希望輸送条件を同時に満足させ、双方にメリットの大きい取引仲介サービスを高速かつ安いコストで提供できる。
図１８から図１９に示すフローチャートを参照して、取引仲介装置１の処理動作について説明する。
各輸送業者が、空きのあるトラックの輸送条件（輸送区間、積載量、希望最低価格等）を業者端末３から入力し、データベース１５に登録される（ステップＳ１、ステップＳ３）。
各顧客が、輸送してもらいたい荷物の輸送希望条件（輸送区間、量、希望上限価格等）を顧客端末２から入力し、データベース１５に登録される（ステップＳ２、ステップＳ３）。
図９は、データベース１５に登録された、業者側の属性と希望取引条件とを模式的に示したもので、複数（ここでは、例えば４者）の輸送業者が、それぞれ希望取引条件として、輸送区間、積載量、各区間の単位積載量当たりの希望最低価格を登録している場合を示している。例えば輸送業者「シロネコ」は輸送区間が「東京−静岡−名古屋」であって、東京−静岡間に輸送可能な積載量は「２」、その間の単位積載量「１」当たりの輸送費は５千円であることがわかる。なお、積載量としては、説明の簡単のため、単位積載量を基準とした数値のみで表すものとする。すなわち、この例では、積載量「２」で、東京から静岡まで輸送する場合、輸送費は１万円かかるということである。
図１０は、データベース１５に登録された、顧客側の属性と希望取引条件とを模式的に示したもので、複数（ここでは、例えば３者）の顧客が、それぞれ希望取引条件として、輸送区間、積載量を登録している場合を示している。例えば顧客「初芝」は輸送区間が「東京−大阪」であって、その間の積載量は「２」である。
スケジューリング部１６が、例えば、データベース１５の登録内容の更新を検知して（ステップＳ４）、上記希望取引条件間のマッチングを行い、取引候補である、複数の組合せ候補を生成する（ステップＳ５）。その際、前述したような探索木を用いて組合せ候補を生成し、その後、生成された各組合せ候補に対し、制約チェックや評価値に基づくより実現性のある組合せ候補の抽出を行うが、ここでは、その説明は省略する。
ステップＳ５において、ある取引条件を基点として組合せ探索を行った際に、顧客と業者の双方の希望取引条件を満足するような組合せ候補が１つも生成できない場合がある。その場合には（ステップＳ６）、例えば空白区間について、オークション形式で輸送業者からエントリー募集を行ったり、もしくは逆オークション形式で顧客からエントリー募集を行う（ステップＳ７）。
ステップＳ５で生成された組合せ候補は、組合せ候補データベース１７に格納される。また、閲覧要求があった場合に、各組合せ候補をその候補を構成する各顧客および各業者に通知する。例えば、業者「シロネコ」の業者端末３には、図１１に示すような組合せ候補のリストが送信され、ＧＵＩ３２に表示される（図１９のステップＳ８）。また、顧客「初芝」の顧客端末２には、図１２に示すような組合せ候補のリストが送信され、ＧＵＩ２１に表示される（図１９のステップＳ９）。
まず、図１１、図１２を参照して、スケジューリング部１６で生成された組合せ候補について説明する。
例えば顧客「初芝」は、図１０から明らかなように、東京から大阪まで積載量「２」の輸送を希望している。その間の輸送費として希望上限価格は「４万円」であるとする。
業者「シロネコ」は、図９から明らかなように、東京−静岡間に積載量「２」の空きと、静岡−名古屋間に積載量「２」の空きがある。また、業者「サカワ便」は、図９から明らかなように、名古屋−大阪間に積載量「２」の空きがあるので、この２つの業者を組み合わせれば、顧客「初芝」の希望取引条件を満たす輸送が実現できる。この場合、輸送費は「３万円」であるとする。その他、同様にて、図１２に示すような、顧客「初芝」の希望取引条件を満足するような業者の組合せが可能である。顧客側からすれば、希望の積載量でできるだけ安価で輸送できることが望ましい。そこで、組合せ候補閲覧・選択部１３は、これら組合せのうち、輸送費が４万円以内のものを輸送コストの安いもの順に並び替えて、図１２に示したようなリストを生成し、それを顧客端末２に提供する。あるいは、輸送時間の短い順に組合せ候補を並び替えてもよく、要は、顧客が選択した最も重要視した項目を基準に組合せ候補を並び替えればよい。
一方、業者「シロネコ」は東京から名古屋まで「初芝」の荷物を輸送すれば、積載量が１００％となる。また、東京−静岡間で「初芝」と「松下」の荷物を「１」づつ輸送し、静岡から名古屋までは「初芝」と「ソミー」の荷物を「１」づつ輸送すれば同じく、積載量が１００％となる。業者側からすれば、空きのルートを積載量１００％で全て埋められることが望ましい。そこで、組合せ候補閲覧・選択部１３は、これら組合せのうち、積載量が高いものが上になるように並び替えて、図１１に示したようなリストを生成し、それを業者端末３に提供する。あるいは、売上が高い者から順に並び替えてもよく、要は、業者が選択した最も重要視したい項目を基準に組合せ候補を並び替えればよい。
また、この場合、業者「ヘリカン」の業者端末３には、図１３に示すような組合せリストが表示される。
さて、顧客「初芝」、業者「シロネコ」の双方の端末のＧＵＩ２１、３１に表示された図１２、図１１に示したようなリスト上の「ＯＫ」ボタン１０１、２０１が選択されて、図１２、図１１のぞれぞれのリストの最初に提示された組合せ候補に対し、当該取引に承認する旨が組合せ候補閲覧・選択部１３に送られてきたとする（ステップＳ１０）。さらに、「サカワ便」の業者端末から同じ組合せ候補に対し承認する旨が組合せ候補閲覧・選択部１３に送られてきたとする。すると、「シロネコ」「サカワ便」「初芝」の２業者１顧客の３当事者間の業務取引が成立したことになる（ステップＳ１１）。なお、顧客、業者の双方からの承認が早く得られたものら順に、早い者勝ちで取引の成立とする。
組合せ候補に対し承認する際には、上記以外の手法も可能である。例えば、顧客あるいは業者端末にいちいち組合せ候補を提示するまでもなく、顧客あるいは業者から承認可能な最低条件が予め提示されているときは、自動的にその最低条件を満たす組合せ候補に対し承認が得られたものとみなすようにしてもよい。例えば、顧客「初芝」の場合、輸送費が４万円以下で、東京から大阪まで積載量「２」の輸送が可能である取引候補であるならば、そのような取引候補を全て承認すると、予め取引仲介装置１へ通知しているときは、図１２に示した取引候補は全て顧客「初芝」から承認されたことになる。
また、例えば、図１２に示した取引候補のうち、顧客「初芝」が、上から２番目に提示された、輸送費が３万５千円の取引候補を承認した際には、その上に提示された全ての取引候補、すなわち、顧客「初芝」の取引希望条件をより満足する取引候補をも承認したものとみなすようにしてもよい。
組合せ候補契約成立通知部１９は、取引の成立した組合せ候補を構成する業者、顧客へ、その取引が成立した旨を通知する（ステップＳ１２）。
また、組合せ候補消去部１４は、取引の成立した組合せ候補をデータベース１７から消去するとともに、業者登録部１１，顧客登録部１２はデータベース１５に登録された取引成立により無効となった業者、顧客の属性、希望取引条件を消去する（ステップＳ１３）。その結果、データベース１５の登録内容が更新され（図１４、図１５参照）、図１８のステップＳ５へ進み、スケジューリング部１６は、図１４、図１５に示したような更新された登録内容に基づき、再び、業者、顧客の希望取引条件のマッチングを行い、組合せ候補を作成する。
一方、組合せ候補消去・変更通知部１８は、上記業者「シロネコ」と顧客「初芝」との間の取引成立に応じて、これら業者、顧客を含む組合せ候補をリストとして提供した業者、顧客の端末へ、この取引の成立した組合せ候補が消去されたこと、また、それに伴い、消去された組合せ候補を既に承認していた顧・業者にその承認が無効となった旨と、組合せ候補の変更があったことを通知する。この通知を受けて、変更された組合せ候補のリストの要求が合った場合は、組合せ候補閲覧・選択部１３は、当該要求元に、新たなリストを提供する。
例えば、顧客「初芝」と業者「シロネコ」との間の取引成立に伴い、図１３の業者「ヘリカン」を含む組合せ候補の中から、顧客「初芝」の取引希望条件を含む組合せ候補が削除されるので、業者「ヘリカン」の端末３には、図１７に示すような新たに生成された組合せ候補のリストが表示される。すなわち、積載率５０％であるが、静岡−大阪間を顧客「ソミー」の荷物を輸送するという、顧客「ソミー」と業者「ヘリカン」との組合せ候補がリスト上に表示される。一方、顧客「ソミー」の端末にも、図１６に示すように、同じ組合せ候補がリストとして表示される。
なお、上記各ステップの処理は順次実施されるとは限らず、通常は複数のプロセスとして並行して実施される。
また、ここで挙げた例では、輸送業者のみ取引に参加しているが、業者として倉庫業者などが倉庫の場所、提供期間などを取引希望条件として提示して参加することも有り得る。
本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピーディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
また、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記実施形態には種々の段階の発明は含まれており、開示される複数の構成用件における適宜な組み合わせにより、種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも１つ）が解決でき、発明の効果の欄で述べられている効果（のなくとも１つ）が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
産業上の利用可能性
以上説明したようにこの発明は、インターネットを媒体として複数当事者間の取引を仲介する電子取引仲介サービスを提供するための通信技術の分野、このサービスを提供するための装置およびプログラムを製造、使用する分野に有効である。
【図面の簡単な説明】
図１はこの発明に係わる電子取引仲介システムの全体の構成例を示す図。
図２は図１の取引仲介装置の処理動作を説明するためのフローチャートを示す図。
図３は業者側から提出された取引希望条件の記憶例を示す図。
図４は顧客側から提示された取引希望条件の記憶例を示す図。
図５は図１の取引仲介装置の処理動作を説明するためのフローチャートを示す図。
図６は図１の取引仲介装置の処理動作を説明するためのフローチャートを示す図。
図７は組合せ候補探索木の一例を示す図。
図８は図１の取引仲介装置の処理動作を説明するためのフローチャートを示す図。
図９は業者側の取引希望条件の登録データを示す図。
図１０は顧客側の取引希望条件の登録データを示す図。
図１１は業者端末のＧＵＩ画面に表示される組合せ候補の表示例を示す図。
図１２は顧客端末のＧＵＩ画面に表示される組合せ候補の表示例を示す図。
図１３は業者端末のＧＵＩ画面に表示される組合せ候補の表示例を示す図。
図１４は取引が成立した組合せ候補のデータを削除した後のデータベースに格納されている業者側の取引希望条件の登録データを示す図。
図１５は取引が成立した組合せ候補のデータを削除した後のデータベースに格納されている顧客側の取引希望条件の登録データを示す図。
図１６は顧客端末のＧＵＩ画面に表示される組合せ候補の表示例を示す図。
図１７は業者端末のＧＵＩ画面に表示される組合せ候補の表示例を示す図。
図１８は図１の取引仲介装置が、共同輸送の複数の物流業者及び顧客間の自由参加形式の取引を仲介する場合の処理動作を説明するためのフローチャートを示す図。
図１９は図１の取引仲介装置が、共同輸送の複数の物流業者及び顧客間の自由参加形式の取引を仲介する場合の処理動作を説明するためのフローチャートを示す図。

Claims (12)

1. 複数の項目からなる複数の取引希望条件をネットワークを介して複数のユーザの端末から収集するステップと、
   前記複数のユーザからの複数の取引希望条件を組み合わせて、各ユーザの取引希望条件のうちの複数の項目を満足する複数の取引候補を生成するステップと、
   前記生成された取引候補をその取引候補に含まれる取引希望条件を提出した取引の当事者としての各ユーザの端末に提示するステップと、
   前記複数の取引候補のうちの特定の取引候補に対して、その取引候補に係る取引の当事者としてのユーザ全員の端末から承認を得られて取引が成立したとき、前記成立した取引の当事者としてのユーザ全員の端末に取引が成立した旨を通知するステップと、
   を有することを特徴とする電子取引仲介方法。
2. 前記特定の取引候補に係る取引が成立したとき、前記特定の取引候補に含まれる取引希望条件を少なくとも１つ含む他の取引候補を削除して、取引可能な取引候補のみをユーザの端末に提示することを特徴とする請求項１記載の電子取引仲介方法。
3. 前記取引候補をその取引の当事者としてのユーザの端末に提示する際、そのユーザの端末から提出された取引希望条件を最も満足する取引候補を最も優先して提示することを特徴とする請求項１記載の電子取引仲介方法。
4. 前記取引候補をその取引の当事者としてのユーザの端末に提示する際、そのユーザの端末から提出された取引希望条件の満足度の高い取引候補から順に提示し、この提示された複数の取引候補のうち、前記ユーザの端末により承認可能な最低レベルの満足度の取引候補が選択されたとき、その最低レベル以上の満足度の取引候補が前記ユーザにより承認されたものとみなすことを特徴とする請求項１記載の電子取引仲介方法。
5. 前記複数のユーザのうちの特定のユーザが当事者となる取引候補が、前記特定のユーザにより予め提示された承認可能な最低条件を満たすときは、前記特定のユーザから既に承認を得たものとみなすことを特徴とする請求項１記載の電子取引仲介方法。
6. ネットワークを介して複数のユーザ間の取引を仲介する電子取引仲介装置において、
   前記ネットワークを介して前記複数のユーザの端末から複数の項目からなる複数の取引希望条件を収集するように構成された収集部と、
   前記複数の取引希望条件を組み合わせて、各ユーザの取引希望条件のうち複数の項目を満足する複数の取引候補を生成するように構成された生成部と、
   この生成部で生成された取引候補を、その取引候補に含まれる取引希望条件を提出した取引の当事者としての各ユーザの端末に提示するように構成された提示部と、
   この提示部で提示された複数の取引候補のうちの特定の取引候補に対して、その取引候補に係る取引の当事者としてのユーザ全員の端末から承認を得られて取引が成立したとき、前記成立した取引の当事者としてのユーザ全員の端末に取引が成立した旨を通知するように構成された通知部と、
   を具備したことを特徴とする電子取引仲介装置。
7. 前記特定の取引候補に係る取引が成立したとき、前記特定の取引候補に含まれる取引希望条件を少なくとも１つ含む他の取引候補を削除して、取引可能な取引候補のみをユーザの端末に提示することを特徴とする請求項６記載の電子取引仲介装置。
8. 前記取引候補をその取引の当事者としてのユーザの端末に提示する際、そのユーザの端末から提出された取引希望条件を最も満足する取引候補を最も優先して提示することを特徴とする請求項６記載の電子取引仲介装置。
9. 前記取引候補をその取引の当事者としてのユーザの端末に提示する際、そのユーザの端末から提出された取引希望条件の満足度の高い取引候補から順に提示し、この提示された複数の取引候補のうち、前記ユーザにより承認可能な最低レベルの満足度の取引候補が選択されたとき、その最低レベル以上の満足度の取引候補が前記ユーザにより承認されたものとみなすことを特徴とする請求項６記載の電子取引仲介装置。
10. 前記複数のユーザのうちの特定のユーザが当事者となる取引候補が、前記特定のユーザにより予め提示された承認のための最低条件を満たすときは、前記特定のユーザから既に承認を得たものとみなすことを特徴とする請求項６記載の電子取引仲介装置。
11. ネットワークを介して複数のユーザ間の取引を仲介するための機能をコンピュータに実現させるためのプログラム製品であって、
    前記ネットワークを介して前記複数のユーザの端末から複数の項目からなる複数の取引希望条件を収集するための機能と、
    前記複数の取引希望条件を組み合わせて、各ユーザの取引希望条件のうち複数の項目を満足する複数の取引候補を生成するための機能と、
    前記生成された取引候補を、その取引候補に含まれる取引希望条件を提出した取引の当事者としての各ユーザの端末に提示させるための機能と、
    前記提示された複数の取引候補のうちの特定の取引候補に対して、その取引候補に係る取引の当事者としてのユーザ全員の端末から承認を得られて取引が成立したとき、前記成立した取引の当事者としてのユーザ全員の端末に取引が成立した旨を通知するための機能と、
    をコンピュータに実現させるためのプログラム製品。
12. 複数の項目からなる複数の取引希望条件をネットワークを介して複数のユーザの端末から収集するための処理と、
    前記複数のユーザからの複数の取引希望条件を組み合わせて、各ユーザの取引希望条件のうちの複数の項目を満足する複数の取引候補を生成するための処理と、
    前記生成された取引候補をその取引候補に含まれる取引希望条件を提出した取引の当事者としての各ユーザの端末に提示させるための処理と、
    前記複数の取引候補のうちの特定の取引候補に対して、その取引候補に係る取引の当事者としてのユーザ全員の端末から承認を得られて取引が成立したとき、前記成立した取引の当事者としてのユーザ全員の端末に取引が成立した旨を通知するための処理と、
    をコンピュータに実行させるプログラムを記録した機械読み取り可能な記録媒体。

Images