JPH11232352A - 商品取引装置、商品取引システム、及び記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 計画的な商品の生産及び販売、計画的な商品
の調達を可能とすることで、効率的な商品の売買取引を
可能とする商品取引システムを提供する。 【解決手段】 複数の購入情報（買手側が発する情報）
と、複数の販売情報（売手側が発する情報）を突き合わ
せて、双方の条件の折り合うものから順次成約決定する
取引の処理とを実行可能とする。このとき、第２の取引
条件（商品を厳密に特定した条件）に従った取引処理で
不成約であった販売情報を、自動的に第１の取引条件
（第２の取引条件より広範囲の条件）に従った取引処理
に移行し、再度その取引処理で処理する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、例えば、花卉や青
果物等のライフサイクルの短い生鮮商品や、有効期限の
あるチケット等のサービス商品、使用日が限れた航空チ
ケットのように、ある期間が過ぎてしまうと商品価値が
なくなる或いは減少する各種商品の売買取引に用いられ
る商品取引装置、商品取引システム、及び該取引を行う
ための処理ステップをコンピュータが読出可能に格納し
た記憶媒体に関するものである。

【０００２】

【従来の技術】例えば、生花の売り買いの取引は、卸売
市場で行われる。すなわち、買手業者は現場に出向き、
売手業者が実際に販売している現物を観察し、どのよう
な生花がいくらで販売されているか等を把握する。そし
て、希望する生花が販売されていた場合には、その売手
と価格等を含めた取引を行う。このようにして、買手業
者は、希望する生花を調達する。

【０００３】

【発明が解決しようとする課題】しかしながら、従来で
は、上述したような生花等の商品の売買取引をシステム
化したものはなかった。このため、次のような問題があ
った。

【０００４】（１）商品の売買取引の流通が複雑化す
る。また、買手業者は、希望する商品を得るためには現
場（卸売市場や卸売会社等）に実際に出向いて行く必要
があり、このとき、希望する商品が販売されていればよ
いが、販売されていない場合は無駄になってしまう。特
に、生花等のような商品は、気象や災害等の自然条件の
影響を受けやすいものであるため、予定のものが予定通
りに販売されない場合が多々ある。したがって、買手業
者にとっては、場当たり的な仕入れとなる場合が多く、
調達計画を立てることができない。

【０００５】（２）売手業者は卸売市場で商品の販売を
行うが、その商品に買手がつくか、どのくらいの量を裁
ききれるか等を事前に知ることができず、販売計画を立
てることができない。また、裁ききれなかった商品（残
商品）については、その他の販売手段に頼ることになる
が、上述したような生花等の商品は、ある期間が過ぎて
しまうと品質が低下してしまうため、荷受、競り準備、
競り後の分荷によりダメージを受ける程、その分価格を
下げる必要が出てくる。

【０００６】（３）買手業者は、複数種類の商品を大量
に希望する場合が多いが、実際に卸売市場に出向いてい
かなければ、希望する商品が販売されているのか、ま
た、それが大量に販売されているのか等を事前に知るこ
とができない。このため、計画購入することができな
い。また、大量に商品を購入しようとすると、その卸売
市場の需要が逼迫し、自分で価格をつり上げることにな
る。

【０００７】（４）売手業者は販売計画を立てることが
できないため、生産者側も生産計画を立てることができ
ない。

【０００８】そこで、本発明は、上記の欠点を除去する
ために成されたもので、計画的な商品の生産及び販売、
計画的な商品の調達を可能とすることで、効率的な商品
の売買取引を可能とする商品取引装置、商品取引システ
ム、及び該取引を行うための処理ステップをコンピュー
タが読出可能に格納した記憶媒体を提供することを目的
とする。

【０００９】

【課題を解決するための手段】斯かる目的下において、
第１の発明は、複数の端末装置から出力される商品の売
買取引のための販売情報と購入情報情報に基づいて、商
品の売買の成約を決定するシステムにおける上記複数の
端末装置の少なくとも１つの端末装置であって、複数の
上記購入情報と複数の上記販売情報を突き合わせて、双
方の条件の折り合うものから順次成約決定する取引の処
理を行う取引処理手段を備え、上記取引処理手段は、上
記販売情報に含まれる商品に関する情報の任意の情報を
第１の取引条件として特定する第１の特定手段と、上記
販売情報に含まれる商品に関する情報の任意の情報を第
２の取引条件として特定する第２の特定手段と、上記第
２の取引条件に従った取引処理により発生した未成約商
品の販売情報を上記第１の取引条件に従った取引処理に
移行する処理移行手段とを含むことを特徴とする。

【００１０】第２の発明は、上記第１の発明において、
上記第１の取引条件は、上記第２の取引条件より広範囲
の条件であることを特徴とする。

【００１１】第３の発明は、上記第１の発明において、
上記販売情報は、下限価格情報を含むことを特徴とす
る。

【００１２】第４の発明は、上記第１の発明において、
各取引処理を実行するためのアイコン機能を有する表示
手段を備えることを特徴とする。

【００１３】第５の発明は、上記第１の発明において、
上記商品は、商品毎に想定される期間経過後には価値が
なくなる或いは減少するものであることを特徴とする。

【００１４】第６の発明は、複数の端末装置から出力さ
れる商品の売買取引のための販売情報と購入情報から商
品の売買の成約を決定する商品取引システムであって、
上記複数の端末装置の少なくとも１つの端末装置は、請
求項１〜５の何れかに記載の商品取引装置であることを
特徴とする。

【００１５】第７の発明は、複数の端末装置とホストが
相互通信することで、上記複数の端末装置から出力され
る商品の売買取引のための販売情報と購入情報から商品
の売買の成約を決定する商品取引システムであって、上
記端末装置は、送られてきた情報をブラウザ機能により
画面表示し、その画面上の情報に基づいて行われたユー
ザからの操作に従って情報を出力し、上記ホストは、複
数の上記購入情報と複数の上記販売情報を突き合わせ
て、双方の条件の折り合うものから順次成約決定する取
引の処理を行う取引処理機能を有し、上記取引処理機能
は、上記販売情報に含まれる商品に関する情報の任意の
情報を第１の取引条件として特定する第１の特定機能
と、上記販売情報に含まれる商品に関する情報の任意の
情報を第２の取引条件として特定する第２の特定機能
と、上記第２の取引条件に従った取引処理により発生し
た未成約商品の販売情報を上記第１の取引条件に従った
取引処理に移行する処理移行機能とを含むことを特徴と
する。

【００１６】第８の発明は、複数の端末装置から出力さ
れる商品の売買取引のための販売情報と購入情報情報に
基づいて、商品の売買の成約を決定するための処理ステ
ップを実行するプログラムを格納した記憶媒体であっ
て、上記処理ステップは、複数の上記購入情報と複数の
上記販売情報を突き合わせて、双方の条件の折り合うも
のから順次成約決定する取引の処理を行う取引処理ステ
ップを含み、上記取引処理ステップは、上記販売情報に
含まれる商品に関する情報の任意の情報を第１の取引条
件として特定する第１の特定ステップと、上記販売情報
に含まれる商品に関する情報の任意の情報を第２の取引
条件として特定する第２の特定ステップと、上記第２の
取引条件に従った取引処理により発生した未成約商品の
販売情報を上記第１の取引条件に従った取引処理に移行
する処理移行ステップとを含むことを特徴とする。

【００１７】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を用いて説明する。

【００１８】（第１の実施の形態）本発明に係る商品取
引システムは、例えば、図１に示すような生花取引シス
テム１００に適用される。

【００１９】生花取引システム１００では、上記図１に
示すように、生花の市場管理を行うサーバ側の端末装置
１０１と、複数の売手業者側の端末装置１１１〜１１４
及び１４１、複数の買手業者側の端末装置１２１〜１２
３及び１５１、及び中卸業者側の端末装置１３１とが、
ＷＡＮ１６１を介して互いに通信可能に接続された構成
としている。

【００２０】ここで、複数の売手業者の中には、大手業
者（大手売手）や小口の業者（小口売手）も含まれてお
り、また、複数の買手業者の中にも大手業者（大手買
手）や小口の業者（小口買手）も含まれているものとす
る。そして、サーバ側、売手業者側、買手業者側、及び
中卸業者側の各端末装置は、例えば、中央処理装置（Ｃ
ＰＵ）、キーボード、マウス、表示器、通信器、及び本
システムの処理プログラムが予め格納されたメモリ等を
備えたパーソナルコンピュータ（パソコン）からなり、
該メモリの処理プログラムをＣＰＵにより読み出して実
行することで、後述する種々の処理を行うようになされ
ている。

【００２１】尚、サーバ側、売手業者側、買手業者側、
及び中卸業者側の各端末装置は、本発明に係る商品取引
装置を適用したものである。また、ここでは、ＷＡＮ１
６１を介してのサーバ側と各業者側の接続構成とした
が、これに限らず、ホストコンピュータと端末装置の接
続構成でもよいし、サーバ側とクライアント側の接続構
成でもよい。さらに、複数の売手業者側の端末装置１１
１〜１１４、及び複数の買手業者側の端末装置１２１〜
１２３は個々に、ＷＡＮ１６１を介してサーバ側と接続
された構成としてもよい。また、上記図１中の１７１〜
１７３は、生産者であり、大手売手業者１１１とは通信
で接続されておらず、電話やファックス等で連絡するよ
うになされている。

【００２２】上述のような生花取引システム１００は、
買手側から発生する商品の情報に基づいた各業者間の取
引（注文情報に基づいた取引）、売手側から発生する商
品の情報に基づいた各業者間の取引（販売情報に基づい
た取引）、及び複数の買手側から発生する注文情報と複
数の売手側から発生する販売情報に基づいた複数の各業
者間の取引（複数の注文情報と複数の販売情報に基づい
た取引）を含む生花の売買取引を、生花取引システム１
００に加入している各業者（参加者）側の端末装置上で
行うようになされている。

【００２３】尚、ここでの”商品の情報”は、例えば、
数量、単価、情報入力時刻、及び属性データを含み、
該”属性データ”は、期日、期限、品種、及び色等を含
む。また、ここでの”生産者”には、実際の生産者から
販売の委託を受けている販売代理人、販売卸業者、販売
エージェント、或いは輸入業者等も含まれる。

【００２４】そこで、まず、サーバ側の端末装置の内部
構成、及び各業者側の端末装置の内部構成について、図
２を用いて説明する。

【００２５】上記図２に示すように、サーバ側の端末装
置３００は、種々の情報の受信及び送信（配信）を行う
ための情報受信配信機能３１０と、アプリケーション機
能（ＡＰＰ機能）としての取引処理及び価格形成機能３
２１、価格予想機能３２２、システム運用管理機能３２
３、個人別マーケット分析機能３２４、及び個人別デー
タ配信管理機能３２５と、トランザクションデータやマ
スターデータを記憶すると共に各種処理に必要なデータ
を記憶するための記憶機能（データベースメモリ：ＤＢ
Ｍ）３３０とを有している。

【００２６】取引処理及び価格形成機能３２１とは、注
文情報に基づいた取引、販売情報に基づいた取引、及び
複数の注文情報と複数の販売情報に基づいた取引等、各
種の取引処理を行うための機能である。

【００２７】価格予想機能３２２とは、各業者間での取
引において、取引対象となる生花の価格の変動を予測す
るための機能である。

【００２８】システム運用管理機能３２３とは、サーバ
側の端末装置を運用して生花取引システム１００を制御
管理するための機能である。

【００２９】個人別マーケット分析機能３２４とは、参
加者の登録を行うと共に、その参加者が実際に取引した
日時、その取引後の取引状況、及び取引された生花につ
いての情報（生花の種類や取引価格等）等、各参加者が
行った取引に関する情報をＤＢＭに記憶させ、その記憶
情報を基に、例えば、取引される生花の季節別の傾向
値、値段の高低、各参加者の今後の取引傾向（売買動
向）等を分析するための機能である。

【００３０】個人別データ配信管理機能３２５とは、各
参加者に対するデータ配信管理についてフィルタリング
をかける機能であり、例えば、売手側や買手側の各参加
者の業態（中卸や量販店等）、或いは商品の引き渡しの
条件、或いは各参加者に提供されるサービスの内容等に
よって、配信データの全体或いは一部の表示を行ったり
行わなかったりする機能、或いは上述の理由により各参
加者側毎で端末装置上に表示される全体或いは一部の内
容を変更させたりする機能である。

【００３１】一方、各業者側の端末装置４００は、種々
の情報の受信及び配信を行う情報受信配信機能４１０
と、ＷＷＷブラウザ等によるユーザインターフェース
（Ｉ／Ｆ）機能４２０と、アプリケーション機能として
の自己勘定管理機能４３１及び連携機能４３２と、トラ
ンザクションデータやマスターデータを記憶すると共に
各種処理に必要なデータを記憶するための記憶機能４４
０とを有している。

【００３２】自己勘定管理機能４３１とは、先の取引に
より発生する支払いの管理等、参加者側で処理する自己
勘定を管理するための機能である。

【００３３】連携機能４３２とは、直属する小売店側の
システムや社内販売システムと連携して、先の取引につ
いての情報を通知する等、参加者側に所属する側と連携
可能とするための機能である。

【００３４】尚、ここでは、業者側の端末装置４００に
自己勘定管理機能４３１、連携機能４３２、及び記憶機
能４４０を設けるようにしたが、これらの機能について
は、必ずしも業者側の端末装置４００に設ける必要はな
く、業者側の端末装置４００に設ける代わりに、サーバ
側の端末装置３００に設けるようにしてもよい。

【００３５】つぎに、生花取引システム１００による各
種処理の流れ、特に、（Ａ）注文情報に基づいた取引処
理、（Ｂ）販売情報に基づいた取引処理、及び（Ｃ）複
数の注文情報と複数の販売情報に基づいた取引処理の流
れについて説明する。尚、（Ａ）、（Ｂ）、及び（Ｃ）
の各取引処理についての以下の説明では、例えば、買手
業者と売手業者間の取引とする。

【００３６】ここで、各業者の端末装置には、例えば、
インターフェース機能としてのＷＷＷブラウザにより、
サーバ側を介して送られてくる各種データが画面表示さ
れるものとする。そして、端末装置の使用者が、画面上
で操作することで、処理が進められるものとする。そこ
で、ある業者が生花取引システム１００を利用して、
（Ａ）、（Ｂ）、及び（Ｃ）の各取引処理等を行う場
合、先ず、自端末装置でサーバ側にアクセスすること
で、装置には、例えば、図３又は図４に示すようなトッ
プ画面が表示される。上記図３は、買手となる場合に表
示されるトップ画面であり、「注文」、「予約」、「一
般Ｉ」、「一般ＩＩ」、「成約・着荷」、「集統計」、
「お知らせ」、「終了」等、各種項目が表示される。一
方、上記図４は、売手となる場合に表示されるトップ画
面であり、「注文」、「予約」、「複写」、「一般」、
「成約・着荷」、「集統計」、「お知らせ」、「終了」
等、各種項目が表示される。尚、これらの表示は、アイ
コン機能と同様に、その文字部をクリックすると、その
文字部に対応した処理が実行されるようになされてい
る。ここでは文字表示としているが、これに限らず、絵
柄等で表示するようにしてもよい。そして、端末装置の
使用者は、マウス等を用いて各項目を選択的に指定（ク
リック）する。これにより、このとき指定された項目に
対応した処理が実行される。例えば、（Ａ）の取引を行
う場合には「注文」の項目、（Ｂ）の取引を行う場合に
は「予約」の項目、（Ｃ）の取引を行う場合には「一般
Ｉ」又は「一般ＩＩ」、或いは「一般」の項目を選択し
て指定する。

【００３７】（Ａ）注文情報に基づいた取引処理 （第１の取引：注文情報に基づく予約相対取引）本取引
処理は、例えば、図５に示すような流れに従って実行さ
れる。

【００３８】買手業者は、自端末装置のトップ画面（上
記図３）上で「注文」の項目を選択し指定する。これに
より、装置は、注文情報入力可能状態となる。そして、
買手業者は、調達（仕入）計画に従って、希望する購入
日、生花の品目、品種、色、等階級、産地、総本数、及
び価格等の購入希望情報である注文情報をキーボード入
力する。この情報は、サーバ側に送られる。この結果、
例えば、図６に示すような注文情報一覧がサーバ側で作
成され、買手業者側の端末装置で画面表示される。そし
て、この画面（注文情報一覧画面）上には、買手業者が
入力した注文情報の他、”合計本数”、未選定合計本
数”、及び”合計金額”等の情報も表示される。尚、こ
の”合計本数”、未選定合計本数”、及び”合計金額”
等は、サーバ側で計算して得られ、端末装置に送信され
て表示される。このようにして、買手業者は、自端末装
置上で調達（仕入）計画に従った生花の注文を行う。

【００３９】売手業者は、自端末装置にて、買手業者が
発した注文情報を画面上で参照することで、販売（生
産）計画に従って、買手業者が希望する生花を出荷可能
であるか否かを判断し、出荷可能であれば、それを応募
情報としてキーボード入力する。この応募情報は、サー
バ側に送られる。このようにして、売手業者は、買手業
者が発した注文情報に対して、自端末装置上で応募す
る。尚、売手業者は、買手業者が希望する総本数全てに
対して応募することもでき、その一部に対して応募する
こともできる。或いは、買手業者が希望する総本数より
多い本数を応募することもできる。

【００４０】買手業者は、自端末装置にて、上記図６に
示した注文情報一覧を画面上で再度参照する。このとき
の注文情報一覧には、サーバ側により、売手業者が発し
た応募情報が反映されている。具体的には、例えば、注
文情報一覧の”応募”欄には、注文情報に対して応募し
た売手業者の注文件数が表示されるようになされてお
り、買手業者は、”応募”欄部分の隣の”応”のアイコ
ン部をマウスで指定することで、注文情報に対して応募
した売手業者の詳細情報が参照できるようになされてい
る。このような注文情報一覧画面を買手業者が参照する
ことで、買手業者は、注文情報に対して応募した売手業
者のなかから希望する売手業者を選択して予約し、それ
を発注情報としてキーボード入力する。この発注情報
は、サーバ側に送られ登録される。

【００４１】そして、サーバ側にて、買手業者と売手業
者の成約が成り立つと、サーバ側から売手業者側に対し
て成約通知が送られ、売手業者は、これを受け、買手業
者との取引が確定したことを認識する。尚、この成約通
知を送らずに売手業者が自端末装置にて、例えば、成約
情報一覧を画面上で参照することで、買手業者の取引が
確定したことを認識するようにしてもよい。

【００４２】このとき、買手業者側の上記図６に示した
注文情報一覧には、この成約が”未選定”欄に反映され
る。例えば、ある希望する生花の希望総本数が１００本
であり、この成約で１００本全て確定した場合、未成約
本数である未選定本数は０本となる。また、１００本の
うち４０本が確定した場合、未選定本数は６０本とな
る。また、売手業者が応募した本数が、希望する総本数
より多い場合には、未選定数のマイナス表示を許すこと
により、未選定本数がマイナス本数（−６０本等）とな
る。

【００４３】尚、ここでは、買手業者の注文情報に対し
て各々の売手業者が応募した後、買手業者が該応募情報
を参照して所望する売手業者を選択するようにしたが
（上記図５参照）、例えば、買手業者は、このときの選
択を行わずに、再度新たな注文情報の追加登録するよう
にしてもよい。或いは、以前の注文情報を削除して新た
な注文情報を登録するようにしてもよい。この場合、更
新され注文情報に対して、上述したような売手業者の応
募が繰り返して行われることになる。また、買手業者が
上記の応募情報を選択する際、それらの応募情報の全て
或いは一部を選択可能、或いは拒絶可能とするようにし
てもよい。

【００４４】（Ｂ）販売情報に基づいた取引処理 （第２の取引：販売情報に基づく予約相対取引）本取引
処理は、例えば、図７（Ｂ）に示すような流れに従って
実行される。

【００４５】売手業者は、自端末装置のトップ画面（上
記図４）上で「予約」の項目を選択し指定する。これに
より、装置は、販売情報入力可能状態とな。そして、売
手業者は、希望する生花の品目、品種、色、着荷日、等
階級、産地、生産者名、箱数、及び価格等の販売希望情
報である販売情報（出荷情報）をキーボード入力する。
この結果、例えば、図８に示すような出荷情報一覧が作
成され、画面表示される。そして、このような販売情報
は、サーバ側に送られる。このようにして、売手業者
は、自端末装置上で生花の販売を行う。

【００４６】買手業者は、自端末装置にて、例えば、図
９に示すような、売手業者が発した販売情報を画面上で
希望商品を検索し参照することで、希望する品の箱数等
を購入登録情報としてキーボード入力する。このとき、
希望する箱数の一部の登録も行うことができる。例え
ば、出荷情報の残箱数が５０箱であり、買手業者が本来
希望する箱数は２０箱であるが、そのうちの１０箱のみ
を登録することもできる。そして、このような購入登録
情報は、サーバ側に送られる。このようにして、買手業
者は、売手業者が発した出荷情報に対して、自端末装置
上で購入登録する（タイプ１）。

【００４７】売手業者は、自端末装置にて、買手業者の
登録状況を画面上で参照して判断し、買手業者と成約す
る。

【００４８】尚、買手業者側において、上述したような
購入登録を行う際（タイプ１）、購入価格の指定を行っ
て、これを購入登録情報とすることもできる（タイプ
２）。この場合、例えば、売手業者側の端末装置におい
て、複数の買手業者から指定された各購入価格に基づい
て、適切な買手業者、例えば、最も購入価格の高い買手
業者を自動的に決定するようなアルゴリズムを実行させ
るようにしてもよい。また、販売情報で残数１０箱に対
し、買手業者は、購入登録情報として、例えば、６箱と
し、且つ、６箱以下でも購入する旨の情報を登録するこ
ともできる。これにより、残数１０箱に対して、甲乙２
名の買手業者が各々６箱の購入登録しても、甲が６箱以
下でも購入するという情報であれば、乙に６箱、甲に４
箱、という成約も可能となる。

【００４９】（Ｃ）複数の購入情報及び複数の販売情報
に基づいた取引処理 （第３の取引：複数の購入情報と複数の販売情報を同時
に双方の条件の折り合うものから順次成約決定する取
引）本取引処理は、例えば、上記図７（Ｃ）に示すよう
な流れに従って実行される。

【００５０】ここで、本取引処理は、２つの取引処理
（Ｃ１の取引処理、Ｃ２の取引処理とする）に分けら
れ、これらの２つの取引処理が、買手となる場合のトッ
プ画面（上記図３）の「一般Ｉ」と「一般ＩＩ」に対応
する。そして、Ｃ１の取引処理とＣ２の取引処理は、例
えば、買手業者が上述したような購入登録する際に、詳
細は後述するが、売手業者側が発した販売情報に対して
行う購入登録の方法が異なる。

【００５１】そこで、売手業者は、上述した（Ｂ）の取
引処理の結果、販売情報として発した数量を全て裁きき
れなかった場合、具体的には、ある生花を１００箱、販
売希望したにも関わらず、そのうちの６０箱しか買手業
者と成約できなかった場合、４０箱が残ってしまう。こ
のような販売漏れの生花（未成約の生花）がある場合に
は、売手業者は、自端末装置にて、未成約の生花を検索
し、その情報を得て、トップ画面（上記図４）の「複
写」項目を選択し指定することで、販売漏れの生花、す
なわち（Ｂ）の取引処理での生花のうち販売漏れの生花
についてを、本取引処理に移行する。そして、売手業者
は、販売漏れの生花について、（Ｂ）の取引処理と同様
にして、販売情報をキーボード入力する。また、このと
き、新規に販売希望する生花があれば、それについての
販売情報も入力する。このときに、下限価格情報（販売
下限価格値）も入力する。そして、このような販売情報
は、サーバ側に送られる。また、他の売手業者も同様に
して各々、自端末装置にて、販売希望する生花の販売情
報を入力する。そして、各売手業者の販売情報も、サー
バ側に送られる。したがって、サーバ側には、複数の売
手業者の販売情報が存在することになる。このとき、サ
ーバ側に販売情報が複写された後に生じた販売状況の変
化に応じて、売手業者が自端末装置の画面を見ながら、
販売情報の追加や削除等を行ってもよい。尚、トップ画
面（上記図４）の「複写」による処理についての詳細は
後述する。

【００５２】買手業者は、自端末装置にて、複数の売手
業者が発した販売情報を画面上にて参照し、希望する条
件に合った販売情報に対して、（Ｂ）の取引処理と同様
にして、購入登録するが、このとき、上述のＣ１の取引
処理、或いは、Ｃ２の取引処理で購入登録する。すなわ
ち、Ｃ１の取引処理で購入登録する場合、買手業者は、
自端末装置のトップ画面（上記図３）上で「一般Ｉ」を
選択し指定する。これにより、装置は、上述のように、
複数の売手業者が発した販売情報の参照可能状態とな
り、購入登録可能状態となる。ここでの購入登録は、例
えば、希望する生花の”品目”及び”色”のみの条件
（第１の取引条件）を特定できるようになされている。
一方、Ｃ２の取引処理で購入登録する場合、買手業者
は、自端末装置のトップ画面（上記図３）上で「一般Ｉ
Ｉ」を選択し指定する。これにより、装置は、Ｃ１の取
引処理と同様に、複数の売手業者が発した販売情報の参
照可能状態となり、購入登録可能状態となるが、ここで
の購入登録は、例えば、希望する生花の”品目”及び”
色”のみならず、”品種”や”等階級”等、その他の詳
細な条件（第２の取引条件）を特定できるようになされ
ている。また、買手業者は、このような詳細な条件を複
数の販売情報に対して特定できるようになされている。
そして、このような購入登録情報は、サーバ側に送られ
る。また、他の買手業者も同様にして各々、自端末装置
にて、複数の売手業者が発した販売情報を参照して、Ｃ
１或いはＣ２の取引処理で購入登録する。したがって、
サーバ側には、複数の売手業者が発した販売情報と、複
数の買手業者が発した購入登録情報とが存在することに
なる。

【００５３】サーバ側では、所定の成約決定アルゴリズ
ムによる所定の成約決定処理により、複数の売手業者が
発した販売情報と、複数の買手業者が発した購入登録情
報とに対して、双方の条件の折り合うものから順次成約
（価格）を決定する。尚、ここでの成約決定アルゴリズ
ムは、例えば、販売下限価格の条件を満たし、且つ、購
入価格の高い順、購入情報の入力時間の早い順等により
成約を決定するものである。この成約決定についての情
報は、売手業者側及び買手業者側に通知される。これに
より、売手業者及び買手業者は各々、自端末装置にて、
成約決定について認識する。

【００５４】ところで、この生花取引システム１００で
は、上述のような（Ｃ）の取引処理において、Ｃ２の取
引処理（品目や色と共に種類等の条件も特定）の結果、
未成約の購入情報については、買手業者側の自端末装置
での操作により、その購入情報にて条件を緩和して（品
目や色のみの条件を特定）、Ｃ１の取引処理に移行する
こともでき、これを自動的に行うこともできる。

【００５５】具体的には、例えば、図１０に示すよう
に、先ず、上述したように、（Ｂ）の取引処理の結果、
未成約の生花については、売手業者側からトップ画面
（上記図４）の「複写」項目が選択され指定されること
で、（Ｃ）の取引処理に移行される。例えば、Ｃ２の取
引処理に移行される。これにより、（Ｂ）の取引処理で
の未成約の販売情報が、Ｃ２の取引処理での販売情報と
して登録される。また、このとき、新規に販売希望する
生花があれば、それの販売情報もＣ２の取引処理での販
売情報として登録される。

【００５６】次に、買手業者が自端末装置上で、Ｃ２の
取引処理での販売情報として登録された未成約の販売情
報を参照して、希望する生花があれば、その購入情報を
登録する。これにより、サーバ側において、それらの販
売情報と購入情報を突き合わせ、双方の条件が折り合っ
た場合には成約決定とされ、折り合わなかった場合には
未成約とされる。そして、その結果は売手業者側及び買
手業者側に通知される。買手業者側は、サーバ側からの
通知により、登録した購入情報が未成約であった場合、
自端末装置にて、販売情報の条件を緩和して（品目や色
のみの条件を特定）、その購入情報をＣ１の取引処理に
移行する。これにより、このときの購入情報は、Ｃ１の
取引処理での購入情報として登録され、Ｃ１の取引処理
で処理される。

【００５７】ここで、このようなＣ２の取引処理からＣ
１の取引処理への移行を自動的に行いたい場合、買手業
者側は、購入情報の登録時に、自端末装置にて、登録し
た購入情報がＣ２の取引処理で未成約であったならばＣ
１の取引処理に自動移行するための設定を行う。例え
ば、図１１に示すように、買手業者は、Ｃ２の取引処理
時の画面上にて、マウス等により、購入情報毎に対応し
て設けられたアイコン部を指定（クリック）すること
で、自動移行の設定を行う。この設定情報は、サーバ側
に送られる。これにより、サーバ側で自動移行の設定が
認識され、売手業者側の販売情報と、買手業者側の購入
情報の双方の条件が折り合った場合には、上述したよう
に成約決定とされ、逆に、双方の条件が折り合わなかっ
た場合には、その購入情報は未成約とされて、Ｃ１の取
引処理での購入情報として自動的に登録され、Ｃ１の取
引処理で処理される。

【００５８】上述のような自動移行の設定により、買手
業者は、Ｃ２の取引処理と、Ｃ１の取引処理とを１度の
操作で行うことができる。

【００５９】また、この生花取引システム１００は、例
えば、上述したＣ２の取引処理の結果、大量の販売情報
が未成約で残ってしまった場合、サーバ側が買手業者側
と売手業者側に介入して取引を行うこともできるように
なされている。

【００６０】すなわち、図１２に示すように、サーバ側
（市場運営者等）は、自端末装置にて、Ｃ１の取引処理
の結果を参照する。例えば、サーバ側は、図１３に示す
ように、自端末装置の画面上にて、マウス等により、
「成約検索」や「未成約検索」等のアイコンを指定（ク
リック）する等の操作を行うことで、成約した販売情報
や未成約の販売情報の一覧画面を出力させ、この画面上
の情報により、Ｃ１の取引処理の結果を把握する。そし
て、未成約の販売情報に含まれる各種情報を調整し、成
約率を上げて確定させるようにする。このとき、未成約
の販売情報に含まれる下限価格の調整を行った場合、そ
の調整を行った販売情報を再度Ｃ１及びＣ２の取引処理
での販売情報として登録する。したがって、下限価格が
調整された販売情報は、上述したようにしてＣ２の取引
処理から順にＣ１の取引処理で処理される。

【００６１】尚、上述したようにして、下限価格が調整
された販売情報を再度Ｃ１及びＣ２の取引処理で処理す
る場合、この結果は、仮成約又は未成約となる。

【００６２】また、上述した成約決定アルゴリズムで
は、購入希望価格の高い順や情報入力の早い順に成約決
定するようにしたが、これに限らず、例えば、購入希望
数量の多い順や過去の取引規模などの因子により予め決
められた優先順位に従って成約決定するようにしてもよ
い。或いは、購入希望数量の一部でも販売残数があれば
購入したいという要求をも許容して、これを優先順位決
定に反映させて成約決定してもよい。したがって、例え
ば、購入希望価格の高い順に成約決定する場合で、同じ
価格の購入情報が存在した場合、それらの中でさらに数
量の多い順や、情報入力の早い順、或いは上述の購入希
望数量に欠けが存在した場合の購入許可など、買手業者
側の購入条件に許容範囲の広いもの、などの一部或いは
これらの組み合わせのアルゴリズムを用いるようにして
もよい。また、対象商品の条件許容度が高い（条件が緩
い）場合に、（Ｃ）の取引処理へ移行し、許容度が低い
（条件が厳しい）場合には、（Ｃ）の取引処理に移行し
ない、というようなアルゴリズムを付加するようにして
もよい。

【００６３】また、売手業者が発する販売情報中に下限
価格情報（販売下限価格値）を含むようにしたが、下限
価格情報を”０”（ゼロ）とし、完全な販売委託方式に
してもよし、下限価格情報の代わりに別のパラメータを
用いるようにしてもよい。例えば、販売最低本数の情報
を用いるようにしてもよい。

【００６４】また、Ｃ１及びＣ２の取引処理での条件入
力（Ｃ２では詳細は条件入力、Ｃ１では該条件を緩和し
た条件入力）を、買手業者が決定して行うものとした
が、例えば、システム内で予め各々の項目（「品種」、
「品目」、「色」等）及びその内容（例えば、項目「品
目」であれば、「菊」、「バラ」等の内容）を設定して
おき、その中から買手業者が所望する項目及びその内容
（条件）を指定するようにしてもよい。具体的には例え
ば、取引対象商品が野菜であった場合、「品種」、「規
格」のみの条件と、この「品種」、「規格」に産地・生
産者名の条件とを予めテーブル等で用意しておく。ま
た、航空チケットの場合には、フライト日と区間のみの
条件と、これに航空会社名或いは具体的な便名（複数も
可）等の複数の条件を予め用意しておく。これにより、
買手業者は、多様な条件の設定を行うことができる。

【００６５】以上、生花取引システム１００による
（Ａ）、（Ｂ）、及び（Ｃ）の各取引処理の流れについ
て説明した。

【００６６】つぎに、上述したサーバ側の端末装置が有
する”価格予想機能”について具体的に説明する。

【００６７】この価格予測機能とは、上述したような
（Ａ）、（Ｂ）、及び（Ｃ）等の各取引において、取引
対象となる生花の価格の変動を予測するための機能であ
り、この機能により、市場運用（管理）者は、自端末装
置（サーバ側の端末装置）上で価格を容易に予測するこ
とができる。

【００６８】すなわち、図１４に示すように、サーバ側
の端末装置において、記憶機能（ＤＢＭ）には、個人別
マーケット分析機能により種々のデータが記憶されると
共に、取引時に発生した各種データが記憶される。この
ＤＢＭに記憶された各種データを多変量解析処理等によ
り解析し、その解析結果からモデルを生成する。そし
て、生成したモデルにより、そのときの市場状況に対す
る価格の変動等を予測する。このような価格予測は、生
花の品目毎や季節等の予測条件に応じて行えるようにな
されている。

【００６９】つぎに、上述したトップ画面（上記図４）
の「複写」による処理について具体的に説明する。

【００７０】「複写」による処理（複写処理）は、上述
したように、売手側において、（Ｂ）の取引処理の結
果、販売漏れがあった場合に行われる処理であり、この
複写処理を実行することで、（Ｂ）の取引処理が（Ｃ）
の取引処理に移行される。

【００７１】すなわち、図１５に示すように、（Ｂ）の
取引処理の結果、成約された生花（成約出荷商品）と、
未成約となった生花（未成約出荷商品）とが発生する。
このときの商品の価格（販売価格）を”ｘ”、下限価格
（最低希望価格）を”ｙ”とする。これらの成約出荷商
品及び未成約出荷商品の各情報は、サーバ側の端末装置
に送られ、そのＤＢＭに記憶される。

【００７２】売手側は、自端装置にて、サーバ側のＤＢ
Ｍの記憶情報から生成された、例えば、図１６に示すよ
うな、未成約出荷一覧の画面を参照することで、複写処
理を実行するか否かを判断し、上記図４に示した画面の
「複写」を選択し指定する。そして、売手側は、複写す
る商品を個別に選択し、複写するものを指定する。尚、
このとき、未成約商品を全て一括して指定できるように
してもよい。また、売手側は、販売価格ｘを販売価格
ｘ’（ｘ≠ｘ’）、下限価格ｙを下限価格ｙ’（ｙ≠
ｙ’）に各々変更する指定も行うことができる。これに
より、サーバ側のＤＢＭに記憶された不成立出荷商品の
情報は、価格変更も含めて、（Ｃ）の取引処理での商品
の情報とされる。また、このとき、売手側が新たに商品
の登録（新規登録）を、販売価格ｘ₁ ’、下限価格をｙ
₁ ’として行った場合には、これらの情報も含めて、
（Ｃ）の取引処理での商品の情報とされる。

【００７３】そして、売手側は、自端末装置にて、例え
ば、図１７に示すような販売情報一覧画面により、
（Ｃ）の取引処理に移行した商品、新規登録した商品、
及びそれらの情報を登録した日（情報登録日）を確認す
る。

【００７４】尚、売手業者が発する販売情報において、
下限価格の代わりに、上述したような他のパラメータ
（販売最低本数等）を利用した場合、そのパラメータを
変更することになる。

【００７５】つぎに、生花取引システム１００で行える
他の処理として、集統計処理について説明する。

【００７６】この集統計処理は、売手側の端末装置にお
いて、上記図４に示したトップ画面の「集統計」の項目
が選択され指定されたときに実行される処理である。す
なわち、売手側は、自端末装置にて、トップ画面の「集
統計」の項目を選択し指定する。これにより、装置に
は、例えば、図１８に示すような集統計情報表示一覧画
面が表示される。この集統計情報表示一覧画面には、今
後発生する予定の取引（既に決定している取引）につい
ての情報、具体的には、先渡し（荷渡し）の日付、生花
の平均価格、最高価格、最低価格、及び総本数等の情報
を含む。これらの情報は、画面上で日付け、品目、品種
等の条件を指定することで、指定された条件毎の情報を
表示することもできる。このような画面により、売手側
は今後の予定を把握することができる。また、同様に買
手側も、自端末装置にて、トップ画面（上記図３）の
「集統計」の項目を指定し、種々の条件を指定すること
で、買手側の今後の予定を把握することができる。

【００７７】尚、上述した実施の形態では、対象商品を
生花等の生鮮商品を一例として説明したが、これに限ら
れることはない。航空チケットや他の交通機関のチケッ
ト、コンサートチケットのように、使用可能な期限が決
まった商品にも適用することができる。例えば、航空チ
ケットの場合、上述した生産者が航空会社に対応し、大
手売手業者が航空会社の支店などの営業部門、或いは大
手旅行会社などの販売エ−ジェントに対応し、小口売手
業者が各旅行代理店や航空チケットを扱うコンビニエン
スストアなどの販売店に対応する。また、１２月３０日
又は２９日のＸＸＸ便を２席購入したい、或いは１２月
２９日のＡ空港からＢ空港までのＸＸＸ便又はＹＹＹ便
を２席購入したい等が（Ａ）取引処理に対応し、１２月
２９日から１月５日までのＸＸＸ便がα円、ＹＹＹ便が
β円で各々１００席ずつある等の情報に基づいた取引が
（Ｂ）取引処理に対応し、これらの条件に様々な広がり
を有する購入情報と販売情報を突き合わせて価格と数量
の決定を行う取引が（Ｃ）取引処理に対応する。したが
って、このように、航空チケット等の期限付きの商品や
期日付きの商品についても、本発明は適用可能である。

【００７８】（第２の実施の形態）本実施の形態では、
上述した（Ｃ）の取引処理での成約決定のアルゴリズム
（複数の購入情報と複数の販売情報を紐付けして取引成
立するためのアルゴリズム）を、より具体化した一例と
して、次のような［アルゴリズム１］と［アルゴリズム
２］とする。尚、ここでは、販売情報や購入情報に含ま
れる項目（「品目」や「色」等）に基づいて、あるまと
まり、集団等を特定することを”クラスタリング”と言
い、そのクラスタリングの基となる項目を”クラスタリ
ング属性”という。例えば、複数の購入情報を、クラス
タリング属性を「品目」及び「色」としてクラスタリン
グした場合、リンギク／白の購入情報群（クラスタ）、
ガーベラ／赤の購入情報群、・・・が生成されることに
なる。

【００７９】［アルゴリズム１］図１９は、本アルゴリ
ムを図示したものである。この図１９に示すように、
「品種」及び「色」をクラスタリング属性とするレベル
１（図中（Ａ））、「品種」、「色」、及び「規格」を
クラスタリング属性とするレベル２（図中（Ｂ））、
「品種」、「色」、「規格」、及び「生産者」をクラス
タリング属性とするレベル３（図中（Ｃ））が、予め規
定されている。すなわち、レベル１よりもレベル２が、
レベル２よりもレベル３が細かい条件指定となる。この
レベル規定は、例えば、市場運営者がこれらのレベル
（以下、「クラスタレベル」とも言う）を予め決定して
システム的に用意しておく。尚、ここでは説明の簡単の
ために３つのレベル規定とするが、これに限られること
はなく、その他複数レベル用意するようにしてもよい。

【００８０】買手業者は、これらレベル１〜３のどのレ
ベルで取引を行うか指定し、その指定したレベルのクラ
スタリング属性の各項目に、その内容を設定する。具体
的には例えば、ある買手業者は、レベル１での取引を指
定し、そのレベル１のクラスタリング属性の項目「品
種」と「色」に対して、希望する”精雲”と”白”を設
定する。また、ある買手業者は、レベル２での取引を指
定し、そのレベル２のクラスタリング属性の項目「品
種」、「色」、及び「規格」に対して、希望する”精
雲”、”白”、及び”秀Ｌ”を設定する。したがって、
買手業者からは、各々の指定レベルに従ったクラスタリ
ング属性の項目に、その内容が設定された購入情報が発
せられることになる。ここでは、レベル１指定での購入
情報を購入情報Ａ−、レベル２指定での購入情報を購
入情報Ｂ−、レベル３指定での購入情報を購入情報Ｃ
−とする。

【００８１】そこで、先ず、最も条件指定が細かい購入
情報Ａ−を、そのクラスタリング属性の項目である
「品種」、「色」、「規格」、及び「生産者」でクラス
タリングする。また、上記のクラスタリング属性に従っ
て、売手業者側からの販売情報をクラスタリングする。
そして、同一クラスタ内で、購入情報と販売情報を紐付
けして成約決定する（以下、ここでの成約決定処理を
「成約決定処理１」とする）。

【００８２】次に、次に条件指定が細かい購入情報Ａ−
を、そのクラスタリング属性の項目である「品種」、
「色」、及び「規格」でクラスタリングする。また、上
記のクラスタリング属性に従って、売手業者側からの販
売情報（成約決定処理１で残った販売情報）をクラスタ
リングする。そして、同一クラスタ内で、購入情報と販
売情報を紐付けして成約決定する（以下、ここでの成約
決定処理を「成約決定処理２」とする）。

【００８３】そして最後に、購入情報Ａ−を、そのク
ラスタリング属性の項目である「品種」及び「色」でク
ラスタリングする。また、上記のクラスタリング属性に
従って、売手業者側からの販売情報（成約決定処理１及
び２で残った販売情報）をクラスタリングする。そし
て、同一クラスタ内で、購入情報と販売情報を紐付けし
て成約決定する。

【００８４】ここで、上述のようなアルゴリズムに従っ
たクラスタリングでは、購入情報と販売情報の対応する
クラスタ毎に、予め規定された処理順（ここでは、レベ
ル３→レベル２→レベル１）で成約決定するようにし
た。これは、例えば、レベル１での”精雲”と”白”の
クラスタは、レベル２での”精雲”、”白”、及び”秀
Ｌ”のクラスタに含まれる、ということから、各クラス
タが他のクラスタと部分的に重複している場合もあるた
めである。したがって、通常は売手業者側にとって需要
度が高く、価格の高くなるレベル３→レベル２→レベル
１の処理順が一般的である、ということから、ここでは
レベル３→レベル２→レベル１のように、条件指定の細
かい順で処理を行うようにした。しかしながら、この処
理順に限られることはなく、市場運営者等が任意に予め
規定するようにしてもよい。尚、成約決定の際の紐付け
についての詳細は後述する。

【００８５】［アルゴリズム２］本アルゴリズムでは、
図２０（ａ）に示すように、買手業者側からの購入情報
の処理順（購入希望価格の高い順、数量の多い順、情報
入力時刻の早い順等、予め規定された処理順）を決定
し、その決定した順に、購入情報の条件に従って販売情
報をクラスタリングする。或いは、上記図２０（ｂ）に
示すように、販売業者側からの販売情報の処理順（販売
希望価格の高い順或いは低い順、数量の多い順、情報入
力時刻の早い順等、予め規定された処理順）を決定し、
その決定した順に、販売情報の条件に従って購入情報を
クラスタリングする。

【００８６】図２１は、上述したような各アルゴリズム
において、購入情報と販売情報の対応するクラスタ内で
の紐付けの一例を示したものである。ここでは、ある購
入情報のクラスタ内に購入情報（１）〜（４）が存在
し、それに対応する販売情報のクラスタ内に販売情報
（ａ）〜（ｂ）が存在するものとしている。そして、ク
ラスタ内での紐付けの基準を、価格、数量、及び情報入
力時刻としている。また、購入情報（１）と購入情報
（４）は、同じ上限価格を指定しており、数量もその範
囲の同じものを指定している。但し、購入情報（１）の
ほうが購入情報（４）よりも早く入力されたものとす
る。購入情報（２）と購入情報（３）は、上限価格、数
量、及びその範囲を他者と異なるものを指定している。
一方、販売情報（ｂ）は、最も低い下限価格を指定して
おり、販売情報（ｃ）は、最も高い下限価格を指定して
いる。販売情報（ａ）は、販売情報（ｂ）と販売情報
（ｃ）の各下限価格の間の価格を下限価格として指定し
ている。

【００８７】そこで、上述のような購入情報（１）〜
（４）のクラスタと、販売情報（ａ）〜（ｂ）のクラス
タとでの紐付けは、次のような順序で行われる。

【００８８】１．上限価格の高い順に、購入情報の紐付
け処理順を決定する。このとき、上限価格が同じ購入情
報が存在した場合は数量を多く指定してある方を優先
し、数量も同じ指定であった場合は、情報入力時刻の早
い方を優先する。ここでは、最も高い上限価格を指定し
た購入情報が、購入情報（１）と購入情報（４）の２つ
であるが、これらの購入情報のうち情報入力時刻が早い
のは購入情報（１）であるため、この購入情報（１）を
優先する。したがって、購入情報の紐付け処理順は、購
入情報（１）→購入情報（４）→購入情報（３）→購入
情報（２）となる。

【００８９】２．下限価格の高い順に、販売情報の紐付
け処理順を決定する。或いは、買手業者に上限価格の高
値入力を促し、売手業者に下限価格の安値入力を促すと
いう観点から、下限価格の低い順に、販売情報の紐付け
処理順を決定する。このときも、下限価格が同じ販売情
報が存在した場合は数量を多く指定してある方を優先
し、数量も同じ指定であった場合は、情報入力時刻の早
い方を優先する。したがって、下限価格の高い順の場
合、販売情報の紐付け処理順は、販売情報（ｃ）→販売
情報（ａ）→販売情報（ｂ）となり、下限価格の低い順
の場合、販売情報の紐付け処理順は、販売情報（ｂ）→
販売情報（ａ）→販売情報（ｃ）となる。

【００９０】３．販売情報の紐付け処理順が下限価格の
高い順である場合、購入情報（１）は、最初の販売情報
（ｃ）が条件を満たすものであれば、これと紐付けられ
て成約決定となる。このとき、販売情報（ｃ）の条件で
は満たされない場合、次の販売情報（ａ）と紐付けられ
る。販売情報（ａ）でも満たされないときは、最後の販
売情報（ｂ）と紐付けられる。また、例えば、購入情報
（１）と販売情報（ｃ）が紐付けられ、購入情報（１）
の希望する数量（必要数量）が販売情報（ｃ）で指定さ
れている数量では満たされない場合、該必要数量が満た
されるまで、次の販売情報（ここでは販売情報（ａ）、
販売情報（ｂ））との紐付けが繰り返し行われる。販売
情報の紐付け処理順が下限価格の低い順である場合も同
様にして、購入情報（１）は、販売情報（ｂ）、販売情
報（ａ）、販売情報（ｃ）の順に、紐付けられて成約決
定される。この場合の紐付け処理順で処理を進めると、
購入情報（１）の上限価格を下回る販売情報の下限価格
（最安値）の商品が、購入情報（１）に紐付けられるこ
とになるため、成約決定の確率が高くなり、取引がより
活性化される、という効果がある。その後、次の購入情
報（４）が同様にして処理され、続いて、購入情報
（３）、購入情報（２）が順に処理される。

【００９１】上述の処理３．での成約決定の際の価格に
ついては、購入情報にて指定されている上限価格（＠
１）に基づいて決定するのが一般的であるが、これに限
らず、販売情報にて指定されている下限価格（＠２）に
基づいて決定するようにしてもよい。或いは、購入情報
と販売情報の各々で指定されている価格に基づいて決定
するようにしてもよい。例えば、購入情報の上限価格
（＠１）と販売情報の下限価格（＠２）の内分点（（＠
１＋＠２）／２）に基づいて価格決定する。

【００９２】尚、上述した紐付け処理と価格決定処理に
ついては、対象コンテンツの特性や取引参加者の評価関
数によりＮＯＮル−ル化してもよいし、ＧＡを利用する
ようにしてもよい。

【００９３】ところで、本実施の形態では、対象商品を
生花としているが、これに限られることはない。例え
ば、航空チケットや他の交通機関のチケット、コンサー
トチケットのように、使用可能な期限が決まった商品で
もよい。

【００９４】その一例として、図２２は、対象商品を航
空チケットとした場合に、売手側の販売情報に対して買
手側が様々な条件付け（様々なクラスタレベルでのクラ
スタリング属性の項目の内容の限定）を行った際の紐付
け処理順の抽象度が、上述した生花の場合と、どのよう
に対応するかを示したものである。この図２２に示すよ
うに、航空チケットの場合においても、共通項目である
「価格」及び「数量」に加えて、「便名」、「航空会
社」、「時間帯」、「フライト日」、「ＯＤ（出発地、
到着地）」と、指定項目が多ければ多いほど、抽象度が
高くなり、先に処理されることになる。尚、航空チケッ
トの場合、生産者が航空会社に対応し、大手売手業者が
航空会社の支店などの営業部門、或いは大手旅行会社な
どの販売エ−ジェントに対応し、小口売手業者が各旅行
代理店や航空チケットを扱うコンビニエンスストアなど
の販売店に対応する。

【００９５】具体的には例えば、図２３は、クラスタレ
ベル１〜４が仲介業者により予め決定されており、買手
側がそれらのクラスタレベル１〜４の中から任意に決定
したクラスタレベルのクラスタリング属性の項目にその
内容を設定する場合の、買手側１〜３の紐付け処理順を
示したものである。この図２３に示すように、最も条件
指定が細かいクラスタレベル４（「フライト日」、「午
前又は午後指定」、「航空会社」、及び「便名」の全て
の指定）にてその内容を設定した買手側３が先ず最初の
処理対象となり、次に条件指定が細かいクラスタレベル
３（「フライト日」、「午前又は午後指定」、及び「航
空会社」の指定）にてその内容を設定した買手側２が次
の処理対象となり、そして最後の買手側１が処理対象と
なる。

【００９６】また、図２４、買手側１〜４が各々クラス
タリング属性の項目及びその内容（条件）を任意に設定
する場合の、買手側１〜４の紐付け処理順を示したもの
である。この図２４に示すように、最も条件指定が細か
い買手側４が先ず最初の処理対象となり、続いて、買手
側３、買手側２、買手側１が順に処理対象となる。先ず
最初の買手側４については、対応する販売情報は販売情
報の１つのみであるため、これを紐付けする。次の買
手側３については、対応する販売情報は販売情報及び
の２つであるため、それらのうちの販売金額の高い販
売情報の方を優先して紐付けする。次の買手側２につ
いても同様に、対応する販売情報、、、及びの
４つのうち、販売金額の高い順で、販売金額が同じなら
ば席数の多い方を優先して、該当する販売情報を紐付け
する。そして最後の買手側１についても同様に、対応す
る販売情報〜（全ての販売情報）のうち、販売金額
の高い順で、販売金額が同じならば席数の多い方を優先
して、さらに席数が同じならば情報入力時刻の早い方を
優先して、該当する販売情報を紐付けする。

【００９７】以上の説明から、本実施の形態でのクラス
タリング属性の項目指定及び処理順については、次のよ
うにまとめられる。 １．クラスタリング属性の項目とその内容 市場運営者や仲介業者が予め決定する。 買手側が任意に決定する。 ２．クラスタ間の処理順 条件指定が細かい（指定項目が多いもの、内容の限
定が細かいもの）クラスタから順に処理する。 市場運営者や仲介業者が予め決定する。 ３．クラスタ内の処理順 購入情報のクラスタ内の処理順を決定してから、購
入情報毎に販売情報をクラスタリングする。 販売情報のクラスタ内の処理順を決定してから、販
売情報毎に購入情報をクラスタリングする。

【００９８】尚、本発明の目的は、上述した各実施の形
態のサーバ及び端末の機能を実現するソフトウェアのプ
ログラムコードを記憶した記憶媒体を、システム或いは
装置に供給し、そのシステム或いは装置のコンピュータ
（又はＣＰＵやＭＰＵ等）が記憶媒体に格納されたプロ
グラムコードを読みだして実行することによっても、達
成されることは言うまでもない。この場合、記憶媒体か
ら読み出されたプログラムコード自体が上述した各実施
の形態の機能を実現することとなり、そのプログラムコ
ードを記憶した記憶媒体は本発明を構成することとな
る。

【００９９】プログラムコードを供給するための記憶媒
体としては、ＲＯＭ、フロッピーディスク、ハードディ
スク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、Ｃ
Ｄ−Ｒ、磁気テープ、不揮発性のメモリカード等を用い
ることができる。

【０１００】また、コンピュータが読みだしたプログラ
ムコードを実行することにより、上述した各実施の形態
の機能が実現されるだけでなく、そのプログラムコード
の指示に基づき、コンピュータ上で稼動しているＯＳ等
が実際の処理の一部又は全部を行い、その処理によって
各実施の形態の機能が実現される場合も含まれることは
言うまでもない。

【０１０１】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された拡張機能ボー
ドやコンピュータに接続された機能拡張ユニットに備わ
るメモリに書き込まれた後、そのプログラムコードの指
示に基づき、その機能拡張ボードや機能拡張ユニットに
備わるＣＰＵなどが実際の処理の一部又は全部を行い、
その処理によって上述した各実施の形態の機能が実現さ
れる場合も含まれることは言うまでもない。

【０１０２】

【発明の効果】以上説明したように本発明によれば、所
謂先渡し取引をネットワーク上で可能にし、今迄にない
販売及び調達の機会を売手側及び買手側に与えることが
できるようになるため、従来にない効率的な商品取引が
できる。具体的には、商品の売買の取引をシステム化し
て、複数の購入情報（買手側が調達希望する商品の品目
や種類、価格等）と複数の販売情報（売手側が販売希望
する商品の品目や種類、価格等）を同時に双方の条件の
折り合うものから順次成約決定する取引処理を、端末装
置の画面上で行えるようにした。また、買手側は、複数
の売手が発した販売情報に対して、それに含まれる情報
のうち任意の情報を第１又は第２の取引条件として特定
できるようにした。例えば、品目のみを第２の取引条件
として特定（厳密な特定）、或いは、品目と共に種類ま
でを第１の取引条件として特定（第２の特定条件よりも
広範囲な特定）できるようにした。そして、第２の取引
条件に従った取引処理で未成約であった販売情報を、自
動的に第１の取引条件に従った取引処理に移行し、再度
その取引処理で処理できるようにした。このような構成
とすることで、少なくとも次のような効果が得られる。

【０１０３】（１）買手側は、卸売市場等に出向く必要
がなく、自端末装置にて、希望する商品が販売されてい
るか等を容易に把握することができ、希望する商品を容
易に仕入れることができる。また、事前にこれを行うこ
とができる。これにより、調達計画を立てることができ
る。

【０１０４】（２）売手側は、自端末装置にて、販売す
る商品に買手がつくか、どのくらいの量を販売できるか
等を事前に把握することができる。これにより、販売計
画を立てることができるため、無駄な商品の発生も抑え
ることができ、特に、ある期間を過ぎると価値が無くな
る生花等においては、その商品の鮮度保持も可能とな
る。

【０１０５】（３）買手側は、自端末装置にて、大量の
商品を希望する場合であっても、容易に品揃えすること
ができる。

【０１０６】（４）売手側は、販売計画を立てることが
できるため、生産者側もそれに従って、生産計画を立て
ることができる。

【０１０７】（５）商品の出荷前に売手側と買手側間で
その商品を取引を行うことができる。

【０１０８】（６）希望する商品を厳密に条件付けた購
入と、その条件範囲を広げた購入とを１度の操作で行う
こともできる。これにより、成約率を向上させることが
でき、取引効率も飛躍的に向上させることができる。

【０１０９】したがって、本発明によれば、計画的な商
品の生産及び販売を行うことができ、また、計画的な商
品の調達も行うことができ、これにより、効率的な商品
の売買取引を行うことができる。

【図面の簡単な説明】

【図１】第１の実施の形態において、本発明に係る商品
取引システムを適用した生花取引システムの構成を示す
ブロック図である。

【図２】上記生花取引システムの各業者側及びサーバ側
の端末装置の内部構成を示すブロック図である。

【図３】買手側のトップ画面を説明するための図であ
る。

【図４】売手側のトップ画面を説明するための図であ
る。

【図５】注文情報に基づく予約相対取引処理を説明する
ための図である。

【図６】上記取引処理において、注文情報一覧画面を説
明するための図である。

【図７】販売情報に基づく予約相対取引処理を説明する
ための図である。

【図８】上記取引処理において、販売（出荷）情報一覧
画面を説明するための図である。

【図９】上記取引処理において、売手側が発した販売情
報の画面を説明するための図である。

【図１０】取引処理の移行を説明するための図である。

【図１１】上記移行処理において、買手側の画面上での
設定を説明するための図である。

【図１２】上記移行処理後に発生した未成約の販売情報
に対してサーバ側が行う処理を説明するための図であ
る。

【図１３】上記サーバ側の画面上での操作を説明するた
めの図である。

【図１４】販売価格予測機能を説明するための図であ
る。

【図１５】複写処理を説明するための図である。

【図１６】上記複写処理において、未成約出荷一覧画面
を説明するための図である。

【図１７】上記複写処理において、販売情報一覧画面を
説明するための図である。

【図１８】集統計処理において、集統計情報表示一覧画
面を説明するための図である。

【図１９】第２の実施の形態において、複数の上記購入
情報と複数の上記販売情報を紐付けして取引成立するた
めのアルゴリズム１を説明するための図である。

【図２０】複数の上記購入情報と複数の上記販売情報を
紐付けして取引成立するためのアルゴリズム２を説明す
るための図である。

【図２１】上記の各アルゴリズムにおいて、購入情報と
販売情報の対応するクラスタ内での紐付けの一例を説明
するための図である。

【図２２】対象商品を航空チケットとした場合の、売手
側の販売情報に対して買手側が様々な条件付けを行った
際の紐付け処理順の抽象度を説明するための図である。

【図２３】上記の紐付け処理順をより具体化（買手側が
条件のレベルを指定する場合）して説明するための図で
ある。

【図２４】上記の紐付け処理順をより具体化（買手側が
条件を任意に指定する場合）して説明するための図であ
る。

【符号の説明】

１００ 生花取引システム １０１ サーバ側の端末装置 １１１〜１１４ 大手売手業者側の端末装置 １２１〜１２３ 大手買手業者側の端末装置 １３１ 中卸業者側の端末装置 １４１ 小口売手業者側の端末装置 １５１ 小口買手業者側の端末装置 １６１ ＷＡＮ １７１〜１７３ 生産者

Claims (8)

【特許請求の範囲】
1. 【請求項１】 複数の端末装置から出力される商品の売
   買取引のための販売情報と購入情報情報に基づいて、商
   品の売買の成約を決定するシステムにおける上記複数の
   端末装置の少なくとも１つの端末装置であって、 複数の上記購入情報と複数の上記販売情報を突き合わせ
   て、双方の条件の折り合うものから順次成約決定する取
   引の処理を行う取引処理手段を備え、 上記取引処理手段は、上記販売情報に含まれる商品に関
   する情報の任意の情報を第１の取引条件として特定する
   第１の特定手段と、上記販売情報に含まれる商品に関す
   る情報の任意の情報を第２の取引条件として特定する第
   ２の特定手段と、上記第２の取引条件に従った取引処理
   により発生した未成約商品の販売情報を上記第１の取引
   条件に従った取引処理に移行する処理移行手段とを含む
   ことを特徴とする請求項１記載の商品取引装置。
2. 【請求項２】 上記第１の取引条件は、上記第２の取引
   条件より広範囲の条件であることを特徴とする請求項１
   記載の商品取引装置。
3. 【請求項３】 上記販売情報は、下限価格情報を含むこ
   とを特徴とする請求項１記載の商品取引装置。
4. 【請求項４】 各取引処理を実行するためのアイコン機
   能を有する表示手段を備えることを特徴とする請求項１
   記載の商品取引装置。
5. 【請求項５】 上記商品は、商品毎に想定される期間経
   過後には価値がなくなる或いは減少するものであること
   を特徴とする請求項１記載の商品取引装置。
6. 【請求項６】 複数の端末装置から出力される商品の売
   買取引のための販売情報と購入情報から商品の売買の成
   約を決定する商品取引システムであって、 上記複数の端末装置の少なくとも１つの端末装置は、請
   求項１〜５の何れかに記載の商品取引装置であることを
   特徴とする商品取引システム。
7. 【請求項７】 複数の端末装置とホストが相互通信する
   ことで、上記複数の端末装置から出力される商品の売買
   取引のための販売情報と購入情報から商品の売買の成約
   を決定する商品取引システムであって、 上記端末装置は、送られてきた情報をブラウザ機能によ
   り画面表示し、その画面上の情報に基づいて行われたユ
   ーザからの操作に従って情報を出力し、 上記ホストは、複数の上記購入情報と複数の上記販売情
   報を突き合わせて、双方の条件の折り合うものから順次
   成約決定する取引の処理を行う取引処理機能を有し、 上記取引処理機能は、上記販売情報に含まれる商品に関
   する情報の任意の情報を第１の取引条件として特定する
   第１の特定機能と、上記販売情報に含まれる商品に関す
   る情報の任意の情報を第２の取引条件として特定する第
   ２の特定機能と、上記第２の取引条件に従った取引処理
   により発生した未成約商品の販売情報を上記第１の取引
   条件に従った取引処理に移行する処理移行機能とを含む
   ことを特徴とする商品取引システム。
8. 【請求項８】 複数の端末装置から出力される商品の売
   買取引のための販売情報と購入情報情報に基づいて、商
   品の売買の成約を決定するための処理ステップを実行す
   るプログラムを格納した記憶媒体であって、上記処理ス
   テップは、 複数の上記購入情報と複数の上記販売情報を突き合わせ
   て、双方の条件の折り合うものから順次成約決定する取
   引の処理を行う取引処理ステップを含み、 上記取引処理ステップは、上記販売情報に含まれる商品
   に関する情報の任意の情報を第１の取引条件として特定
   する第１の特定ステップと、上記販売情報に含まれる商
   品に関する情報の任意の情報を第２の取引条件として特
   定する第２の特定ステップと、上記第２の取引条件に従
   った取引処理により発生した未成約商品の販売情報を上
   記第１の取引条件に従った取引処理に移行する処理移行
   ステップとを含むことを特徴とする記憶媒体。