JP2004070526A - 取引管理サーバ、取引管理プログラムおよび記録媒体 - Google Patents

Abstract

【課題】取引に不慣れな購入者であっても、信頼のおける生産者から生鮮商品を購入することができる取引管理サーバ、プログラムおよび記録媒体を提供する。
【解決手段】取引管理サーバは、セラー管理データベースを備え、このセラー管理データベースには、セラーごとに、取引上の信頼度を示す情報として、取引システム運営者が実際に調査して評価した評価結果と、実際に生鮮食品を購入したバイヤーによる評価とから算出された価格適正度が記録されている。従って、購入者は発注するものを選択する際に、生産者の信頼度を考慮することができる。
【選択図】　　　図３

Description

【０００１】
【発明の属する技術分野】
本発明は、青果物や鮮魚などの生鮮商品を生産する生産者と、当該生鮮商品を購入する購入者との間の取引を管理するための取引管理サーバ、取引管理プログラムおよび記録媒体に関する。
【０００２】
【従来の技術】
従来から、第１次産業生産物である青果物などを生鮮商品とした卸売取引が全国各地に点在する卸売市場で行われている。この卸売取引にあっては、生産者が競売日時までに生鮮商品を卸売市場に出荷する一方、購入者が現物商品を観察してから、買付けに参加し、これにより、生産者と購入者との間で卸売取引が行われている。しかしながら、近年、小売商業の巨大企業化が進み、青果物などの生鮮商品を中心に大企業による仕入量が巨大化し、卸売流通分野での顧客としての発言権が増大した結果、一企業による早期取引や、生鮮商品の大量希望量の確保、生鮮商品価格の相対取引化などといった、事実上、先物取引が習慣化されるようになっている。このため、卸売現物市場としての競売による公正な価格形成が機能しなくなり、仕入量の少ない購入者に対して不利益が生じるといった問題がある。
【０００３】
この問題を解決するものとして、特開平９−１７５３１号公報には、生鮮商品の先物通信入札による自動電算卸売競売システムが示されている。この自動電算卸売競売システムにあっては、生産者から提供される出荷前の先物取引情報（希望販売価格や数量など）が管理されており、購入者は、この先物取引情報に基づいて競売入札する生鮮商品を決定し、その情報をホスト電算機へ送信することで、購入者間で競売が行われ生鮮商品が取引される。これにより、生産者は、生鮮商品の販売価格を所望の価格に設定しつつ、安定した販売が可能となると共に、購入者は、大企業に独占されることなく生鮮商品を購入することが可能となる。
【０００４】
【発明が解決しようとする課題】
しかしながら、一般的に、取引に不慣れな購入者は、生産者が信頼できるか否かを、生産者が提示する先物取引情報だけから判断するのは困難であり、このため、粗悪な生鮮商品を高値で購入してしまう恐れがある。
【０００５】
本発明は、上述した事情に鑑みてなされたものであり、取引に不慣れな購入者であっても、信頼のおける生産者から生鮮商品を購入することができる取引管理サーバ、取引管理プログラムおよび記録媒体を提供することを目的とする。
【０００６】
【課題を解決するための手段】
上記目的を達成するために、本発明は、生産者が所有する第１の通信端末、および、当該生産者が生産する生産物を購入する購入者が所有する第２の通信端末の各々と通信網を介して通信する取引管理サーバにおいて、生産者と、当該生産者が生産する生産物の情報とを対応付けて記憶する第１の記憶手段と、生産者の取引上の信頼度を生産者ごとに記憶する第２の記憶手段と、購入者が所望する生産物の条件を、前記第２の通信端末から受信する第１の受信手段と、受信した条件に従って前記第１の記憶手段を検索し、該当する生産物の情報を読み出すと共に、当該生産物の情報に対応付けられた生産者の信頼度を前記第２の記憶手段から読み出す読出手段と、読み出された生産物の情報および生産者の信頼度を前記第２の通信端末に送信する第１の送信手段と、生産物の発注のための情報であり、前記第１の送信手段により送信された前記生産物の情報のうち、購入者が発注すべく選択した生産物の情報を識別する情報を含む発注情報を前記第２の通信端末から受信する第２の受信手段と、前記発注情報から生産者を特定すると共に、当該生産者が所有する第１の通信端末に対して、前記発注情報を送信する第２の送信手段とを備える取引管理サーバを提供する。
【０００７】
この取引管理サーバによれば、購入者には、検索条件に該当する生産物の情報に加え、当該生産物を生産する生産者の取引上の信頼度も合わせて提供される。
従って、購入者は、検索条件に該当した生産物の中から、発注するものを選択する際に、生産者の信頼度を考慮することができ、これにより、取引に不慣れな購入者であっても、信頼のおける生産者から生産物を購入することが可能となる。
【０００８】
また、上記目的を達成するために、本発明は、生産者が所有する第１の通信端末、および、当該生産者が生産する生産物を購入する購入者が所有する第２の通信端末の各々と通信網を介して通信するコンピュータを、生産者と、当該生産者が生産する生産物の情報とを対応付けて記憶する手段、生産者の取引上の信頼度を生産者ごとに記憶する手段、購入者が所望する生産物の条件を、前記第２の通信端末から受信する手段、受信した条件に従って前記第１の記憶手段を検索し、該当する生産物の情報を読み出すと共に、当該生産物の情報に対応付けられた生産者の信頼度を前記第２の記憶手段から読み出す手段、読み出された生産物の情報および生産者の信頼度を前記第２の通信端末に送信する手段、生産物の発注のための情報であり、前記第１の送信手段により送信された前記生産物の情報のうち、購入者が発注すべく選択した生産物の情報を識別する情報を含む発注情報を前記第２の通信端末から受信する手段、および、前記発注情報から生産者を特定すると共に、当該生産者が所有する第１の通信端末に対して、前記発注情報を送信する手段として機能させるための取引管理プログラムを提供する。
なお、この取引管理プログラムの取引の態様は、光ディスクや光磁気ディスク、磁気ディスクなどの各種記録媒体に記録されて取引される態様であっても良く、また、インターネットなどの電気通信回線を通じて取引される態様であっても良い。
【０００９】
【発明の実施の形態】
以下、図面を参照して、本件発明の実施の形態について説明する。
図１は、本発明の実施形態に係る取引システム１の構成を示す概念図である。
この取引システム１にあっては、青果物などの陸地で栽培される第１次産業生産物が生鮮商品として生産者（以下、単に「セラー」と称する）と購入者（以下、「バイヤー」と称する）との間で取引される。ここで、セラーとしては、青果物の生産者個人の他、生産者団体などが該当し、また、バイヤーとしては、取引量の大口、小口を問わず、例えば生鮮商品小売店や生鮮商品の加工メーカ、飲食店、食料品メーカ、スーパーなどが該当する。
【００１０】
さて、図１において、セラー端末２０は、セラーが所有する通信端末であり、バイヤー端末３０は、バイヤーが所有する通信端末である。セラー端末２０およびバイヤー端末３０は、いずれもインターネット２を介して、このインターネット２に接続された端末と通信する装置であり、例えば、パーソナルコンピュータなどの据置型の通信端末や、ノート型パーソナルコンピュータなどの携帯型の通信端末などである。取引管理サーバ１０は、セラーとバイヤーとの間での生鮮商品の取引を中枢的に管理する機能を備えたサーバコンピュータであり、インターネット２を介して、セラー端末２０およびバイヤー端末３０の各々と通信する。
【００１１】
ここで、本実施形態に係る取引システム１は、国際的な取引を扱うシステムであり、セラーとバイヤーとは、互いに異なる国に在住している。以下の説明では、セラーが在住する国を生産国４と称し、また、バイヤーが在住する国を購入国５と称することにする。生産国４から購入国５への生鮮所品の輸送の際には、貨物コンテナ６に生鮮商品が荷詰され、航空機や船などで輸送されることになる。
【００１２】
なお、図１には、取引管理サーバ１０が購入国５に設置されている場合が例示されているが、どの国に取引管理サーバ１０を設置するかは任意である。また、本実施形態では、通信網としてインターネット２を例示するが、これに限らず、任意の通信ネットワークが用いることができ、また、通信プロトコルは、通信網に応じて決定されれば良い。例えば、通信網としてインターネットが用いられる場合には、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）が用いられる。但し、本実施形態に係る取引システム１は、商取引に関するものであるため、ＨＴＴＰが使用される場合には、ＳＳＬ（Ｓｅｃｕｒｅ　Ｓｏｃｋｅｔｓ　Ｌａｙｅｒ）の組み込みによってセキュリティ機能が通信プロトコルに付加されることが望ましい。
また、本実施形態に係る取引システム１は、図１に示されている各通信端末２０、３０および取引管理サーバ１０の他にも、決済機関が所有する通信端末や、輸出業者が所有する通信端末、輸入業者が所有する通信端末、輸入時の検品を実施する機関が所有する通信端末、通関手続をする機関が所有する通信端末といった、国際取引に必要とされる業者が所有する通信端末を備えており、これらの通信端末と取引管理サーバ１０とがインターネット２を介して互いに通信し、取引の決済処理や生鮮商品の輸出入処理などの各種処理が行われるようになっている。
【００１３】
次いで、取引管理サーバ１０の構成について詳述する。図２は、取引管理サーバ１０の機能的構成を示すブロック図である。この図において、制御部１００は、ＣＰＵなどの演算手段、および、ＲＯＭやＲＡＭ等の記憶手段を備え、各部の制御や各種演算、データの一時的格納等を行う。通信インターフェース（以下、「通信Ｉ／Ｆ」と称する）１０２は、インターネット２に接続された各種通信端末との間で通信データを授受するものである。具体的に説明すると、通信Ｉ／Ｆ１０２は、インターネット２を介してセラー端末２０またはバイヤー端末３０から受信した通信データを制御部１００に出力する一方で、制御部１００からの通信データをセラー端末２０またはバイヤー端末３０に送信する。記憶部１２０〜１２８の各々は、各種プログラムや各種データベースを記憶するものであり、例えばハードディスクドライブなどから構成される。
【００１４】
記憶部１２０は、制御部１００が各部を制御するための制御プログラムや、セラーとバイヤーとの間での生鮮商品の取引を中枢的に管理する機能を、この取引管理サーバ１０に実現させるための取引管理プログラムを記憶している。さらに、記憶部１２０は、この他にも、ＷＷＷ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）サーバの機能を実現するためのＷＷＷサーバプログラムと、例えばＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）などのマークアップ言語で記述されたホームページとを記憶している。
ホームページとしては、例えば、セラー登録時に用いられるセラー登録ページ４００（図８参照）や、バイヤー登録時に用いられるバイヤー登録ページ４１０（図１１参照）などがある。
【００１５】
次いで、記憶部１２２は、セラーを集中的に管理するためのセラー管理データベース１２２０を記憶している。このセラー管理データベース１２２０は、図３に示すように、セラーテーブル１２２０ａとセラー実績テーブル１２２０ｂとを備えるリレーショナルデータベースである。セラーテーブル１２２０は、各セラーの氏名や連絡先などの基本情報を管理するためのものであり、１件のレコードには、セラー毎に割り当てられた識別情報であるセラーＩＤと、このセラーの氏名（会社にあっては名称）と、住所や電話番号などの連絡先と、電子メールアドレスと、セラーの認証に使用されるパスワードとが含まれている。一方、セラー実績テーブル１２２０ｂは、バイヤーに対してセラーの取引上の信頼性を示すべく、各セラーの取引実績を管理するためのものである。この取引実績として、本実施形態では、価格適正度が用いられている。
【００１６】
価格適正度は、セラーが販売価格として、生鮮商品の品質に見合った価格を過去にどれだけ付けたかを示す指標であり、この価格適正度が高い程（本実施形態では、５段階に評価）、セラーが提示する販売価格が生鮮商品の品質に見合っていた事を示す。この価格適正度は、この取引システム１を運営する会社などが実際に調査して評価した評価結果と、実際に生鮮商品を購入したバイヤーによる評価とから算出されている。ここで、セラーが過去に一度も取引をしていない場合には、価格適正度には、評価値の代わりに、新規セラーであることを示す「新規」が記入される。なお、本実施形態では、セラー実績として価格適正度が用いられる場合を例示するが、セラー実績としては、セラーの取引上の信頼性を、バイヤーなどの第三者に対して示すことのできる指標であれば任意のものを用いることができる。
【００１７】
記憶部１２４は、取引の対象となる生鮮商品を集中的に管理するための商品管理データベース１２４０を記憶している。商品管理データベース１２４０は、図４に示すように、品目テーブル１２４０ａと、商品登録データテーブル１２４０ｂと、輸入テーブル１２４０ｃとを備えている。品目テーブル１２４０ａは、取引システム１にて取引される生鮮商品の品目と、この品目を識別するための品目ＩＤとを対応付けるものである。また、商品登録テーブル１２４０ｂは、セラーによって登録された生鮮商品の情報を管理するためのものである。輸入テーブル１２４０ｃは、商品登録テーブル１２４０ｂの各レコードごとに、生鮮商品の輸入に関する情報を管理するためのものである。
【００１８】
より具体的に説明すると、商品登録テーブル１２４０ｂの１件のレコードには、セラー登録商品ＩＤと、セラーＩＤと、品目ＩＤと、原産地と、規格と、パッケージ容量と、出荷予定数と、販売価格と、出荷港と、船便名とが含まれている。セラー登録商品ＩＤは、セラーによって登録された生鮮商品を一意に識別するためのものである。生産地は、生鮮商品を栽培した地域名などを示すものであり、また、規格は、従来から青果物に対して慣用的に用いられている等級などを示すものである。パッケージ容量は、１つのパッケージに含まれる生鮮商品の数量を示すものであり、生鮮商品は、パッケージ単位で販売される。出荷予定数は、出荷予定日までに生産・出荷される予定の数量であり、パッケージの何個分かで示されている。生椎茸を例にすると、１つのパッケージ容量が５ｋｇであり、かつ、生産予定数が５００ｋｇであれば、出荷予定数量は、１００（＝５００／５）となる。次いで、販売価格は、セラーが提示するパッケージあたりの価格である。出荷港は、この生鮮商品が出荷される港を示し、船便名は、生鮮商品が輸送される船の船便名を示す。
【００１９】
また、輸入テーブル１２４０ｃの１件のレコードには、セラー登録商品ＩＤと、到着港と、港到着予定日と、コンテナ荷詰容量とが含まれている。到着港は、購入国５のどの港に、生鮮商品が到着するかを示す。また、港到着予定日は、生鮮商品が到着港に到着する予定日を示す。ここで、到着港と港到着予定日との各々は、セラーが指定するのではなく、出荷港と船便名とから、制御部１００が特定するようになっている。具体的には、取引管理サーバ１０は、出荷港ごとに、この出荷港を出港する船便名と、この船便の到着港および到着日時が対応付けられたテーブル（不図示）を備え、このテーブルを検索することで、到着港と港到着予定日とを特定する。次いで、コンテナ荷詰容量は、輸送時に使用される１個の貨物コンテナに、生鮮商品のパッケージが何個分詰めるかを示すものである。
【００２０】
上述のように、登録商品データテーブル１２４０ｂには、取引対象となる生鮮商品の情報が登録されており、バイヤーは、この登録商品データテーブル１２４０ｂを検索して、生鮮商品を発注するセラーを選択する。具体的には、図１７に例示する商品検索用ページ４３０が記憶部１２０に記憶されており、バイヤーは、この商品検索用ページ４３０に検索条件を入力して生鮮商品を検索する。この検索については、後に詳述する。
【００２１】
次いで、図２に示す記憶部１２６は、バイヤーを集中的に管理するためのバイヤー管理データベース１２６０を記憶している。図５に示すように、バイヤー管理テーブル１２６０の１件のレコードには、バイヤー毎に割り当てられた識別情報であるバイヤーＩＤと、このバイヤーの氏名（会社にあっては名称）と、住所や電話番号などの連絡先と、電子メールアドレスと、バイヤーの認証に使用されるパスワードとが含まれている。
【００２２】
記憶部１２８は、バイヤーの発注状況およびセラーの納品状況といった取引状況を管理するための取引管理データベース１２８０を記憶している。また、この取引管理データベース１２８０は、各バイヤーから発注された生鮮商品のパッケージの総個数が貨物コンテナの荷詰容量の所定値（例えば９割など）以上、コンテナ荷詰容量以下となるように、各バイヤーの発注を取りまとめるためにも使用される。
【００２３】
より具体的に説明すると、取引管理データベース１２８０の１件のレコードには、各発注を一意に識別するための発注ＩＤと、発注元であるバイヤーのバイヤーＩＤと、発注先であるセラーのセラーＩＤと、発注された生鮮商品の品目ＩＤと、発注数量と、取りまとめＩＤと、出荷チェックフラグとが含まれている。発注数量は、バイヤーが発注するパッケージの個数を示す。取りまとめＩＤは、この発注が他の発注と取りまとめられた場合に、その取りまとめ発注を一意に識別するためのものである。
【００２４】
例えば、発注ＩＤが「ＨＡ００１」、「ＨＡ００９」および「ＨＡ０１３」の３つの発注を例にすると、これらの発注を取りまとめれば、発注されるパッケージの総個数が１貨物コンテナの荷詰容量の所定値（例えば、荷詰容量の９割など）以上、荷詰容量以下となる。そこで、これらの発注ＩＤに対して、取りまとめＩＤとして「ＴＯＲＩ００１」が付与されると共に、各発注が一括してセラーに対して発注される。また、１つの発注の発注個数のみで貨物コンテナの荷詰数量の所定値をこえ、かつ、荷詰容量以下になる場合（例えば「ＨＡ００２」）には、その発注は、他の発注と取りまとめられずにセラーに対して発注される。但し、この場合、他の発注との取りまとめが行われていないが、セラーに対してなされた発注を一意に識別するために、便宜上取りまとめＩＤが付与される。すなわち、取りまとめＩＤが付与されている発注は、セラーに対して発注されたことを示す。
出荷チェックフラグは、発注した生鮮商品が出荷港より出荷されたか否かを示すものであり、未だ出荷されていない場合には、「０」が記入され、また、出荷が完了している場合には、「１」が記入される。
【００２５】
次いで、本実施形態に係る取引システム１の動作について説明する。この取引システム１において、セラーおよびバイヤーの各々は、取引管理サーバ１０に予め自己を登録する。先ず、この登録について説明する。
【００２６】
セラー登録は、セラーがセラー端末２０から取引管理サーバ１０のセラー登録ページ４００（図８参照）にアクセスし、各種情報を入力することにより行われる。具体的には、図７に示すように、先ず、セラー端末２０は、取引管理サーバ１０に対してセラー登録ページ４００の表示データの送信を取引管理サーバ１０に要求する（ステップＳａ１）。取引管理サーバ１０の制御部１００は、この送信要求を受信すると（ステップＳａ２）、記憶部１２０からセラー登録ページ４００の表示データを読出し（ステップＳａ３）、通信Ｉ／Ｆ１０２を介してセラー端末２０に送信する（ステップＳａ４）。セラー端末２０は、このセラー登録ページ４００の表示データを受信すると（ステップＳａ５）、このセラー登録ページ４００を表示部に表示する（ステップＳａ６）。
【００２７】
図８に示すように、セラー登録ページ４００には、セラー管理データベース１２２０のセラーテーブル１２２０ａ（図３参照）に記録すべき情報を、セラーに入力させるためのセラー名記入欄４００ａと、連絡先記入欄４００ｂと、電子メールアドレス記入欄４００ｃと、パスワード登録欄４００ｄとが設けられている。セラーがセラー端末２０の操作部を操作などして、各欄４００ａ〜４００ｄに情報を入力した後に、セラー登録ページ４００に設けられた送信ボタン４００ｅをクリックすると、セラー端末２０は、係る操作を検出し、セラーによって入力された情報をセラー情報として取得し（ステップＳａ７）、取引管理サーバ１０に送信する（ステップＳａ８）。
【００２８】
取引管理サーバ１０の制御部１００は、セラー情報を受信すると（ステップＳａ９）、このセラー情報を一意に識別するための、すなわち、セラーを一意に識別するためのセラーＩＤを生成する（ステップＳａ１０）。次いで、制御部１００は、セラー管理データベース１２２０のセラーテーブル１２２０ａにセラー情報に対応するレコードを追加すべく、１件のレコードを生成し、セラーテーブル１２２０ａに追加する（ステップＳａ１１）。そして、制御部１００は、ステップＳａ１０において生成したセラーＩＤをセラー端末２０に送信する（ステップＳａ１２）。より具体的には、制御部１００は、セラーＩＤが示されたセラー登録完了ページ４０２（図９参照）の表示データを生成し、このセラー登録完了ページ４０２の表示データをセラー端末２０に送信する。そして、セラー端末２０がセラー登録終了ページ４０２の表示データ、すなわち、セラーＩＤを受信する（ステップＳａ１３）ことにより、セラーの登録が完了する。
【００２９】
次いで、バイヤー登録について説明する。バイヤー登録もセラー登録と同様に、バイヤーがバイヤー端末３０から取引管理サーバ１０のバイヤー登録ページ４１０（図１１参照）にアクセスして、各種情報を入力することにより行われる。
具体的には、図１０に示すように、バイヤー端末３０は、取引管理サーバ１０に対してバイヤー登録ページ４１０の表示データの送信を取引管理サーバ１０に要求する（ステップＳｂ１）。取引管理サーバ１０の制御部１００は、この送信要求を受信すると（ステップＳｂ２）、記憶部１２０からバイヤー登録ページ４１０の表示データを読出し（ステップＳｂ３）、バイヤー端末３０に送信する（ステップＳｂ４）。バイヤー端末３０は、このバイヤー登録ページ４１０の表示データを受信すると（ステップＳｂ５）、バイヤー登録ページ４１０を表示部に表示する（ステップＳｂ６）。
【００３０】
図１１に示すように、バイヤー登録ページ４１０には、バイヤー管理データベース１２６０（図５参照）に記録すべき情報を、バイヤーに入力させるためのバイヤー名記入欄４１０ａと、連絡先記入欄４００ｂと、電子メールアドレス記入欄４００ｃと、パスワード記入欄４００ｄとが設けられている。バイヤーがバイヤー端末３０の操作部を操作などして、各欄４１０ａ〜４１０ｄに情報を入力した後に、バイヤー登録ページ４１０に設けられた送信ボタン４１０ｅをクリックすると、バイヤー端末３０は、係る操作を検出し、入力された情報をバイヤー情報として取得して（ステップＳｂ７）、取引管理サーバ１０に送信する（ステップＳｂ８）。
【００３１】
取引管理サーバ１０の制御部１００は、バイヤー情報を受信すると（ステップＳｂ９）、このバイヤー情報を一意に識別するためのＩＤ、すなわち、バイヤーを一意に識別するためのバイヤーＩＤを生成する（ステップＳｂ１０）。次いで、制御部１００は、バイヤー管理データベース１２６０にバイヤー情報に対応するレコードを追加すべく、１件のレコードを生成し、バイヤー管理データベース１２６０に追加する（ステップＳｂ１１）。そして、制御部１００は、ステップＳｂ１０において生成したバイヤーＩＤが示されたバイヤー登録完了ページ４１２（図１２参照）の表示データを生成して、バイヤー端末３０に送信する（ステップＳｂ１２）。そして、バイヤー端末３０がバイヤー登録完了ページ４１２、の表示データ、すなわち、バイヤーＩＤを受信する（ステップＳａ１３）ことにより、バイヤーの登録が完了する。
【００３２】
次いで、セラーが生鮮商品を取引管理サーバ１０に登録する場合の処理動作について説明する。生鮮商品の登録は、セラーがセラー端末２０から取引管理サーバ１０の生鮮商品登録ページ４２０（図１４参照）にアクセスし、各種情報を入力することにより行われる。具体的には、図１３に示すように、先ず、セラー端末２０は、取引管理サーバ１０に対して生鮮商品登録ページ４２０の表示データの送信を取引管理サーバ１０に要求する（ステップＳｃ１）。取引管理サーバ１０の制御部１００は、この送信要求を受信すると（ステップＳｃ２）、生鮮商品登録ページ４２０の表示データの送信に先立って、セラーに対して認証を行うべく、セラー端末２０にセラーＩＤとパスワードとを要求する（ステップＳｃ３）。セラー端末２０は、係る要求を受信すると、このセラー端末２０の使用者（セラー）に対して、セラーＩＤとパスワードとの入力を促した後、入力されたセラーＩＤとパスワードとを認証情報として取得し（ステップＳｃ４）、取引管理サーバ１０へ送信する（ステップＳｃ５）。
【００３３】
取引管理サーバ１０の制御部１００は、認証情報を受信すると、この認証情報が正当か否かの認証処理を実行する（ステップＳｃ６）。具体的には、制御部１００は、認証情報により示されるセラーＩＤを検索キーとして、セラーテーブル１２２０ａに登録されている各レコードを検索し、該当するレコードに登録されているパスワードと、ステップＳｃ６において受信したパスワードとを比較して、認証処理を行う。そして、パスワードが正当でないと判断された場合、制御部１００は、セラー端末２０にエラー通知を送信し（ステップＳｃ７）、処理を終了する。すなわち、セラーが生鮮商品を登録する場合には、ステップＳｃ１に示す処理から再度実行されることになる。この認証処理により、第三者によるセラーへの成りすましが防止される。
【００３４】
一方、ステップＳｃ６における認証処理の結果、パスワードが正当であると判断された場合には、制御部１００は、記憶部１２０から生鮮商品登録ページ４２０の表示データを読出し（ステップＳｃ８）、セラー端末２０に送信する（ステップＳｃ９）。セラー端末２０は、このセラー登録ページ４２０の表示データを受信すると（ステップＳｃ１０）、生鮮商品登録ページ４２０を表示部に表示する（ステップＳｃ１１）。
【００３５】
図１４に示すように、生鮮商品登録ページ４２０には、商品登録テーブル１２４０ｂ（図４参照）に登録すべき情報をセラーに入力させるための品目入力欄４２０ａと、原産地入力欄４２０ｂと、規格入力欄４２０ｃと、出荷予定数入力欄４２０ｄと、販売価格入力欄４２０ｅと、出荷港入力欄４２０ｆと、船便名入力欄４２０ｇとが設けられている。ここで、パッケージ容量を取得すべく、出荷予定数入力欄４２０ｄには、パッケージ容量×個数にて表される出荷予定数が入力される。セラーは、操作部を操作するなどして生鮮商品登録ページ４２０に、登録する生鮮商品の情報を入力し、送信ボタン４２０ｈをクリックする。セラー端末２０は、係る操作を検出すると、入力された情報をセラーの生鮮商品登録情報として取得し（ステップＳｃ１２）、取引管理サーバ１０に送信する（ステップＳｃ１３）。
【００３６】
取引管理サーバ１０の制御部１００は、生鮮商品登録情報を受信すると（ステップＳｃ１４）、生鮮商品登録情報を一意に識別するためのＩＤ、すなわち、登録商品を一意に識別するためのセラー登録商品ＩＤを生成する（ステップＳｃ１５）。そして、制御部１００は、この生鮮商品登録情報を商品登録テーブル１２４０ｂに追加すべく、認証情報として受信したセラーＩＤと、生成したセラー登録商品ＩＤと、生鮮商品登録情報とから、１件のレコードを生成し、商品登録テーブル１２４０ｂに追加する（ステップＳｃ１６）。これにより、セラーが取引を所望する生鮮商品の情報が商品登録テーブル１２４０ｂに登録される。
【００３７】
次いで、制御部１００は、商品登録テーブル１２４０ｂに追加したレコードに対応する輸入テーブル１２４０ｃのレコードを生成し、この輸入テーブル１２４０ｃに追加する（ステップＳｃ１７）。具体的に説明すると、制御部１００は、生鮮商品登録情報に含まれる出荷港と、船便名とから、到着港と、港到着予定日とを特定すると共に、生鮮商品登録情報に含まれている生鮮商品の最小取引数量から、貨物コンテナの荷詰容量を算出してレコードを生成する。そして、制御部１００は、セラー端末２０へ登録完了の旨を通知して（ステップＳｃ１８）、生鮮商品の登録処理を終了する。
【００３８】
以上説明した登録処理によって、セラーが取引を所望する生鮮商品が取引管理サーバ１０に登録されることになる。一方、バイヤーは、このようにして登録された生鮮商品の中から所望の生鮮商品を検索し、該当する生鮮商品があれば、その生鮮商品を発注する。以下、この生鮮商品の検索・発注処理について説明する。
【００３９】
図１５および図１６は、生鮮商品の検索・発注処理におけるバイヤー端末３０と取引管理サーバ１０との処理手順を示すシーケンス図である。この図に示すように、先ず、バイヤー端末３０は、取引管理サーバ１０に対して生鮮商品の商品検索用ページ４３０（図１７参照）の表示ページの送信を取引管理サーバ１０に要求する（ステップＳｄ１）。取引管理サーバ１０の制御部１００は、この送信要求を受信すると（ステップＳｄ２）、商品検索用ページ４３０を送信するに先立って、バイヤーに対して認証を行うべく、バイヤー端末３０にバイヤーＩＤとパスワードとを要求する（ステップＳｄ３）。バイヤー端末３０は、係る要求を受信すると、バイヤー端末３０の使用者（バイヤー）に対して、バイヤーＩＤとパスワードとの入力を促した後、入力されたバイヤーＩＤとパスワードとを認証情報として取得し（ステップＳｄ４）、取引管理サーバ１０へ送信する（ステップＳｄ５）。
【００４０】
取引管理サーバ１０の制御部１００は、認証情報を受信すると、この認証情報が正当か否かの認証処理を実行する（ステップＳｄ６）。より具体的には、具体的には、制御部１００は、認証情報により示されるバイヤーＩＤを検索キーとして、バイヤー管理データベース１２６０に登録されている各レコードを検索し、該当するレコードに登録されているパスワードと、ステップＳｄ６において受信したパスワードとを比較して、認証処理を行う。そして、パスワードが正当でないと判断された場合、制御部１００は、バイヤー端末３０にエラー通知を送信し（ステップＳｄ７）、処理を終了する。
【００４１】
一方、ステップＳｄ６における認証処理の結果、パスワードが正当であると判断された場合には、制御部１００は、記憶部１２０から商品検索用ページ４３０を読出し（ステップＳｄ８）、バイヤー端末３０に送信する（ステップＳｄ９）。バイヤー端末３０は、この商品検索用ページ４３０を受信すると（ステップＳｄ１０）、図１７に例示する商品検索用ページ４３０を表示部に表示する（ステップＳｄ１１）。
【００４２】
図１７に示すように、商品検索用ページ４３０には、検索条件が入力される入力欄として、生鮮商品の品目入力欄４３０ａと、規格入力欄４３０ｂと、原産地入力欄４３０ｃと、発注予定数入力欄４３０ｄと、希望納入日入力欄４３０ｅと、希望価格入力欄４３０ｆとが設けられている。品目入力欄４３０ａは、検索条件として、生鮮商品の品目が入力される欄であり、また、規格入力欄４３０ｂは、生鮮商品の規格が入力される欄である。原産地入力欄４３０ｃは、検索条件として、生鮮商品の原産地が入力される欄であり、また、発注予定数入力欄４３０ｄは、バイヤーが予定している発注数量（パッケージの個数）が入力される欄である。希望納入日欄４３０ｅは、バイヤーが希望する生鮮商品の納入日が入力される欄である。希望価格入力欄４３０ｆは、バイヤーが希望する購入価格が入力される欄である。バイヤーは、バイヤー端末３０の操作部を操作するなどして、商品検索用ページ４３０の各欄に検索条件を入力した後、送信ボタン４３０ｇをクリックすると、バイヤー端末３０が係る操作を検出し、入力された情報を検索情報として取得し（ステップＳｄ１２）、取引管理サーバ１０へ送信する（ステップＳｄ１３）。ここで、バイヤーが商品検索用ページ４３０の幾つかの入力欄に情報を入力していない場合には、入力された情報のみが、検索用情報として取引管理サーバ１０へ送信されることになる。
【００４３】
取引管理サーバ１０の制御部１００は、検索情報を受信すると（ステップＳｄ１４）、この検索情報に示される各検索条件に従って、商品登録テーブル１２４０ｂを検索し、該当するレコードを抽出する（ステップＳｄ１５）。ここで、検索情報に検索条件として希望納入日が含まれている場合には、制御部１００は、輸入テーブル１２４０ｃも検索し、港到着予定日が希望納入日よりも前の日付となっているレコードを抽出することになる。
【００４４】
次いで、制御部１００は、抽出したレコードに従って、図１８に例示する検索結果ページ４３２の表示データを生成し（ステップＳｄ１６）、バイヤー端末３０へ送信する（ステップＳｄ１７）。ここで、制御部１００は、検索結果ページ４３２の表示データを生成する際に、検索条件に該当した各レコードのセラーに対応するセラー実績を、セラー実績テーブル１２２０ｂから読出し、図１８に示すように、検索結果ページ４３２に信頼度として示している。バイヤー端末３０は、検索結果ページ４３２の表示データを受信すると（ステップＳｄ１８）、表示部などに表示する（ステップＳｄ１９）。以上の処理により、バイヤーは、所望する条件の生鮮商品を検索することができる。また、検索結果ページ４３２には、生鮮商品を選択する指標として、セラーの価格適正度が信頼度として表示されているため、バイヤーが生鮮商品の購入に慣れていない場合であっても、信頼のおけるセラーから生鮮商品を購入することができる。
【００４５】
次に、バイヤーが検索結果ページ４３２に示される各生鮮商品のうち、任意ものをクリックすると、その生鮮商品の詳細な情報を示した商品詳細ページ４３４（図１９参照）が表示されるようになっている。より具体的には、バイヤーが検索結果ページ４３２に示される生鮮商品をクリックすると、バイヤー端末３０が係る操作を検出し（ステップＳｄ２０）、その生鮮商品の商品詳細ページ４３４の表示データの送信を取引管理サーバ１０へ要求する（ステップＳｄ２１）。取引管理サーバ１０の制御部１００は、この送信要求を受信すると（ステップＳｄ２２）、バイヤーが詳細表示を所望する生鮮商品のレコードを、商品登録テーブル１２４０ｂおよび輸入テーブル１２４０ｃから抽出し、このレコードに示されている情報を記載した商品詳細ページ４３４の表示データを生成して（ステップＳｄ２３）、バイヤー端末３０に送信する（ステップＳｄ２４）。
【００４６】
バイヤー端末３０は、商品詳細ページ４３４の表示データを受信すると（ステップＳｄ２５）、図１９に例示する商品詳細ページ４３４を表示部などに表示する（ステップＳｄ２６）。図１９に示すように、商品詳細ページ４３４には、商品登録テーブル１２４０ｂおよび輸入テーブル１２４０ｃに記録されている各情報の他、戻るボタン４３４ａと発注ボタン４３４ｂとが設けられている。バイヤーは、商品詳細ページ４３４を閲覧し、他の生鮮商品の商品詳細を閲覧する場合には、戻るボタン４３４ａをクリックする。バイヤー端末３０は、係る操作を検出すると、処理手順をステップＳｄ１８に戻し、検索結果ページ４３２を再度表示する。これにより、バイヤーは、商品詳細を閲覧したい生鮮商品を再び選択することができる。
【００４７】
また、バイヤーは、商品詳細ページ４３４を閲覧して、この生鮮商品の発注を所望する場合には、発注ボタン４３４ｂをクリックする。バイヤー端末３０は、係る操作を検出すると（ステップＳｄ２７）、取引管理サーバ１０に対して、発注要求を送信する（ステップＳｄ２８）。取引管理サーバ１０は、発注要求を受信すると（ステップＳｄ２９）、記憶部１２０から発注ページ４３６（図２０参照）の表示データを読出し（ステップＳｄ３０）、バイヤー端末３０へ送信する（ステップＳｄ３１）。バイヤー端末３０は、発注ページ４３６の表示データを受信すると（ステップＳｄ３２）、図２０に例示する発注ページ４３６を表示部などに表示する（ステップＳｄ３３）。
【００４８】
図２０に示すように、発注ページ４３６には、発注の対象となるセラーの氏名および生鮮商品の情報（品目名、生産地、規格、納品予定日）とが予め示されており、バイヤーが情報を入力する手間を省けるようになっている。また、発注ページ４３６には、発注数量入力欄４３６ａが設けられており、バイヤーは、操作部を操作するなどして、発注数量を入力した後に、送信ボタン４３６ｂをクリックする。バイヤー端末３０は、係る操作を検出すると、入力された情報を発注情報として取得し（ステップＳｄ３４）、取引管理サーバ１０へ送信する（ステップＳｄ３５）。
【００４９】
取引管理サーバ１０の制御部１００は、発注情報を受信すると（ステップＳｄ３６）、この発注情報を取引管理データベース１２８０に追加すべく、この発注情報を一意に識別するための発注ＩＤを生成した後に（ステップＳｄ３７）、この発注ＩＤと発注情報とからレコードを生成し、取引管理データベース１２８０に追加する（ステップＳｄ３８）。これにより、バイヤーからの発注が取引管理データベース１２８０に登録される。
【００５０】
このように、バイヤーからの発注が取引管理データベース１２８０に順次登録されると、取引管理サーバ１０の制御部１００は、登録された各発注のうち、同一のセラーであり、かつ、同一の生鮮商品に対する発注を抽出し、発注数量が貨物コンテナの荷詰数量となるように、抽出した各発注を取りまとめる処理を実行する。以下、この発注取りまとめ処理について説明する。
【００５１】
図２１は、取引管理サーバ１０の制御部１００が実行する発注取りまとめ処理の処理手順を示すフローチャートである。この図に示すように、先ず、制御部１００は、取引管理データベース１２８０の各レコードから、同一のセラーに対する発注のみを抽出するために、セラーＩＤを検索キーとして、取引管理データベース１２８０を検索し、該当するレコードを抽出する（ステップＳｅ１）。次いで、制御部１００は、このように抽出したレコードから、同一の生鮮商品が発注されているものを抽出するために、品目ＩＤを検索キーとして、該当するレコードを抽出する（ステップＳｅ２）。これにより、取引管理データベース１２８０に登録された各レコードから、同一のセラーであり、かつ、同一の生鮮商品に対する発注を示すレコードが抽出される。
【００５２】
次いで、制御部１００は、ステップＳｅ２において抽出された各レコード（発注）のうち、幾つかを取りまとめ、１件の取りまとめ発注を生成する（ステップＳｅ３）。より具体的に説明すると、制御部１００は、ステップＳｅ２において抽出された各レコードから、発注数量の総量がコンテナ荷詰容量以下であり、かつ、所定値（例えば、コンテナ荷詰容量の９割）以上となるように１乃至２以上のレコードを選択する。そして、制御部１００は、選択した各レコードに対して、取りまとめＩＤを付する。すなわち、同一の取りまとめＩＤが付された各レコードが１件の取りまとめ発注として扱われることになる。
【００５３】
次に、制御部１００は、同一の取りまとめＩＤが付されている各レコードに示される発注を一括してセラー端末２０に送信する（ステップＳｅ４）。これにより、１個の貨物コンテナが略満杯となるように、セラーに対して発注がなされる。従って、２以上のバイヤーからの発注が取りまとめられて発注された場合には、貨物コンテナ単位で課金される輸送料金を、これらのバイヤー間で分担することになるため、一人で少量を発注するときに比べ、輸送料金を抑えることができる。ここで、輸送料金は、各バイヤーの発注数量に比例して分担されることが望ましい。このように輸送料金が分担された場合、パッケージ単位での輸送料金は、各バイヤー間で同額となる。すなわち、発注数量の大小を問わず、各バイヤー間で輸送料金が同額となり、発注数量の違いによる輸送料金の格差を無くす事が可能となる。
【００５４】
さて、以上の取りまとめ処理によって、セラーに発注がなされると、セラーは、発注に従って生鮮商品を貨物コンテナに詰め、貨物コンテナ単位で出荷港より出荷する。そして、セラーは、出荷完了の旨を示す出荷完了通知をセラー端末２０から取引管理サーバ１０に送信する。ここで、この出荷完了通知には、どの発注に対する出荷であるかを識別する情報（例えば、発注ＩＤまたは取りまとめＩＤなど）が含まれている。取引管理サーバ１０の制御部１００は、出荷完了通知を受信すると図２２に示す出荷チェック処理を実行する。具体的には、この図に示すように、制御部１００は、出荷完了済みであることを取引管理データベース１２８０に記録すべく、出荷完了通知によって示される発注ＩＤを特定する（ステップＳｆ１）。次いで、制御部１００は、特定した発注ＩＤに対応するレコードの出荷チェックフラグ（図６参照）に「１」を記録する（ステップＳｆ２）。
これにより、発注された生鮮商品が出荷されたかが、取引管理データベース１２８０に記録されることになる。
【００５５】
このようにして、セラーが在住する生産国４から生鮮商品が出荷され、購入国５に輸送されると、この生鮮商品の品質が販売価格に見合っているかが評価される。この評価は、例えば、取引管理システム１を運営する団体によって行われても、また、この団体から委託された機関によって行われても良い。そして、この評価結果に従って、セラーの取引実績を示す価格適正度（図３参照）が更新される。また、取引管理サーバ１０は、バイヤーからの苦情などの商品評価を示す情報をバイヤー端末３０から受信すると、この情報に従ってセラーの価格適正度を更新する。これにより、セラーの取引実績を示す価格適正度、すなわち、セラーの取引上の信頼度が取引ごとに評価されることになる。
【００５６】
以上説明したように、本実施形態に係る取引システム１にあっては、セラーの取引上の信頼度が評価され、バイヤーに対して示されるため、バイヤーが取引に慣れていない場合であっても、信頼できるセラーから生鮮商品を購入することができ、品質に見合った価格で生鮮商品を購入することができる。また、貨物コンテナが略満杯になるように複数の発注が取りまとめられて、セラーに発注されるため、生鮮商品の輸送料金をバイヤー間で平等にすることができる。
【００５７】
＜変形例＞
上述した実施形態は、あくまでも例示であり、本発明の趣旨の範囲内で任意に変形および応用が可能である。そこで、以下に、実施形態の各種変形例について説明する。
【００５８】
（変形例１）
上述した実施形態にあっては、バイヤーが商品検索用ページ４３０に検索条件を入力し、検索結果として得られた検索結果ページ４３２（図１８参照）を閲覧することで、どのセラーに発注するかを選択する構成とした。しかしながら、次のように変形されても良い。すなわち、バイヤーがセラーを選択するのではなく、取引管理サーバ１０が発注先のセラーを選択する構成である。具体的には、図１７に示す商品検索用ページ４３０に、取引管理サーバ１０にセラーの選択を指示するためのチェックボックスを更に設ける。そして、取引管理サーバ１０は、このチェックボックスにチェックがされている場合には、商品検索用ページ４３０に入力された検索条件に該当するレコードを商品管理データベース１２４０から抽出し、これらのレコードから、更に、セラー実績（価格適正度）が優秀なものを抽出する。そして、抽出したセラーを発注先のセラーとして、バイヤーに提示する。このような構成により、バイヤーは、より簡単に信頼のおけるセラーに対して生鮮商品を発注することができる。
【００５９】
（変形例２）
上述した実施形態にあっては、セラーの取引上の信頼度として、セラーの取引実績を示す価格適正度を用いる構成とし、この価格適正度は、取引管理システム１を運営する団体、または、この団体から委託された機関などの評価、および、バイヤーからの苦情などの評価に基づいて更新される構成とした。この構成において、取引管理サーバ１０が各評価を取得した際に、この評価と、過去の評価の累積（例えば平均など）とから、価格適正度を求めるようにしても良い。このような構成とすることで、１回あたりの評価の重みを小さくすることができ、各回の発注取引ごとに、評価が大きく変動するのを抑えることができる。
なお、上述した実施形態において、セラーの取引上の信頼度と同様に、バイヤーの取引上の信頼度をもセラーに対して示す構成としても良いことは勿論である。この構成において、バイヤーの取引上の信頼度として、例えば、発注に対する入金の滞納頻度などが挙げられる。このように、バイヤーの信頼度をセラーに対して示すことにより、セラーは、取引上、信頼のおけるバイヤーに対してのみ生鮮商品を販売することができる。
【００６０】
（変形例３）
上述した実施形態にあっては、取引管理サーバ１０は、バイヤーからの発注を受け付けるだけの構成であったが、これに限らず、例えば、生鮮商品のオークション販売を実現するための機能を備える構成であっても良い。この構成において、オークションの対象となる生鮮商品のセラーの取引実績をバイヤーに対して提示する構成としても良いことは勿論である。
【００６１】
【発明の効果】
以上説明したように、本発明によれば、取引に不慣れな購入者であっても、品質に見合った適正な価格で生鮮商品を購入することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係る取引システムの構成を示す概念図である。
【図２】同取引管理サーバの機能的構成を示すブロック図である。
【図３】同セラー管理データベースの構成を示す概念図である。
【図４】同商品管理データベースの構成を示す概念図である。
【図５】同バイヤー管理データベースの構成を示す概念図である。
【図６】同発注管理データベースの構成を示す概念図である。
【図７】セラー登録時のセラー端末と取引管理サーバの処理手順を示すシーケンス図である。
【図８】同セラー登録ページの構成を示す概念図である。
【図９】同セラー登録終了ページの構成を示す概念図である。
【図１０】同バイヤー登録時のバイヤー端末と取引管理サーバとの処理手順を示すシーケンス図である。
【図１１】同バイヤー登録ページの構成を示す概念図である。
【図１２】同バイヤー登録終了ページの構成を示す概念図である。
【図１３】生鮮商品登録時のセラー端末と取引管理サーバとの処理手順を示すシーケンス図である。
【図１４】同生鮮商品登録ページの構成を示す概念図である。
【図１５】同生鮮商品検索、発注時のバイヤー端末と取引管理サーバとの処理手順を示すシーケンス図である。
【図１６】同生鮮商品検索、発注時のバイヤー端末と取引管理サーバとの処理手順を示すシーケンス図である。
【図１７】同商品検索用ページの構成を示す概念図である。
【図１８】同検索結果ページの構成を示す概念図である。
【図１９】同商品詳細ページの構成を示す概念図である。
【図２０】同発注ページの構成を示す概念図である。
【図２１】同制御部によって実行される発注取りまとめ処理の処理手順を示すフローチャートである。
【図２２】同制御部によって実行される出荷チェック処理の処理手順を示すフローチャートである。
【符号の説明】
１・・・取引システム、２・・・インターネット、１０・・・取引管理サーバ、２０・・・セラー端末、３０・・・バイヤー端末、１００・・・制御部、１０２・・・通信Ｉ／Ｆ、１２０〜１２８・・・記憶部、１２２０・・・セラー管理データベース、１２２０ｂ・・・セラー実績テーブル、１２４０・・・商品管理データベース、１２６０・・・バイヤー管理データベース、１２８０・・・取引管理データベース。

Claims (5)

1. 生産者が所有する第１の通信端末、および、当該生産者が生産する生産物を購入する購入者が所有する第２の通信端末の各々と通信網を介して通信する取引管理サーバにおいて、
   生産者と、当該生産者が生産する生産物の情報とを対応付けて記憶する第１の記憶手段と、
   生産者の取引上の信頼度を生産者ごとに記憶する第２の記憶手段と、
   購入者が所望する生産物の条件を、前記第２の通信端末から受信する第１の受信手段と、
   受信した条件に従って前記第１の記憶手段を検索し、該当する生産物の情報を読み出すと共に、当該生産物の情報に対応付けられた生産者の信頼度を前記第２の記憶手段から読み出す読出手段と、
   読み出された生産物の情報および生産者の信頼度を前記第２の通信端末に送信する第１の送信手段と、
   生産物の発注のための情報であり、前記第１の送信手段により送信された前記生産物の情報のうち、購入者が発注すべく選択した生産物の情報を識別する情報を含む発注情報を前記第２の通信端末から受信する第２の受信手段と、
   前記発注情報から生産者を特定すると共に、当該生産者が所有する第１の通信端末に対して、前記発注情報を送信する第２の送信手段と
   を具備することを特徴とすると取引管理サーバ。
2. 前記第１の送信手段は、信頼度が最も高い生産者に対応する生産物の情報のみを送信する
   ことを特徴とする請求項１に記載の取引管理サーバ。
3. 生産物を輸送する際に使用される１個の貨物コンテナに荷詰可能な生産物の数量を荷詰可能数量として記憶する第３の記憶手段と、
   前記第２の受信手段が受信した発注情報を累積的に記憶する第４の記憶手段と、
   前記第４の記憶手段に記憶されている各発注情報から、幾つかの発注情報を選択する手段であり、発注情報により示される前記生産物の発注数量の総量が前記荷詰可能数量以下であり、かつ、所定値以上となるように発注情報を選択する選択手段手段とを、さらに備え、
   前記第２の送信手段は、前記選択手段により選択された発注情報を一括して送信する
   ことを特徴とする請求項１に記載の取引管理サーバ。
4. 生産者が所有する第１の通信端末、および、当該生産者が生産する生産物を購入する購入者が所有する第２の通信端末の各々と通信網を介して通信するコンピュータを、
   生産者と、当該生産者が生産する生産物の情報とを対応付けて記憶する手段、
   生産者の取引上の信頼度を生産者ごとに記憶する手段、
   購入者が所望する生産物の条件を、前記第２の通信端末から受信する手段、
   受信した条件に従って前記第１の記憶手段を検索し、該当する生産物の情報を読み出すと共に、当該生産物の情報に対応付けられた生産者の信頼度を前記第２の記憶手段から読み出す手段、
   読み出された生産物の情報および生産者の信頼度を前記第２の通信端末に送信する手段、
   生産物の発注のための情報であり、前記第１の送信手段により送信された前記生産物の情報のうち、購入者が発注すべく選択した生産物の情報を識別する情報を含む発注情報を前記第２の通信端末から受信する手段、および、
   前記発注情報から生産者を特定すると共に、当該生産者が所有する第１の通信端末に対して、前記発注情報を送信する手段
   として機能させるための取引管理プログラム。
5. 生産者が所有する第１の通信端末、および、当該生産者が生産する生産物を購入する購入者が所有する第２の通信端末の各々と通信網を介して通信するコンピュータを、
   生産者と、当該生産者が生産する生産物の情報とを対応付けて記憶する手段、
   生産者の取引上の信頼度を生産者ごとに記憶する手段、
   購入者が所望する生産物の条件を、前記第２の通信端末から受信する手段、
   受信した条件に従って前記第１の記憶手段を検索し、該当する生産物の情報を読み出すと共に、当該生産物の情報に対応付けられた生産者の信頼度を前記第２の記憶手段から読み出す手段、
   読み出された生産物の情報および生産者の信頼度を前記第２の通信端末に送信する手段、
   生産物の発注のための情報であり、前記第１の送信手段により送信された前記生産物の情報のうち、購入者が発注すべく選択した生産物の情報を識別する情報を含む発注情報を前記第２の通信端末から受信する手段、および、
   前記発注情報から生産者を特定すると共に、当該生産者が所有する第１の通信端末に対して、前記発注情報を送信する手段
   として機能させるための取引管理プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images