JP2021039392A - 商品取引システム、商品取引方法および商品取引プログラム - Google Patents

Abstract

【課題】生産者と買い手との間で直接的な商品の取引をも可能とするプラットフォームを提供する。
【解決手段】買い手と供給者との間の商品取引を行うための商品取引システムが提供される。商品取引システムは、買い手から特定の商品の購入希望価格を含む購入要求を受け付ける第１の受付手段と、供給者から特定の商品の販売希望価格を含む販売要求を受け付ける第２の受付手段と、供給者から買い手までの特定の商品を配送するための配送費を反映した上で、購入要求と販売要求とがマッチングするか否かを判断する判断手段とを含む。
【選択図】図１

Description

本開示は、買い手と供給者との間の商品取引を行うための商品取引システム、商品取引方法および商品取引プログラムに関する。

従来の流通システムにおいては、生産者から小売りを介して買い手の元へ商品が届けられる。このような流通システムに対して、例えば、特開２０１９−１２８８１４号公報（特許文献１）は、マーケットを活性化できる電子売買システムを開示する。

特開２０１９−１２８８１４号公報

上述の特許文献１に開示される電子売買システムは、購入者と販売者との間の商品売買を支援するものであるが、例えば、工業製品を製造する生産者とその工業製品の買い手との直接的な取引を実現するようなものではない。

本開示は、生産者と買い手との間で直接的な商品の取引をも可能とするプラットフォームを提供することを目的とする。

本開示のある形態によれば、買い手と供給者との間の商品取引を行うための商品取引システムが提供される。商品取引システムは、買い手から特定の商品の購入希望価格を含む購入要求を受け付ける第１の受付手段と、供給者から特定の商品の販売希望価格を含む販売要求を受け付ける第２の受付手段と、供給者から買い手までの特定の商品を配送するための配送費を反映した上で、購入要求と販売要求とがマッチングするか否かを判断する判断手段とを含む。

商品取引システムは、１または複数の購入要求、および、１または複数の販売要求を一時的に保持するための要求キューをさらに含んでいてもよい。判断手段は、購入要求もしくは販売要求が要求キューに追加されたとき、または、要求キューに保持されている購入要求もしくは販売要求が変更されたときに、購入要求と販売要求とがマッチングするか否かを判断するようにしてもよい。

商品取引システムは、供給者または特定の商品に関連付けられた配送費定義と、買い手と供給者との間の距離とに基づいて、特定の商品を配送するための配送費を算出する算出手段をさらに含んでいてもよい。

商品取引システムは、買い手および供給者の各々が保有する経済的価値を管理する口座をさらに含んでいてもよい。第１の受付手段は、購入要求に含まれる購入希望価格に基づいて決定される価値を対応する買い手の口座から予約するようにしてもよい。

商品取引システムは、マッチングした購入要求と販売要求とに基づく商品取引が完了すると、当該購入要求に対応する買い手の口座から利用料を徴収する手段をさらに含んでいてもよい。

本開示の別の形態によれば、買い手と供給者との間の商品取引をコンピュータが実行する商品取引方法が提供される。商品取引方法は、買い手から特定の商品の購入希望価格を含む購入要求を受け付けるステップと、供給者から特定の商品の販売希望価格を含む販売要求を受け付けるステップと、供給者から買い手までの特定の商品を配送するための配送費を反映した上で、購入要求と販売要求とがマッチングするか否かを判断するステップとを含む。

本開示のさらに別の形態によれば、コンピュータに買い手と供給者との間の商品取引を実行させるための商品取引プログラムが提供される。商品取引プログラムは、コンピュータに、買い手から特定の商品の購入希望価格を含む購入要求を受け付けるステップと、供給者から特定の商品の販売希望価格を含む販売要求を受け付けるステップと、供給者から買い手までの特定の商品を配送するための配送費を反映した上で、購入要求と前記販売要求とがマッチングするか否かを判断するステップとを実行させる。

本開示によれば、生産者と買い手との間で直接的な商品の取引をも可能とするプラットフォームを実現できる。

本実施の形態に従う商品取引システムにおける処理の概要を説明するための図である。 本実施の形態に従う商品取引システムにおける処理手順の一例を説明するための図である。 本実施の形態に従う商品取引システムを構成する運営サーバの構成例を示す模式図である。 本実施の形態に従う商品取引システムにおけるマッチング処理の要部を示す模式図である。 本実施の形態に従う商品取引システムを構成する買い手の端末上に提供されるユーザインターフェイス画面の一例を示す模式図である。 本実施の形態に従う商品取引システムを構成する供給者の端末上に提供されるユーザインターフェイス画面の一例を示す模式図である。 本実施の形態に従う商品取引システムを構成する買い手の端末上に提供されるユーザインターフェイス画面の一例を示す模式図である。 本実施の形態に従う商品取引システムの運営サーバによる買い手に関する情報の管理方法を説明するための図である。 本実施の形態に従う商品取引システムの運営サーバによる供給者に関する情報の管理方法を説明するための図である。 本実施の形態に従う商品取引システムにおいて利用される配送費定義の一例を示す図である。 本実施の形態に従う商品取引システムにおいて利用される配送費定義の別の一例を示す図である。 本実施の形態に従う商品取引システムの運営サーバにおける処理手順を示すフローチャートである。 本実施の形態に従う商品取引システムの運営サーバにおける処理手順を示すフローチャートである。 本実施の形態に従う商品取引システムを構成する買い手の端末上に提供されるユーザインターフェイス画面の別の一例を示す模式図である。 本実施の形態に従う商品取引システムを構成する供給者の端末上に提供されるユーザインターフェイス画面の別の一例を示す模式図である。

本開示に係る実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。

＜Ａ．商品取引システム１＞
まず、本実施の形態に従う商品取引システム１について説明する。商品取引システム１は、生産者と買い手との間で直接的な商品の取引をも可能とするプラットフォームを提供する。

図１は、本実施の形態に従う商品取引システム１における処理の概要を説明するための図である。図１を参照して、商品取引システム１は、任意の商品の購入を希望する１または複数の買い手１０と、任意の商品の提供を希望する１または複数の供給者２０とのいずれからもアクセス可能な運営サーバ１００を含む。すなわち、商品取引システム１は、買い手１０と供給者２０との間の商品取引を電子的に行う。

買い手１０の各々は、購入を希望する任意の商品および数を特定するための情報、ならびに、その購入希望価格を含む購入要求１２を運営サーバ１００へ送信する。また、供給者２０の各々は、販売を希望する任意の商品および数を特定するための情報、ならびに、その販売希望価格を含む販売要求２２を運営サーバ１００へ送信する。

運営サーバ１００は、１または複数の買い手１０からの購入要求１２と、１または複数の供給者２０からの販売要求２２とを比較して、購入要求１２と販売要求２２とが合致するか否かを判断する（以下、「マッチング処理」とも称す。）。そして、購入要求１２と販売要求２２とが合致すると、取引成立と決定する。

運営サーバ１００は、取引成立と決定された販売要求２２に対応する供給者２０に対して、取引成立の旨を通知するとともに、取引の対象になった商品を買い手１０へ配送する。なお、商品の配送については、供給者２０自身が行ってもよいが、典型的には、任意の配送者３０が行ってもよい。

運営サーバ１００は、後述するように、買い手１０と供給者２０との間の決済処理も担当する。

商品取引システム１において取り扱われる商品としては、特に制限はないが、日用品や消耗品などの繰り返しの購入が想定されているものが好適である。

買い手１０は、典型的には、対象の商品を最終的に使用する個人が想定されるが、これに限らず、例えば、継続的に商品を使用することが予定される店舗や事業所などであってもよい。さらに、買い手１０は、コンピュータや演算機能を備えたデバイスであってもよい。このように、買い手１０は、商品の取引に関して何らかの意思決定が可能な任意の主体を包含する概念である。

供給者２０は、任意の商品を提供可能であればどのような主体であってもよいが、典型的には、任意の商品の生産者あるいは輸入者が好適である。あるいは、供給者２０は、任意の商品を保管または管理する物流会社であってもよい。さらに、供給者２０は、コンピュータや演算機能を備えたデバイスであってもよい。このように、供給者２０は、買い手１０と同様に、商品の取引に関して何らかの意思決定が可能な任意の主体を包含する概念である。

このように、本実施の形態に従う商品取引システム１は、従来のビジネスモデルにおいては存在しなかった、生産者と買い手との間で直接的な商品の取引をも可能とするプラットフォームを提供する。

図２は、本実施の形態に従う商品取引システム１における処理手順の一例を説明するための図である。図２には、買い手１０が特定の商品を注文して、任意の供給者２０との間で取引が成立し、当該供給者２０から商品が提供される場合の処理例を示す。

図２を参照して、買い手１０は、特定の商品を注文するための操作を行うと、購入要求１２が運営サーバ１００へ送信される（ステップＳ１）。運営サーバ１００は、買い手１０から特定の商品の購入希望価格を含む購入要求１２を受け付ける。そして、運営サーバ１００は、当該買い手１０の残高から、買い手１０からの購入要求１２に含まれる購入希望価格および購入希望個数に基づいて決定される購入予定額をリザーブ（予約）する（ステップＳ２）。

一方、供給者２０は、特定の商品を販売するための操作を行うと、販売要求が運営サーバ１００へ送信される（ステップＳ３）。運営サーバ１００は、供給者２０から特定の商品の販売希望価格を含む販売要求２２を受け付ける。

運営サーバ１００は、買い手１０からの購入要求１２と供給者２０からの販売要求２２との間でマッチング処理を実行する（ステップＳ４）。このマッチング処理において、いずれかの買い手１０からの購入要求１２といずれかの供給者２０からの販売要求２２との間で取引が成立すると、運営サーバ１００は、取引成立の通知を買い手１０および供給者２０へそれぞれ送信する（ステップＳ５）。

供給者２０は、取引成立の通知を受けて、取引の対象となった商品を発送する（ステップＳ６）。また、供給者２０は、取引の対象となった商品の発送に伴って、当該発送された商品をトラッキングするためのトラッキング情報を運営サーバ１００を介して買い手１０へ送信する。トラッキング情報を買い手１０および供給者２０ならびに運営サーバ１００で共有することとによって、商品が確実に配送されることを保証できる。

買い手１０は、供給者２０からの商品を受け取ると（ステップＳ７）、商品受取通知を運営サーバ１００へ送信する（ステップＳ８）。運営サーバ１００は、買い手１０からの商品受取通知を受けると、予めリザーブしていた購入予定額を供給者２０の口座へ入金する（ステップＳ９）。

以上のような処理手順によって、商品取引システム１における商品の取引が完了する。

以下、本実施の形態に従う商品取引システム１の構成、機能および処理の詳細について説明する。

＜Ｂ．ハードウェア構成＞
次に、本実施の形態に従う商品取引システム１のハードウェア構成の一例について説明する。

（ｂ１：運営サーバ１００）
図３は、本実施の形態に従う商品取引システム１を構成する運営サーバ１００の構成例を示す模式図である。典型的には、運営サーバ１００は、１または複数の汎用コンピュータを用いて実現される。

図３を参照して、運営サーバ１００は、主たるコンポーネントとして、１または複数のプロセッサ１０１と、メインメモリ１０２と、通信インターフェイス１０３と、入力部１０４と、ディスプレイ１０５と、ストレージ１１０とを含む。これらのコンポーネントは、内部バス１０６を介して接続されている。

プロセッサ１０１は、例えば、ＣＰＵやＧＰＵ（Graphics Processing Unit）などで構成される。複数のプロセッサ１０１が配置されてもよいし、複数のコアを有するプロセッサ１０１を採用してもよい。

メインメモリ１０２は、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などの揮発性記憶装置で構成される。ストレージ１１０は、ハードディスクやＳＳＤ（Solid State Drive）などの不揮発性記憶装置で構成され、プロセッサ１０１で実行される各種プログラムや各種データを保持する。ストレージ１１０に格納されたプログラムのうち、指定されたプログラムコードがメインメモリ１０２上に展開され、プロセッサ１０１は、メインメモリ１０２上に展開されたプログラムコードに含まれるコンピュータ可読命令を順次実行することで、後述するような各種機能を実現する。

典型的には、ストレージ１１０は、マッチング処理を実現するためのマッチングプログラム１１２と、決済処理を実現するための決済プログラム１１４と、要求キュー１１６と、買い手１０および供給者２０に関する各種情報を含むユーザ情報１１８とを格納している。要求キュー１１６は、１または複数の買い手１０からの１または複数の購入要求１２、および、１または複数の供給者２０からの１または複数の販売要求２２を一時的に保持する。

マッチングプログラム１１２および決済プログラム１１４は、コンピュータに買い手１０と供給者２０との間の商品取引を実行させるための商品取引プログラムに相当する。

通信インターフェイス１０３は、買い手１０および供給者２０の端末などとデータ交換を担当する。通信インターフェイス１０３は、例えば、インターネットを介した通信ができるように、イーサネット（登録商標）ポートを含んでいてもよい。

入力部１０４は、任意の入力指示を受け付ける。ディスプレイ１０５は、プロセッサ１０１での処理結果などを表示する。

運営サーバ１００の全部または一部は、コンピュータ可読命令に相当する回路が組み込まれたＡＳＩＣ（Application Specific Integrated Circuit）などのハードワイヤード回路を用いて実現してもよい。さらにあるいは、ＦＰＧＡ（field-programmable gate array）上にコンピュータ可読命令に相当する回路を用いて実現してもよい。また、プロセッサ１０１およびメインメモリ、ＡＳＩＣ、ＦＰＧＡなどを適宜組み合わせて実現してもよい。

運営サーバ１００は、コンピュータ可読命令からなるマッチングプログラム１１２および決済プログラム１１４を格納する非一過性（non-transitory）のメディアから、当該格納しているプログラムなどを読み出すためのコンポーネントをさらに有していてもよい。メディアは、例えば、ＤＶＤ（Digital Versatile Disc）などの光学メディア、ＵＳＢメモリなどの半導体メディアなどであってもよい。

マッチングプログラム１１２および決済プログラム１１４は、メディアを介して運営サーバ１００にインストールされるだけではなく、ネットワーク上の配信サーバから提供されるようにしてもよい。

（ｂ２：買い手１０および供給者２０の端末）
買い手１０および供給者２０は、任意の端末を利用して、商品取引システム１を利用できる。買い手１０および供給者２０が利用する端末は、パーソナルコンピュータ、スマートフォン、タブレット、携帯電話などの任意の情報処理装置を包含する。

後述するような買い手１０および供給者２０に提供される機能は、端末に予めインストールされたアプリケーションによって実現されてもよいし、運営サーバ１００が提供するユーザインターフェイスを端末のブラウザを介して利用するようにしてもよい。

買い手１０および供給者２０に提供されるユーザインターフェイスを含めた各種機能は、どのようなハードウェア構成およびソフトウェア構成を用いて実現してもよい。

＜Ｃ．マッチング処理＞
次に、本実施の形態に従う商品取引システム１におけるマッチング処理について説明する。

（ｃ１：購入要求１２および販売要求２２）
本実施の形態に従う商品取引システム１においては、供給者２０から買い手１０へ商品を配送するために必要な配送費を考慮してマッチング処理を行うようにしてもよい。すなわち、商品取引システム１の運営サーバ１００は、供給者２０から買い手１０までの特定の商品を配送するための配送費を反映した上で、購入要求１２と販売要求２２とがマッチングするか否かを判断する。この配送費の考慮にあたっては、買い手１０と供給者２０との間の距離を考慮してもよい。

図４は、本実施の形態に従う商品取引システム１におけるマッチング処理の要部を示す模式図である。

図４を参照して、買い手１０からの購入要求１２は、購入希望価格１２２および配送費１２３を含む購入希望総額１２１と、購入希望個数１２４と、配送先情報１２５とを含む。購入要求１２は、システム利用料１２６をさらに含んでいてもよい。システム利用料１２６は、買い手１０が商品取引システム１を利用するにあたっての利用料金であり、典型的には、購入希望価格１２２または購入希望総額１２１に対して所定率（例えば、１．０％）を乗じた額が自動的に算出されてもよい。

すなわち、運営サーバ１００は、マッチングした購入要求１２と販売要求２２とに基づく商品取引が完了すると、購入要求１２に対応する買い手１０の口座からシステム利用料１２６を徴収するようにしてもよい。

なお、配送費１２３については、商品１個ごとに算出されてもよいし、複数の商品に対して一括して算出されてもよい。また、配送先情報１２５については、必ずしも購入要求１２に含める必要はなく、運営サーバ１００に予め格納されたユーザ情報１１８を利用するようにしてもよい。

買い手１０は、特定の商品の購入を希望する場合には、購入希望個数１２４に加えて、購入希望価格１２２を指定、あるいは、購入希望価格１２２および配送費１２３を含む購入希望総額１２１を指定する。これによって、買い手１０の端末が購入要求１２を生成し、運営サーバ１００へ送信する。

一方、供給者２０からの販売要求２２は、販売希望価格２２２および配送費２２３を含む販売希望総額２２１と、販売希望個数２２４と、配送費定義２２５とを含む。販売要求２２において、買い手１０の配送先情報１２５に基づいて、配送費定義２２５から配送費２２３が算出されてもよい。

供給者２０は、特定の商品の販売を希望する場合には、販売希望価格２２２および販売希望個数２２４を指定する。これによって、供給者２０の端末が販売要求２２を生成し、運営サーバ１００へ送信する。運営サーバ１００は、購入先の候補である買い手１０ごとに、販売要求２２における配送費２２３を算出あるいは評価する。

運営サーバ１００は、１または複数の買い手１０からの購入要求１２の購入希望総額１２１と、１または複数の供給者２０からの販売要求２２の販売希望総額２２１とを比較して、互いの条件が合致するか否か（マッチングするか否か）を判断する。あるいは、運営サーバ１００は、１または複数の買い手１０からの購入要求１２の購入希望価格１２２と、１または複数の供給者２０からの販売要求２２の販売希望価格２２２とを比較して、互いの条件が合致するか否か（マッチングするか否か）を判断する。

なお、マッチング処理においては、一方が不利な条件にならなければ、他方が有利な条件で取引成立と決定してもよい。例えば、買い手１０がある商品の購入希望価格１２２を「１００円」に設定していたところ、供給者２０が当該商品の販売希望価格２２２を「９０円」に設定したとする。この場合、買い手１０の希望する購入希望価格１２２を「９０円」に変更した上で、取引成立と決定してもよい。この場合には、買い手１０は、購入希望価格１２２より「１０円」安く商品を購入できるので、有利な条件での取引となる。

逆に、供給者２０の希望する販売希望価格２２２を「１００円」に変更した上で、取引成立と決定してもよい。この場合には、供給者２０は、販売希望価格２２２より「１０円」安く商品を購入できるので、有利な条件での取引となる。

さらに、買い手１０の希望する購入希望価格１２２を「９５円」に変更するとともに、供給者２０の希望する販売希望価格２２２を「９５円」に変更した上で、取引成立と決定してもよい。この場合には、買い手１０および供給者２０の両方にとって、当初に比較して有利な条件での取引となる。

また、個数については、一部の条件のみが合致するような場合であっても、取引を成立させてもよいし、すべての個数についての条件が合致しなければ取引を成立させてもよい。例えば、購入要求１２の購入希望個数１２４が販売要求２２の販売希望個数２２４より少ない場合には、買い手１０は、購入希望個数１２４で指定された個数の一部だけを購入できることになる。買い手１０が許容する場合には、このような指定された個数の一部のみについて取引が成立するようにしてもよい。

（ｃ２：ユーザインターフェイス画面）
次に、本実施の形態に従う商品取引システム１において提供されるユーザインターフェイス画面の一例について説明する。

図５は、本実施の形態に従う商品取引システム１を構成する買い手１０の端末上に提供されるユーザインターフェイス画面３００の一例を示す模式図である。図５を参照して、ユーザインターフェイス画面３００は、購入要求１２を生成するための買い手１０からの指示を受け付ける。

より具体的には、ユーザインターフェイス画面３００は、買い手１０が購入を希望する商品の画像を示す商品表示部３０２と、購入を希望する商品を検索するための検索ボタン３０４と、購入を希望する商品を特定するための識別情報を読み取るためのコード読取ボタン３０６とを含む。

買い手１０は、検索ボタン３０４を選択して、商品名または商品を特定するコードなどを入力することで、購入を希望する商品を検索できる。あるいは、買い手１０は、コード読取ボタン３０６を選択して、端末に実装されているカメラなどで購入を希望する商品に付されているバーコードやＱＲコード（登録商標）を読み取ることで、購入を希望する商品を指定できる。

このように検索あるいは指定された商品を示す画像などが商品表示部３０２に表示される。

なお、商品名または識別情報に基づく商品の検索、ならびに、商品の画像の検索などを行うために、運営サーバ１００の内部あるいは外部に、商品管理用のデータベースを配置してもよい。

買い手１０は、購入を希望する商品を指定すると、購入希望価格および購入希望個数を入力する。より具体的には、ユーザインターフェイス画面３００は、個数入力ボックス３１０および価格入力ボックス３１４を含む。

買い手１０は、購入希望個数を個数入力ボックス３１０に入力するとともに、購入希望価格を価格入力ボックス３１４に入力する。

個別単位（１個単位）またはケース単位のいずれかを選択するための単位選択ラジオボタン３１２の選択状態に応じて、個数入力ボックス３１０に入力される購入希望個数は、個別単位およびケース単位のいずれかに設定される。

配送費込または配送費別のいずれかを選択するための配送費選択ラジオボタン３１６の選択状態に応じて、価格入力ボックス３１４に入力される購入希望価格は、配送費込の価格および配送費別の価格のいずれかに設定される。配送費選択ラジオボタン３１６が配送費込に選択されていれば、価格入力ボックス３１４に入力される価格は購入希望総額１２１を意味することになり、配送費選択ラジオボタン３１６が配送費別に選択されていれば、価格入力ボックス３１４に入力される価格は購入希望価格１２２を意味することになる。

さらに、ユーザインターフェイス画面３００は、購入希望個数の一部の個数についてのみ条件が合致した場合に、当該条件が合致した個数についてのみ取引成立として処理するか否かを設定するチェックボタン３１８を含む。チェックボタン３１８が選択されることで、購入希望個数の一部分についてのみ取引が成立することが許容される。

図５に示すようなユーザインターフェイス画面３００を介して、購入要求１２が生成される。

図６は、本実施の形態に従う商品取引システム１を構成する供給者２０の端末上に提供されるユーザインターフェイス画面の一例を示す模式図である。図６を参照して、ユーザインターフェイス画面４００は、販売要求２２を生成するための供給者２０からの指示を受け付ける。

より具体的には、ユーザインターフェイス画面４００は、供給者２０が販売可能な商品の一覧を示すリスト４０２を含む。リスト４０２は、供給者２０が販売可能な各商品を特定するための商品コードを示す商品コード欄４０４と、各商品の商品名を示す商品名欄４０６と、各商品の販売希望価格を示す販売価格欄４０８と、各商品の販売希望個数を示す販売個数欄４１０と、各商品の販売希望個数のうち取引が未だ成立していない個数を示す残り個数欄４１２と、購入希望販売の一部の個数についてのみ条件が合致した場合に、当該条件が合致した個数についてのみ取引成立として処理するか否かを設定する一部取引欄４１４とを含む。

供給者２０は、販売可能な商品をリスト４０２に登録するとともに、各商品について、販売希望価格（販売価格欄４０８）および販売希望価格（販売個数欄４１０）を入力する。

供給者２０は、検索ボタン４１６を選択して、商品名または商品を特定するコードなどを入力することで、販売可能な商品を検索してリスト４０２に登録できる。あるいは、供給者２０は、コード読取ボタン４１８を選択して、端末に実装されているカメラなどで購入を希望する商品に付されているバーコードやＱＲコードを読み取ることで、販売可能な商品をリスト４０２に登録できる。

供給者２０は、内容変更ボタン４２０を選択して、リスト４０２に登録されている販売希望価格（販売価格欄４０８）および販売希望価格（販売個数欄４１０）を任意に変更できる。供給者２０が変更した内容は、更新ボタン４２２が選択されることで反映される。

図６に示すようなユーザインターフェイス画面４００を介して、販売要求２２が生成される。

図７は、本実施の形態に従う商品取引システム１を構成する買い手１０の端末上に提供されるユーザインターフェイス画面３２０の一例を示す模式図である。図７を参照して、ユーザインターフェイス画面３２０は、運営サーバ１００に受け付けられている購入要求１２および販売要求２２の状況を示す。より具体的には、ユーザインターフェイス画面３２０は、対象の商品の画像を示す商品表示部３２２と、取引状況を示す状況表示部３３０とを含む。

状況表示部３３０には、１または複数の買い手１０からの購入要求１２による購入希望価格および購入希望個数を示す購入要求状況表示部３３２と、１または複数の買い手１０からの販売要求２２による販売希望価格および販売希望個数を示す販売要求状況表示部３３４とを含む。状況表示部３３０においては、購入要求１２と販売要求２２とが対比可能な状態で表示されており、買い手１０および供給者２０は、状況表示部３３０を参照して、新たな購入要求１２あるいは販売要求２２を生成する場合や、既に生成している購入要求１２あるいは販売要求２２の内容を更新する。

ユーザインターフェイス画面３２０の状況表示部３３０は、典型的には、運営サーバ１００の要求キュー１１６（図３）に一時的に保持されている購入要求１２および販売要求２２の内容に基づいて生成される。

（ｃ３：ユーザ管理）
次に、商品取引システム１の運営サーバ１００におけるユーザ管理について説明する。

図８は、本実施の形態に従う商品取引システム１の運営サーバ１００による買い手１０に関する情報の管理方法を説明するための図である。図８を参照して、運営サーバ１００は、買い手１０の各々を管理するための管理情報１５０を有している。

管理情報１５０は、買い手１０の配送先（住所あるいは緯度経度）を示す配送先情報１５２を含む。管理情報１５０に含まれる配送先情報１５２は、購入要求１２の配送先情報１２５として利用されてもよい。但し、買い手１０の端末に実装されるＧＰＳ（Global Positioning System）などからの位置情報を用いて、購入要求１２の配送先情報１２５を都度生成するようにしてもよい。この場合には、必ずしも、配送先情報１５２を管理情報１５０に含めておく必要はない。

管理情報１５０は、買い手１０の口座の残高を示す残高情報１５４を含む。残高情報１５４は、買い手１０および供給者２０の各々が保有する経済的価値を管理する口座を具現化したものである。経済的価値としては、特定の通貨での金額が想定されているが、仮想通貨のようなものであってもよいし、商品取引システム１において利用される独自ポイントであってもよい。

運営サーバ１００は、買い手１０が購入要求１２を生成すると、対応する残高情報１５４から、購入要求１２に基づいて決定される購入予定額をリザーブ（予約）する。すなわち、運営サーバ１００は、購入要求１２に含まれる購入希望価格に基づいて決定される価値を対応する買い手１０の口座から予約する。

管理情報１５０は、買い手１０の取引情報を示す購入履歴１５６を含む。運営サーバ１００は、取引が成立するたびに購入履歴１５６の内容を更新する。なお、運営サーバ１００は、買い手１０が購入要求１２を生成するたびに、その内容を残高情報１５４に反映するようにしてもよい。

図９は、本実施の形態に従う商品取引システム１の運営サーバ１００による供給者２０に関する情報の管理方法を説明するための図である。図９を参照して、運営サーバ１００は、供給者２０の各々を管理するための管理情報２５０を有している。

管理情報２５０は、供給者２０の口座の残高を示す残高情報２５４を含む。運営サーバ１００は、いずれかの買い手１０と供給者２０との間で取引が成立すると、当該取引によって遣り取りされる金額が対応する残高情報２５４に加算される。

管理情報２５０は、供給者２０の取引情報を示す販売履歴２５６を含む。運営サーバ１００は、取引が成立するたびに販売履歴２５６の内容を更新する。

運営サーバ１００は、図８に示される管理情報１５０および図９に示される管理情報２５０を用いて、取引に関する買い手１０および供給者２０の情報を管理する。

（ｃ４：配送費算出）
次に、配送費（購入要求１２に含まれる配送費１２３および販売要求２２に含まれる配送費２２３）の算出方法の一例について説明する。

図１０は、本実施の形態に従う商品取引システム１において利用される配送費定義２２６の一例を示す図である。図１０に示す配送費定義２２６は、商品ごと（図１０の例では「商品Ａ」）に配送費を定義する。配送費定義２２６においては、買い手１０と供給者２０との間の距離を区分（区分１〜５）して、区分ごとに配送費が定義される。購入要求１２または販売要求２２において配送費の算出が必要な場合には、買い手１０の配送先情報および配送費定義２２６を参照して、配送費が決定される。

図１０に示される配送費定義２２６は、販売要求２２の配送費定義２２５として利用されてもよい。

図１１は、本実施の形態に従う商品取引システム１において利用される配送費定義２２７の別の一例を示す図である。図１１に示す配送費定義２２７は、基本的にはすべての商品に対して配送費を定義する。配送費定義２２７においては、買い手１０と供給者２０との間の距離を区分（区分１〜５）して、区分ごとに配送費が定義される。

いずれかの商品について配送費の算出が必要な場合には、商品ごとの重量を示す重量テーブル２２８を参照して、各商品についての重量が決定され、当該決定された重量を配送費定義２２７に適用することで、配送費が決定される。

なお、図１０および図１１には、買い手１０と供給者２０との間の距離を区分して、各区分について配送費が定義されている例を示したが、これに限らず、単位距離（例えば、１ｋｍ）あたりに配送費を定義するようにしてもよい。さらに、国内用および海外用の配送費定義をそれぞれ規定してもよい。

以上のように、本実施の形態に従う商品取引システム１においては、上述したような配送費定義を利用することで、必要な配送費を算出できる。すなわち、運営サーバ１００は、供給者２０または特定の商品に関連付けられた配送費定義と、買い手１０と供給者２０との間の距離とに基づいて、当該特定の商品を配送するための配送費を算出するようにしてもよい。

（ｃ５：処理手順）
次に、商品取引システム１の運営サーバ１００における処理手順の一例について説明する。図１２および図１３は、本実施の形態に従う商品取引システム１の運営サーバ１００における処理手順を示すフローチャートである。図１２および図１３には、買い手１０と供給者２０との間の商品取引をコンピュータが実行する商品取引方法が示される。

図１２および図１３に示す各ステップは、典型的には、運営サーバ１００のプロセッサ１０１がマッチングプログラム１１２および決済プログラム１１４（商品取引プログラムに相当）を実行することで実現される。

図１２および図１３を参照して、運営サーバ１００は、買い手１０の端末からの購入要求１２または供給者２０からの販売要求２２を受信したか否かを判断する（ステップＳ１００）。買い手１０の端末からの購入要求１２または供給者２０からの販売要求２２を受信していれば（ステップＳ１００においてＹＥＳ）、運営サーバ１００は、受信した購入要求１２または販売要求２２を要求キュー１１６に格納する（ステップＳ１０２）。

このように、運営サーバ１００は、買い手１０から特定の商品の購入希望価格を含む購入要求１２を受け付ける処理、および、供給者２０から特定の商品の販売希望価格を含む販売要求２２を受け付ける処理を実行する。

続いて、運営サーバ１００は、受信した要求が購入要求１２であるか否かを判断する（ステップＳ１０４）。受信した要求が購入要求１２であれば（ステップＳ１０４においてＹＥＳ）、運営サーバ１００は、当該受信した購入要求１２に含まれる購入希望価格および購入希望個数に基づいて決定される購入予定額が、購入要求１２を送信した買い手１０の口座に存在するか否かを判断する（ステップＳ１０６）。

購入予定額が買い手１０の口座に存在していれば（ステップＳ１０６においてＹＥＳ）、運営サーバ１００は、買い手１０の口座から購入予定額をリザーブ（予約）する（ステップＳ１０８）。そして、ステップＳ１１０以下のマッチング処理が実行される。

購入予定額が買い手１０の口座に存在していなければ（ステップＳ１０６においてＮＯ）、運営サーバ１００は、ステップＳ１１０以下のマッチング処理を実行しない。この際、運営サーバ１００は、購入要求１２を生成できない旨を買い手１０の端末に通知してもよい。

受信した要求が販売要求２２であれば（ステップＳ１０４においてＮＯ）、ステップＳ１０６およびＳ１０８の処理はスキップされる。

買い手１０の端末からの購入要求１２または供給者２０からの販売要求２２を受信していなければ（ステップＳ１００においてＮＯ）、運営サーバ１００は、買い手１０の端末から購入要求１２の変更または供給者２０から販売要求２２の変更を受信したか否かを判断する（ステップＳ１０９）。買い手１０の端末から購入要求１２の変更または供給者２０から販売要求２２の変更を受信していれば（ステップＳ１００においてＹＥＳ）、ステップＳ１１０以下のマッチング処理が実行される。

買い手１０の端末から購入要求１２の変更および供給者２０から販売要求２２の変更のいずれも受信していなければ（ステップＳ１００においてＮＯ）、ステップＳ１００以下の処理が繰り返される。

このように、購入要求１２もしくは販売要求２２が要求キュー１１６に追加されたとき、または、要求キュー１１６に保持されている購入要求１２もしくは販売要求２２が変更されたときに、購入要求１２と販売要求２２とがマッチングするか否かを判断する処理が実行される。

買い手１０の端末から購入要求１２の変更および供給者２０から販売要求２２の変更を受信していなければ（ステップＳ１００においてＮＯ）、ステップＳ１００以下の処理が繰り返される。

運営サーバ１００は、新たに受信または更新された要求が購入要求１２および販売要求２２のいずれであるかを判断する（ステップＳ１１０）。

新たに受信または更新された要求が購入要求１２であれば（ステップＳ１１０において「購入要求」）、運営サーバ１００は、当該新たに受信または更新された購入要求１２をマッチング対象の購入要求１２に設定し（ステップＳ１１２）、要求キュー１１６に格納されている販売要求２２のうち１つをマッチング候補として選択する（ステップＳ１１４）。

続いて、運営サーバ１００は、マッチング対象の購入要求１２またはマッチング候補の販売要求２２について配送費の算出が必要であるか否かを判断する（ステップＳ１１６）。マッチング対象の購入要求１２またはマッチング候補の販売要求２２について配送費の算出が必要であれば（ステップＳ１１６においてＹＥＳ）、運営サーバ１００は、買い手１０の配送先を示す情報（配送先情報１２５または配送先情報１５２）と、配送費に関する情報（配送費定義２２５または配送費定義２２６）とに基づいて、必要な配送費（配送費１２３または配送費２２３）を決定する（ステップＳ１１８）。

このように、運営サーバ１００は、供給者２０から買い手１０までの特定の商品を配送するための配送費を反映した上で、購入要求１２と販売要求２２とがマッチングするか否かを判断する。

一方、マッチング対象の購入要求１２またはマッチング候補の販売要求２２について配送費の算出が必要でなければ（ステップＳ１１６においてＮＯ）、ステップＳ１１８の処理はスキップされる。

そして、運営サーバ１００は、マッチング対象の購入要求１２とマッチング候補の販売要求２２とを比較して、互いの条件が合致するか否かを判断する（ステップＳ１２０）。

マッチング対象の購入要求１２とマッチング候補の販売要求２２との間で、互いの条件が合致すれば（ステップＳ１２０においてＹＥＳ）、運営サーバ１００は、取引成立と決定し、対象の購入要求１２および販売要求２２にそれぞれ対応する買い手１０および供給者２０に通知し（ステップＳ１２２）、対象の購入要求１２および販売要求２２を、対象の商品の配送完了待ちのステータスに変更する（ステップＳ１２４）。そして、マッチング処理は終了する。

マッチング対象の購入要求１２とマッチング候補の販売要求２２との間で、互いの条件が合致しなければ（ステップＳ１２０においてＮＯ）、運営サーバ１００は、要求キュー１１６に格納されているすべての販売要求２２についてマッチング処理が完了したか否かを判断する（ステップＳ１２６）。要求キュー１１６に格納されている販売要求２２のうちマッチング処理が行われていないものがあれば（ステップＳ１２６においてＮＯ）、運営サーバ１００は、未だマッチング処理が行われていない１つの販売要求２２をマッチング候補として選択し（ステップＳ１２８）、ステップＳ１１６以下の処理を繰り返す。

一方、要求キュー１１６に格納されているすべての販売要求２２についてマッチング処理が完了していれば（ステップＳ１２６においてＹＥＳ）、運営サーバ１００は、互いの条件が合致する購入要求１２と販売要求２２とが見つからなかった判断し、マッチング処理を終了する。

一方、新たに受信または更新された要求が販売要求２２であれば（ステップＳ１１０において「販売要求」）、運営サーバ１００は、当該新たに受信または更新された販売要求２２をマッチング対象の販売要求２２に設定し（ステップＳ１３２）、要求キュー１１６に格納されている購入要求１２のうち１つをマッチング候補として選択する（ステップＳ１３４）。

続いて、運営サーバ１００は、マッチング対象の販売要求２２またはマッチング候補の購入要求１２について配送費の算出が必要であるか否かを判断する（ステップＳ１３６）。マッチング対象の販売要求２２またはマッチング候補の購入要求１２について配送費の算出が必要であれば（ステップＳ１３６においてＹＥＳ）、運営サーバ１００は、買い手１０の配送先を示す情報（配送先情報１２５または配送先情報１５２）と、配送費に関する情報（配送費定義２２５または配送費定義２２６）とに基づいて、必要な配送費（配送費１２３または配送費２２３）を決定する（ステップＳ１３８）。

このように、運営サーバ１００は、供給者２０から買い手１０までの特定の商品を配送するための配送費を反映した上で、購入要求１２と販売要求２２とがマッチングするか否かを判断する。

一方、マッチング対象の販売要求２２またはマッチング候補の購入要求１２について配送費の算出が必要でなければ（ステップＳ１３６においてＮＯ）、ステップＳ１３８の処理はスキップされる。

そして、運営サーバ１００は、マッチング対象の販売要求２２とマッチング候補の購入要求１２とを比較して、互いの条件が合致するか否かを判断する（ステップＳ１４０）。

マッチング対象の販売要求２２とマッチング候補の購入要求１２との間で、互いの条件が合致すれば（ステップＳ１４０においてＹＥＳ）、運営サーバ１００は、取引成立と決定し、対象の販売要求２２および購入要求１２にそれぞれ対応する供給者２０および買い手１０に通知し（ステップＳ１４２）、対象の販売要求２２および購入要求１２を、対象の商品の配送完了待ちのステータスに変更する（ステップＳ１４４）。そして、マッチング処理は終了する。

マッチング対象の販売要求２２とマッチング候補の購入要求１２との間で、互いの条件が合致しなければ（ステップＳ１４０においてＮＯ）、運営サーバ１００は、要求キュー１１６に格納されているすべての購入要求１２についてマッチング処理が完了したか否かを判断する（ステップＳ１４６）。要求キュー１１６に格納されている購入要求１２のうちマッチング処理が行われていないものがあれば（ステップＳ１４６においてＮＯ）、運営サーバ１００は、未だマッチング処理が行われていない１つの購入要求１２をマッチング候補として選択し（ステップＳ１４８）、ステップＳ１３６以下の処理を繰り返す。

一方、要求キュー１１６に格納されているすべての購入要求１２についてマッチング処理が完了していれば（ステップＳ１４６においてＹＥＳ）、運営サーバ１００は、互いの条件が合致する販売要求２２と購入要求１２とが見つからなかった判断し、マッチング処理を終了する。

＜Ｄ．商品管理＞
本実施の形態に従う商品取引システム１における商品管理の一例について説明する。

（ｄ１：識別情報）
商品取引システム１において取り扱われる商品は、パッケージなどに付される識別情報を用いて特定されてもよい。このような識別情報としては、例えば、ＪＡＮ（Japanese Article Number）コード、ＥＡＮ（European Article Number）コード、ＧＴＩＮ−１３、ＧＴＩＮ−８などの商品識別番号を用いてもよい。このような商品識別番号を用いることで、複数の国の間で流通する商品についても取り扱いを容易化できる。

さらに、集合包装用の識別情報を用いるようにしてもよい。集合包装用の識別情報は、企業間の取引単位である集合包装（ケース、ボール、パレットなど）に対し設定される商品識別番号を包含する。このような集合包装用の識別情報としては、ＧＴＩＮ−１４などの集合包装用商品コードが知られている。集合包装用商品コードは、集合包装された個々の商品についての商品識別番号を含むので、商品取引システム１においては、個々の商品を取り扱うこともできるとともに、それらを集合させた状態で取り扱うこともできる。

なお、集合包装用商品コードは、ＩＴＦ（Inter-Leaved two of Five）シンボルなどのバーコードシンボルとして具現化できる。

上述したような個別の商品を示す識別情報および集合包装用の識別情報を併用することで、商品の特性や供給者２０の事情に応じたより柔軟な取引を実現できる。

（ｄ２：メタ商品）
本実施の形態に従う商品取引システム１においては、同一種類の複数の商品をまとめて１つの商品として取り扱うようにしてもよい。このような商品を「メタ商品」とも称す。

例えば、「水」については、様々な商品が提供されているが、買い手１０の一部は、特定の生産者および商品を特定することまでは行わず、単に「水」を購入したいと希望するものも存在する。

そこで、例えば、「１リットルのＰＥＴ容器に入った水」といった商品を特定せず、包括的な商品種別を規定するメタ商品を規定してもよい。

このようなメタ商品にいずれの商品が含まれるのかという対応付け情報を運営サーバ１００に保持しておくことで、買い手１０は、「１リットルのＰＥＴ容器に入った水」（いずれの商品かは問わない）を注文できる。

一方、供給者２０は、メタ商品が要求する商品種別に該当さえすれば、任意の商品を提供できるので、在庫処分などをより容易に行うことができる。

なお、各メタ商品にどのような商品を含めるのかについては、運営サーバ１００側で管理してもよいし、各メタ商品に含ませることのできる条件を明示して、当該条件に従って供給者２０側でメタ商品として販売するようにしてもよい。運営サーバ１００側でメタ商品を管理する場合には、メタ商品を示す商品識別番号と、当該メタ商品に含まれる特定の１または複数の商品の各々を示す商品識別番号とを対応付けるテーブルを保持するようにしてもよい。

このように、メタ商品を利用可能にすることで、より柔軟な商品の取引を実現できる。

＜Ｅ．購入要求１２および販売要求２２のバリエーション＞
上述の説明においては、購入要求１２に含まれる購入希望総額１２１（購入希望価格１２２および配送費１２３を含む）と、販売要求２２に含まれる販売希望総額２２１（販売希望価格２２２および配送費２２３を含む）とを比較するマッチング処理について例示したが、これに限らず、購入要求１２および販売要求２２については、追加の条件を含めるようにしてもよい。以下、いくつかのバリエーションについて説明する。

（ｅ１：価格指定オプション）
図５および図６には、ユーザが具体的な購入希望価格または販売希望価格を入力する例を示すが、これに限らず、取引状況（図７など参照）に応じた価格を指定できるようにしてもよい。

図１４は、本実施の形態に従う商品取引システム１を構成する買い手１０の端末上に提供されるユーザインターフェイス画面３００の別の一例を示す模式図である。図１４に示すユーザインターフェイス画面３００においては、価格入力ボックス３１４に「現在の最安値」が指定されている例を示す。

購入要求１２の「現在の最安値」は、図７に示す取引状況において、取引が成立してない販売要求２２に含まれる販売希望総額２２１あるいは販売希望価格２２２のうち最安値を意味する。このような購入希望価格として「現在の最安値」が指定されると、購入希望個数を満たすだけの販売希望個数が存在していれば、即座に取引が成立することになる。

逆に、販売要求２２を生成する際に「現在の最高値」を指定するようにしてもよい。この場合には、図７に示す取引状況において、取引が成立してない購入要求１２に含まれる購入希望総額１２１あるいは購入希望価格１２２のうち最高値を意味する。このような販売希望価格として「現在の最高値」が指定されると、販売希望個数を満たすだけの購入希望個数が存在していれば、即座に取引が成立することになる。

さらに、「現在の最安値」あるいは「現在の最高値」という指定に加えて、「現在の最安値から５円高」あるいは「現在の最高値から５円安」といった指定なども可能である。

なお、上述した例に限らず、購入希望価格および販売希望価格については、任意の形態で指定できるようにしてもよい。

上述したような購入希望価格および販売希望価格についての価格指定オプションを充実化することで、買い手１０および供給者２０は、取引状況に応じた柔軟な取引を楽しむことができる。

（ｅ２：集合包装オプション）
上述したように、供給者２０は、商品を取引単位でまとめた集合包装の形（例えば、１２個の商品が１つの段ボールにパッケージされているような形態）で買い手１０に提供する場合も多い。このような場合、集合包装を１単位として販売することもできるし、集合包装に含まれる個々の商品を販売することもできる。

このようなニーズに対して、販売要求２２を生成する際には、集合包装を１単位でのみ販売するのか、あるいは、集合包装に含まれる商品を個々に販売することを許容するのかを選択できるようにしてもよい。

図１５は、本実施の形態に従う商品取引システム１を構成する供給者２０の端末上に提供されるユーザインターフェイス画面の別の一例を示す模式図である。供給者２０は、図１５に示すようなユーザインターフェイス画面４００において、取引単位で集合包装された商品については、集合包装を１単位でのみ販売するのか、あるいは、集合包装に含まれる商品を個々に販売することを許容するのかについての選択を受け付けるようにしてもよい（個別販売欄４２４）。

運営サーバ１００は、このような集合包装についての供給者２０の要望を考慮して、購入要求１２と販売要求２２との間の条件の合致を判断する。

なお、集合包装を１単位として販売する場合と、集合包装を個々の商品にばらして販売する場合との間で、配送費を異ならせてもよい。通常、集合包装を１単位として販売する場合に比較して、集合包装を個々の商品にばらして販売する場合の配送費はより高額に設定される。このような異なる配送費を設定することで、集合包装を１単位として販売することのインセンティブを高めることができる。

（ｅ３：有効期限オプション）
買い手１０および供給者２０は、取引が成立するまでは、購入要求１２および販売要求２２をそれぞれ任意に取り消しあるいは撤回できるようにしてもよい。さらに、商品の特性によっては、特定に期限までに購入または販売しなければならない場合もある。

このようなニーズを考慮して、購入要求１２および販売要求２２について有効期限を設定するようにしてもよい。より具体的には、買い手１０および供給者２０は、任意の購入要求１２および販売要求２２を生成したときに、取引が成立しなければ、要求を取り消しあるいは撤回する期限（有効期限の条件）を付加できるようにしてもよい。

運営サーバ１００は、有効期限が指定された購入要求１２および販売要求２２については、指定された有効期限が到来しても取引が成立していなければ、対応する購入要求１２または販売要求２２を強制的に取り消す。このような有効期限の条件を購入要求１２または販売要求２２に付加することで、時期に遅れて取引が成立してしまうような事態を回避できる。

有効期限の指定方法としては、特定の日付、特定の日時、今日中、今週中、今月中などの任意の方法を採用してもよい。

（ｅ４：在庫有無オプション）
供給者２０は特定の商品を常時供給することが予定されているが、何からの事情で一時的に商品を供給できない状況になっている可能性もある。このような場合、商品が入荷次第、商品は買い手１０へ配送されることになるが、商品入荷まで待たされることになる。

そこで、買い手１０が購入要求１２を生成する際に、指定した商品の在庫の有無を条件として追加するようにしてもよい。より具体的には、供給者２０が在庫を有している場合に限って取引を成立させるのか、あるいは、供給者２０が在庫を有していなくても取引を成立させるのかを買い手１０が選択できるようにしてもよい。

供給者２０が在庫を有している場合に限って取引を成立させることが条件とされている場合には、指定された商品が供給者２０の在庫として存在している場合に限って、取引が成立することになる。

一方、供給者２０が在庫を有していなくても取引を成立させることが指定されている場合には、供給者２０に対象の商品が入荷するまでの時間などを買い手１０に提示するようにしてもよい。

（ｅ５：配送開始期限オプション）
買い手１０は何らかの商品をなるべく早く手に入れたいと考えている場合もある。そこで、買い手１０が購入要求１２を生成する際に、指定した商品が供給者２０から配送されるまでの期限を条件として追加するようにしてもよい。より具体的には、買い手１０は、取引が成立してから商品が配送されるまでの時間（例えば、取引成立から６時間以内など）、あるいは、商品を配送すべき期限（例えば、１０月１日１５時など）を指定できるようにしてもよい。

このような条件が付加された購入要求１２が生成された場合には、運営サーバ１００は、供給者２０からの配送可能時刻などの情報の提供を受けて、購入要求１２と販売要求２２との間で条件が合致するか否かを判断する。

（ｅ６：配送可能範囲オプション）
供給者２０の事業規模によっては、商品を配送できる範囲が制限される場合がある。このような配送範囲の制限を考慮して、供給者２０が販売要求２２を生成する際に、商品を配送可能な範囲を予め指定するようにしてもよい。より具体的には、供給者２０は、商品を配送可能な範囲（例えば、日本国内のみ、５００ｋｍ否かなど）を指定できるようにしてもよい。

このような条件が付加された販売要求２２が生成された場合には、運営サーバ１００は、買い手１０の配送先情報（買い手１０の位置を示す情報）を参照して、購入要求１２と販売要求２２との間で条件が合致するか否かを判断する。

なお、買い手１０が購入要求１２を生成する際に、供給者２０が予め指定している配送可能範囲の条件に合致しないことが明らかである場合には、買い手１０に対して、条件に合致しない販売要求２２を隠すようにしてもよい。

（ｅ７：資格確認）
取引される商品（例えば、アルコール類、タバコ、薬など）によっては、買い手１０が所定の資格を有していることを確認する必要がある。そのため、運営サーバ１００は、買い手１０の属性情報（年齢など）を予め保持しておき、属性情報も参照して、購入要求１２と販売要求２２との間で条件が合致するか否かを判断するようにしてもよい。

買い手１０の属性情報については、買い手１０が運転免許証を写した画像などを予め運営サーバ１００へ送信し、その送信された画像に基づいて、当該買い手１０の属性情報を生成するようにしてもよい。

このような買い手１０の資格を確認することで、適性かつ適法な取引を実現できる。

（ｅ８：ボリュームディスカウント）
商品取引システム１における商品の取引において、所定数を超える商品が購入される場合には、商品の価格を下げるようにしてもよい。この場合には、供給者２０が販売要求２２を生成する際に、商品の販売数と割引率（ディスカウント率）を条件として追加するようにしてもよい。

運営サーバ１００は、マッチング処理において、指定された販売数以上の商品の取引が成立した場合には、指定された割引率に従って商品の価格を決定してもよい。

＜Ｆ．その他の形態＞
（ｆ１：口座）
商品取引システム１においては、国際的な商品の取引も可能であり、このような場合には、ユーザの口座は、特定の通貨（例えば、日本円や米国ドルなど）で統一してもよいし、複数の通貨からユーザが特定の通貨を選択するようにしてもよい。異なる通貨の口座間で取引が行われる場合には、取引時の為替レートを考慮して、口座間で代金が遣り取りされてもよい。

あるいは、任意の仮想通貨を用いて各ユーザの口座を管理するようにしてもよい。共通の仮想通貨を用いることで、為替レートに基づく変換処理などを省略できる。

（ｆ２：分散配置）
上述の説明においては、運営サーバ１００がマッチング処理および決済処理を実行する例を示すが、それぞれの処理を異なるサーバに実装してもよいし、複数の運営サーバ１００を用いて実装してもよい。例えば、国ごとまたは地域ごとに運営サーバ１００を用意するとともに、運営サーバ１００同士を連携することで、国際的な商品の取引を実現できる。

＜Ｇ．利点＞
本実施の形態に従う商品取引システム１によれば、買い手１０および供給者２０がそれぞれ購入要求１２および販売要求２２を生成し、運営サーバ１００が購入要求１２と販売要求２２との間のマッチングを判断する。そして、マッチングしたと判断されると、供給者２０から買い手１０に対して商品が配送されるとともに、商品の配送完了に応じて、代金が供給者２０の口座へ移される。このような電子的な売買の仕組みを導入することで、生産者と買い手１０との間で直接的な商品の取引も可能となる。

今回開示された実施の形態はすべての点で例示であって制限的なものでないと考えられるべきである。本発明の範囲は上記した説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ 商品取引システム、１０ 買い手、１２ 購入要求、２０ 供給者、２２ 販売要求、３０ 配送者、１００ 運営サーバ、１０１ プロセッサ、１０２ メインメモリ、１０３ 通信インターフェイス、１０４ 入力部、１０５ ディスプレイ、１０６ 内部バス、１１０ ストレージ、１１２ マッチングプログラム、１１４ 決済プログラム、１１６ 要求キュー、１１８ ユーザ情報、１２１ 購入希望総額、１２２ 購入希望価格、１２３，２２３ 配送費、１２４ 購入希望個数、１２５，１５２ 配送先情報、１２６ システム利用料、１５０，２５０ 管理情報、１５４，２５４ 残高情報、１５６ 購入履歴、２２１ 販売希望総額、２２２ 販売希望価格、２２４ 販売希望個数、２２５，２２６，２２７ 配送費定義、２２８ 重量テーブル、２５６ 販売履歴、３００，３２０，４００ ユーザインターフェイス画面、３０２，３２２ 商品表示部、３０４，４１６ 検索ボタン、３０６，４１８ ボタン、３１０ 個数入力ボックス、３１２ 単位選択ラジオボタン、３１４ 価格入力ボックス、３１６ 配送費選択ラジオボタン、３１８ チェックボタン、３３０ 状況表示部、３３２ 購入要求状況表示部、３３４ 販売要求状況表示部、４０２ リスト、４０４ 商品コード欄、４０６ 商品名欄、４０８ 販売価格欄、４１０ 販売個数欄、４１２ 残り個数欄、４１４ 一部取引欄、４２０ 内容変更ボタン、４２２ 更新ボタン、４２４ 個別販売欄。

Claims (7)

1. 買い手と供給者との間の商品取引を行うための商品取引システムであって、
   前記買い手から特定の商品の購入希望価格を含む購入要求を受け付ける第１の受付手段と、
   前記供給者から前記特定の商品の販売希望価格を含む販売要求を受け付ける第２の受付手段と、
   前記供給者から前記買い手までの前記特定の商品を配送するための配送費を反映した上で、前記購入要求と前記販売要求とがマッチングするか否かを判断する判断手段とを備える、商品取引システム。
2. １または複数の前記購入要求、および、１または複数の前記販売要求を一時的に保持するための要求キューをさらに備え、
   前記判断手段は、前記購入要求もしくは前記販売要求が前記要求キューに追加されたとき、または、前記要求キューに保持されている前記購入要求もしくは前記販売要求が変更されたときに、前記購入要求と前記販売要求とがマッチングするか否かを判断する、請求項１に記載の商品取引システム。
3. 前記供給者または前記特定の商品に関連付けられた配送費定義と、前記買い手と前記供給者との間の距離とに基づいて、前記特定の商品を配送するための配送費を算出する算出手段をさらに備える、請求項１または２に記載の商品取引システム。
4. 前記買い手および前記供給者の各々が保有する経済的価値を管理する口座をさらに備え、
   前記第１の受付手段は、前記購入要求に含まれる購入希望価格に基づいて決定される価値を対応する買い手の口座から予約する、請求項１〜３のいずれか１項に記載の商品取引システム。
5. マッチングした購入要求と販売要求とに基づく商品取引が完了すると、当該購入要求に対応する買い手の口座から利用料を徴収する手段をさらに備える、請求項４に記載の商品取引システム。
6. 買い手と供給者との間の商品取引をコンピュータが実行する商品取引方法であって、
   前記買い手から特定の商品の購入希望価格を含む購入要求を受け付けるステップと、
   前記供給者から前記特定の商品の販売希望価格を含む販売要求を受け付けるステップと、
   前記供給者から前記買い手までの前記特定の商品を配送するための配送費を反映した上で、前記購入要求と前記販売要求とがマッチングするか否かを判断するステップとを備える、商品取引方法。
7. コンピュータに買い手と供給者との間の商品取引を実行させるための商品取引プログラムであって、前記商品取引プログラムは前記コンピュータに、
   前記買い手から特定の商品の購入希望価格を含む購入要求を受け付けるステップと、
   前記供給者から前記特定の商品の販売希望価格を含む販売要求を受け付けるステップと、
   前記供給者から前記買い手までの前記特定の商品を配送するための配送費を反映した上で、前記購入要求と前記販売要求とがマッチングするか否かを判断するステップとを実行させる、商品取引プログラム。

Images