JP2019106132A - 取引サーバ - Google Patents

Abstract

【課題】 商品の出荷可能な量に応じた取引を支援できる取引サーバを提供する。【解決手段】 実施形態によれば、取引サーバは、通信部と、データベースと、プロセッサと、を有する。通信部は、端末装置と通信する。データベースは、前記端末装置からの売り注文に基づく売り注文データを記憶する。プロセッサは、前記端末装置から売り注文を受信した場合、受信した売り注文による商品の注文数量と前記データベースに登録済みの売り注文による当該商品の既注文の数量とを加算した売り注文の総量が閾値以下であるかを判定し、前記総量が閾値以下である場合には受信した売り注文に基づく売り注文データを前記データベースに記憶し、前記総量が閾値を超える場合にはエラー処理を行う。【選択図】図２

Description

本発明の実施形態は、取引サーバに関する。

従来、野菜や魚などの商品は、市場で現物を見ながら価格を決める競りと呼ばれるシングルオークションによって取引されるのが多い。一方、近年では、品質のばらつきが非常に小さい植物体を安定して生産可能な植物工場が実現されている。植物工場で生産される植物体のような安定生産が見込める商品は、株取引や証券取引で採用されているダブルオークションで取引を行うことができると考えられる。例えば、植物工場では安定して植物体を生産でき、毎日の出荷量（植物体の生産能力）が一定となる。このため、植物工場が生産する植物体は、ダブルオークション方式の取引システムでの取引が可能である。

しかしながら、従来の取引システムでは、植物工場における植物体の生産能力などに基づく実際に出荷可能な量を超えた数量の売り注文が入力される可能性がある。また、従来の取引システムは、売り注文を出した商品の出荷日や数量などを変更した場合、売り注文が出された同一商品の総量が実際に出荷可能な量を超える可能性もある。

特開２００９−７７３０８号公報

本発明は、上記した課題を解決するために、商品の出荷可能な量に応じた取引を支援できる取引サーバを提供することを目的とする。

実施形態によれば、取引サーバは、通信部と、データベースと、プロセッサと、を有する。通信部は、端末装置と通信する。データベースは、前記端末装置からの売り注文に基づく売り注文データを記憶する。プロセッサは、前記端末装置から売り注文を受信した場合、受信した売り注文による商品の注文数量と前記データベースに登録済みの売り注文による当該商品の既注文の数量とを加算した売り注文の総量が閾値以下であるかを判定し、前記総量が閾値以下である場合には受信した売り注文に基づく売り注文データを前記データベースに記憶し、前記総量が閾値を超える場合にはエラー処理を行う。

図１は、実施形態に係る取引システムの構成例を示す図である。 図２は、実施形態に係る取引サーバの構成例を示すブロック図である。 図３は、実施形態に係る取引サーバが管理する販売者登録データの例を示す図である。 図４は、実施形態に係る取引サーバによる取引処理の例を説明するためのフローチャートである。 図５は、実施形態に係る取引サーバによる取引処理の例を説明するためのフローチャートである。 図６は、実施形態に係る取引サーバによる取引処理の例を説明するためのフローチャートである。 図７は、実施形態に係る取引サーバが管理する第１の取引期間で受け付ける売り注文データの例を示す図である。 図８は、実施形態に係る取引サーバが管理する第１の取引期間で受付ける買い注文データの例を示す図である。 図９は、実施形態に係る取引サーバが管理する第２の取引期間で受付ける売り注文データの例を示す図である。 図１０は、実施形態に係る取引サーバが管理する第２の取引期間で受付ける買い注文データの例を示す図である。

以下、図面を参照しながら実施形態について説明する。
図１は、実施形態に係る取引システム１の全体構成を概略的に示す図である。
実施形態に係る取引システム１は、ネットワークを介して接続される電子機器の間で、特定の生産期間で生産される野菜や魚などの商品の取引を実現するシステムである。たとえば、取引システム１は、養殖所（植物工場、魚の養殖所、養豚場、養鶏場など）で生産される食料品などの商品の取引を行う。本実施形態では、主として植物工場で生産（栽培）される植物体（たとえば、レタス）を取引する場合を想定して取引システム１について説明する。

取引システム１において、販売者は、植物工場の運営者（生産者）自身あるいは生産者から販売を委託された者である。購入者は、販売者（生産者）から商品を購入する者である。たとえば、購入者は、スーパーマーケット、ホテル、仲卸業者などの小売業者である。消費者は、販売者から直接商品を購入する者ではなく、購入者が取引システム１で購入した商品を購入または消費する者である。たとえば、消費者は、購入者としてのスーパーマーケットなどの小売店の顧客あるいは購入者としてのホテル等の利用者などである。

取引システム１は、商品ごとの出荷日に応じた市場を開き、商品を収穫する前に取引（売買）を実施する。取引システム１では、取引対象の商品に対して取引期間を設定し、取引期間内において販売者が売り注文を出し、購入者が買い注文を出す。取引システム１は、取引期間内の売り注文と買い注文とをマッチングすることにより取引の成否を決定する。このような販売者と購入者との両者が価格形成に関与する取引方式は、ダブルオークションとも呼ばれる。

取引システム１は、出荷日前（たとえば、お届け日の１週間前からなど）または播種前から収穫日までの期間（たとえば、６０日前からなど）で取引を実施する（市場を開く）。取引システム１は、出荷日付近になると取引を終了する（市場を閉じる）。ただし、取引システム１は、取引期間中、２４時間取引できるようにしても良いし、９−１７時などの時間を区切って取引を行うようにしても良い。また、取引システムは、同一商品でも、出荷日ごとに市場を分けて取引される。たとえば、９／１５に出荷するレタスと９／１６に出荷するレタスとは、別の市場（商品）として取引される。

また、実施形態では、取引システム１は、個々の商品について２つの取引期間を設けるものとする。第１の取引期間は、予約期間があり、予約期間の終了日に取引を実施する板寄せ方式による取引を実施する期間である。第２の取引期間は、注文を受けるごとに取引を実施するザラバ方式による取引を実施する期間である。たとえば、第２の取引期間は、第１の取引期間終了後から商品の出荷日（収穫日）までの期間である。ただし、取引期間は、運用形態に応じて適宜設定するものであれば良く、上述した第１および第２の取引期間を設定することに限定されるものではない。

次に、実施形態に係る取引システム１の構成について説明する。
図１に示す構成例において、取引システム１は、取引サーバ２、複数の販売者端末３、複数の購入者端末４などを含む。
取引サーバ２は、取引処理を行うとともに、取引に関するデータおよび商品に関するデータの管理などを行う。取引サーバ２は、たとえば、汎用のサーバ装置により構成される。取引システム１において、取引サーバ２は、１台であっても良いし、複数台であっても良い。たとえば、取引サーバ２は、取引する商品の種類ごとに設けても良い。また、取引サーバ２は、取引処理を行うサーバ装置、および、後述するデータベースごとのサーバ装置などで構成するようにしても良い。

取引サーバ２は、ネットワークを通じて各装置と通信することにより取引処理を実行するサーバ装置として動作する。たとえば、取引サーバ２は、植物体などの商品を取引するためのＷｅｂサイトをネットワーク上に公開する。取引サーバ２は、ネットワークを通じて商品取引用のＷｅｂサイトにアクセスする各販売者端末３からの売り注文および各購入者端末４からの買い注文を受け付ける。取引サーバ２は、受付けた売り注文と買い注文とにより取引処理を実施する。さらに、取引サーバ２は、成約した取引に関する情報および取引が成約した商品に関する情報を管理する機能も有する。

販売者端末３は、植物体などの商品を取引システムで販売する販売者が使用する電子機器である。購入者端末４は、植物体などの商品を購入する購入側の利用者（以下、購入者（バイヤー）とも称する）が使用する電子機器である。販売者端末３および購入者端末４は、プログラムを実行するプロセッサ、取引サーバ２との通信部、および、データを記憶するメモリなどを有する電子機器で実現できる。たとえば、販売者端末３および購入者端末４は、パーソナルコンピュータ、タブレットＰＣ、スマートフォンなどで構成される。販売者端末３は、取引システム１において、複数であって良い。購入者端末４は、通常の運用形態において、取引システム１内に複数存在するものとする。

各販売者端末３は、各販売者が指定する売り注文を取引サーバ２へ送信する。各購入者端末４は、各購入者が指定する買い注文を取引サーバ２へ送信する。取引サーバ２は、販売者端末３からの売り注文と購入者端末４からの買い注文とに基づいて取引処理を行う。取引サーバ２は、取引結果（取引の成立または不成立など）を販売者端末３および購入者端末４へ送信する。さらに、取引サーバ２は、販売者端末３または購入者端末４からの閲覧要求に応じて、各商品に対する、売り注文、買い注文、取引結果などの情報を提供する機能を有する。

次に、取引サーバ２の構成について説明する。
図２は、取引サーバ２の構成を示すブロック図である。
図２に示す構成例において、取引サーバ２は、プロセッサ２１、メモリ２２、通信部２３および各種のデータベース（ＤＢ）２４〜２８を有する。
プロセッサ２１は、プログラムを実行することにより各種の処理を実現する。プロセッサ２１は、たとえば、ＣＰＵである。メモリ２２は、ＲＯＭ、ＲＡＭおよび書換え可能な不揮発性メモリなどのメモリで構成する。たとえば、メモリ２２は、プログラムを記憶する不揮発性のメモリを含む。また、メモリ２２は、データを一時的に格納するためのＲＡＭなどのワーキングメモリを含む。

メモリ２２が記憶するプログラムには、基本プログラム（ＯＳ）の他、各種のアプリケーションプログラムが含まれる。アプリケーションプログラムには、商品の取引に関係する処理を行うためのプログラムおよび商品に関する情報を提供する処理などを行うためのプログラムが含まれる。プロセッサ２１は、メモリ２２が記憶する各種のプログラムを実行することにより後述する各種の処理を実現する。

通信部２３は、取引システム１内の各装置と通信するためのインターフェースである。図２に示す構成例では、通信部２３は、販売者端末３および購入者端末４と通信するためのインターフェースを含む。通信部２３は、インターネット等を含むネットワークを介して販売者端末３および購入者端末４と通信するものであっても良い。

たとえば、通信部２３は、販売者端末３から売り注文または売り注文の変更などの売り注文に関する情報を受信する。また、通信部２３は、購入者端末４から買い注文または閲覧要求などの情報を受信する。また、通信部２３は、取引結果などを販売者端末３および購入者端末４へ送信する。

各ＤＢ２４〜２８は、ハードディスクドライブ（ＨＤＤ（Hard disk drive））あるいはＳＳＤ（solid state drive）などの書換え可能な不揮発性の記憶装置により実現される。なお、各ＤＢ２４〜２８は、取引サーバ２と通信可能な１つ又は複数のデータサーバで実現しても良い。

顧客ＤＢ２４は、取引に参加する販売者および購入者の情報を記憶する。顧客ＤＢ２４は、取引に参加するためのユーザ認証に用いる認証情報などを記憶する。また、顧客ＤＢ２４には、販売者の情報として登録データが記憶される。販売者登録データは、販売者に関する情報だけでなく、当該販売者が販売する商品（生産品種）に関する情報を含む。商品に関する情報としては、生産する品種ごとに１日辺りの出荷可能な量（生産数量）を含む。

商品ＤＢ２５は、取引対象とする商品に関する情報を記憶する。たとえば、商品ＤＢ２５は、商品の出荷日および取引期間を設定するための情報などを記憶する。また、商品ＤＢ２５は、各販売者が生産する品種ごとに１日辺りの出荷可能な量（生産数量）を示す情報を記憶するようにしても良い。

注文ＤＢ２６は、注文に関する情報を記憶する。本実施形態において、注文ＤＢ２６は、第１の売り注文ＤＢ２６ａ、第１の買い注文ＤＢ２６ｂ、第２の売り注文ＤＢ２６ｃ、および、第２の買い注文ＤＢ２６ｄを有するものとする。第１の売り注文ＤＢ２６ａは、板寄せ方式による取引を実施する第１の取引期間で受付けた売り注文を格納する。第１の買い注文ＤＢ２６ｂは、板寄せ方式による取引を実施する第１の取引期間で受付けた買い注文を格納する。第２の売り注文ＤＢ２６ｃは、ザラバ方式による取引を実施する第２の取引期間で受付けた売り注文を格納する。第２の買い注文ＤＢ２６ｄは、ザバラ方式による取引を実施する第２の取引期間で受付ける買い注文を格納する。

成約ＤＢ２７は、成立（成約）した取引に関する情報を格納する。たとえば、成約ＤＢ２７は、成約した商品を示す情報、販売者、購入者、および、取引が確定した日時などを示す成約データを格納する。

なお、取引サーバ２は、管理者用の入出力装置として、入力装置（操作装置）および表示装置を具備しても良い。例えば、入力装置は、キーボード、マウス、タッチパネル等などで実現できる。また、表示装置は、例えば、カラーＬＣＤ（Liquid Crystal Display）等の表示デバイスなどで実現できる。また、入出力装置は、タッチパネル付きの表示装置で実現しても良い。

図３は、販売者登録データの構成例を示す図である。
販売者登録データは、販売者登録データは、販売者に関する情報と当該販売者が生産する商品（植物体）に関する情報とを含む。販売者登録データは、たとえば、顧客データベース２４に記憶される。販売者登録データは、取引サーバ２のプロセッサ２１が適宜アクセスできるメモリに記憶されるものであれば良い。

図３に示す例において、販売者に関する情報は、登録日、ユーザＩＤ、会社（植物工場）名、代表者名、会社住所、会社電話番号、会社メールアドレスなどである。商品に関する情報は、当該販売者が販売する商品（植物工場が生産する植物体の品種）ごとに１日辺りの生産数量（１日辺りに出荷可能な量）を示す情報を含む。図３に示す販売者の１日辺りの生産数量は、フリルレタスが２５００株、ロメインレタスが１０００株、リーフレタスが１０００株、クレソンが５００株である例を示す。

このような各商品に対する１日辺りの生産数量は、後述する取引において各商品の売り注文が可能な数量に対する閾値となる。本実施形態では、取引対象となる商品としての植物体を生産する各植物工場（販売者）は、商品ごとに１日辺りの生産数量（１日で出荷可能な量）が決まっているものとする。本実施形態に係る取引システムでは、各出荷日の商品ごとに１日辺りの生産数量を閾値として、売り注文の登録および変更を受付けるようにするものである。

次に、実施形態に係る取引サーバ２による取引処理について説明する。
図４、図５及び図６は、実施形態に係る取引サーバ２による取引処理の例を説明するためのフローチャートである。
取引サーバ２は、複数種類の商品（各地の植物工場で生産される植物体などの商品）のそれぞれについて出荷日ごとに取引を管理する。たとえば、リーフレタスの取引を行う場合、取引サーバ２は、各販売者についてリーフレタスの出荷（予定）日ごとに売り注文と買い注文とを受け付ける。取引サーバ２のプロセッサ２１は、取引対象とする商品について、出荷予定日および栽培期間等に基づいて取引期間を設定する（ＡＣＴ１０）。

なお、本実施形態において、プロセッサ２１は、商品ごとの取引期間として、第１の取引期間と第２の取引期間とを設定するものとする。第１の取引期間は、第１の取引方式（たとえば、板寄せ方式）で取引する期間である。第１の取引期間は、たとえば、栽培期間が開始される播種日より前の期間が設定される。第２の取引期間は、第２の取引方式（たとえば、ザラバ方式）で取引する期間である。第２の取引期間は、たとえば、播種日以降に取引をする期間である。

実施形態に係る取引サーバ２は、植物工場で栽培される計画生産が可能な品質のばらつきが非常に小さい植物体の取引を行うものとしている。植物工場では、各植物体（種類）について、栽培期間が一定で、出荷予定日に応じて播種日を決定することができる。植物体の栽培期間についてのデータは、植物体の種類毎に、予め商品ＤＢ２５に記録されているものとする。プロセッサ２１は、商品ＤＢ２５に記録されているデータを参照して第１の取引期間と第２の取引期間とを設定するものとする。ただし、取引期間は、上述したような第１および第２の取引期間に限定されるものではなく、運用形態に応じて適宜設定されるものであれば良い。

取引期間を設定すると、取引サーバ２のプロセッサ２１は、設定した各取引期間において、販売者からの売り注文と購入者からの買い注文とを受付ける。すなわち、取引サーバ２のプロセッサ２１は、設定した第１の取引期間の注文開始日になると、第１の取引方式（板寄せ方式）による注文の受付を開始する（ＡＣＴ１１）。注文の受付を開始した後、プロセッサ２１は、第１の取引期間中、当該商品についての販売者端末３からの売り注文および売り注文の変更、購入者端末４からの買い注文および閲覧要求などを受け付ける。プロセッサ２１は、顧客ＤＢ２４に登録された認証情報に基づいて利用者（販売者および購入者）の認証を行い、認証が成功した利用者からの注文を受け付ける。

販売者端末３からの売り注文を受信した場合（ＡＣＴ１２、ＹＥＳ）、プロセッサ２１は、受信した売り注文の内容に基づいて重複する売り注文が既に登録済みであるかを判断する（ＡＣＴ１３）。たとえば、売り注文は、販売者、出荷日、品種（商品名）、および、売り注文の数量などを示す情報を含む。本実施形態において、植物工場が出荷する植物体は、出荷日ごとに異なる市場として管理される。すなわち、プロセッサ２１は、受信した売り注文に対して、販売者、品種および出荷日が同一の売り注文が売り注文ＤＢ２６ａに登録済みか否かにより重複ありか否かを判断する。

重複する売り注文があると判断した場合（ＡＣＴ１３、ＹＥＳ）、プロセッサ２１は、受信した売り注文の数量（今回注文数）と重複する全ての登録済みの売り注文の数量（既注文数）とを加算することによって売り注文の総量（合計注文数）を算出する（ＡＣＴ１４）。また、重複する売り注文が無いと判断した場合（ＡＣＴ１３、ＮＯ）、プロセッサ２１は、受信した売り注文の数量を売り注文の総量（合計注文数）とする。

売り注文の総量を算出すると、プロセッサ２１は、売り注文の総量が当該売り注文の商品に設定される閾値以下であるかを判断する（ＡＣＴ１５）。ここでは、板寄せ取引が当該商品（植物体）の播種前であることを想定している。第１の取引期間（板寄せの取引期間）において、各商品に設定される閾値は、顧客ＤＢ２４に販売者登録データとして登録される１日辺りの生産能力であるものとする。

売り注文の総量が閾値以下である場合（ＡＣＴ１５、ＹＥＳ）、プロセッサ２１は、受信した売り注文を売り注文ＤＢ２６ａに登録する（ＡＣＴ１６）。売り注文を登録する場合、プロセッサ２１は、当該売り注文の発信元である販売者端末へ売り注文を受付けた旨を通知しても良い。

図７は、第１の取引期間において売り注文ＤＢ２６ａに登録される注文データ（売り注文データ）の例である。図７に示す例は、取引方式（発注条件）として「板寄せ」が設定された販売者端末３からの売り注文を示す注文データとなっている。また、図７に示す売り注文ＤＢ２６ａは、後述するような売り注文に対する変更要求を受付けた場合、受付けた変更内容に応じて更新される。

売り注文の総量が閾値を超える場合（ＡＣＴ１５、ＹＥＳ）、プロセッサ２１は、受信した売り注文に対するエラー処理を行う（ＡＣＴ１７）。プロセッサ２１は、エラー処理として、受信した売り注文をキャンセルしても良いし、閾値以下となる数量分の売り注文を受付けるようにしても良い。

受信した売り注文をキャンセルする場合、プロセッサ２１は、当該売り注文の発信元である販売者端末３へ売り注文をキャンセルする旨を通知する。たとえば、プロセッサ２１は、売り注文による合計注文数が生産能力を超えているため、当該売り注文が受付け不可となった旨のメッセージを販売者端末３へ送信する。

また、エラー処理として閾値以下となる数量分の売り注文を受付ける場合、プロセッサ２１は、閾値以下となる数量分の売り注文を売り注文ＤＢ２６ａに登録する。たとえば、既注文数（登録済みの売り注文の数）が５００株、今回注文数（受信した売り注文の数）が１５００株、かつ、閾値（１日辺りの生産数量）が１０００株である場合、プロセッサ２１は、今回の注文として５００株分の売り注文を受付ける。また、プロセッサ２１は、数量を減算して売り注文を受付けた場合、当該売り注文の発信元の販売者端末３へ受付けた数量（又はキャンセル（受付け不可）とした数量）を通知する。

また、取引サーバ２は、売り注文だけでなく、販売者端末からの売り注文の変更（変更要求）を受信する。取引サーバ２は、変更内容が許容される内容であれば、変更要求に応じて売り注文ＤＢ２６ａに登録済みの売り注文の注文データを更新（変更）しても良い。なお、プロセッサ２１は、注文内容を変更するだけでなく、注文の取り消しも受け付けるようにしても良い。これにより、販売者及び購入者は、第１の取引期間の注文期間内であれば、注文状況を把握しながら注文内容を変更することが可能となる。

販売者端末３から売り注文の変更（変更要求）を受信した場合（ＡＣＴ１８、ＹＥＳ）、プロセッサ２１は、受信した売り注文の変更に対して重複する売り注文があるかを判断する（ＡＣＴ１３）。たとえば、登録済みの売り注文における出荷日の変更を要求する変更要求を受信した場合、プロセッサ２１は、当該出荷日の別の売り注文があるかを判断する。

重複する売り注文があると判断した場合（ＡＣＴ１３、ＹＥＳ）、プロセッサ２１は、受信した変更要求に従って変更した後の売り注文の数量と重複する別の売り注文の数量とを加算することによって売り注文の総量（合計注文数）を算出する（ＡＣＴ１４）。また、重複する売り注文が無いと判断した場合（ＡＣＴ１３、ＮＯ）、プロセッサ２１は、受信した変更要求に従って変更した後の売り注文の数量を売り注文の総量（合計注文数）とする。

売り注文の総量を算出すると、プロセッサ２１は、売り注文の総量が当該売り注文の商品に設定される閾値以下であるかを判断する（ＡＣＴ１５）。売り注文の総量が閾値以下であれば（ＡＣＴ１５、ＹＥＳ）、プロセッサ２１は、受信した変更要求に従って変更した売り注文を売り注文ＤＢ２６ａに登録（更新）する（ＡＣＴ１６）。変更要求に応じた売り注文の変更が成立した場合、プロセッサ２１は、当該変更要求の発信元である販売者端末へ売り注文の変更を受付けた旨を通知しても良い。

売り注文の総量が閾値を超える場合（ＡＣＴ１５、ＹＥＳ）、プロセッサ２１は、受信した変更要求に対するエラー処理を行う（ＡＣＴ１７）。プロセッサ２１は、エラー処理として、受信した変更要求をキャンセルしても良いし、閾値以下となる数量分の売り注文の変更を受付けるようにしても良い。エラー処理として変更要求をキャンセルする場合、プロセッサ２１は、当該変更要求の発信元である販売者端末３へ変更要求をキャンセルした旨を通知する。

また、エラー処理として閾値以下となる数量分の売り注文の変更を受付ける場合、プロセッサ２１は、閾値以下となる数量分の売り注文の変更を行う。たとえば、別の既注文数（登録済みの売り注文）が３００株、変更する注文数（変更要求に従って変更した場合の売り注文）が２０００株、かつ、閾値（１日辺りの生産数量）が１０００株である場合、プロセッサ２１は、受信した変更要求のうち７００株分の変更を受付ける。数量を減算して変更要求を受付けた場合、プロセッサ２１は、当該変更要求の発信元の販売者端末へ変更を受付けた数量（又はキャンセル（受付け不可）とした数量）を通知する。

また、買い注文を受信した場合（ＡＣＴ３１、ＹＥＳ）、プロセッサ２１は、受信した買い注文に所定の情報を付加した買い注文の注文データを第１の買い注文ＤＢ２６ｂに記録する（ＡＣＴ３２）。第１の取引期間中、プロセッサ２１は、売り注文の注文データを第１の売り注文ＤＢ２６ａに格納し、買い注文の注文データを第１の買い注文ＤＢ２６ｂに格納する。また、プロセッサ２１は、取引対象の商品ごとに注文データを集計した情報（買い注文数、売り注文数など）を注文ＤＢ２６に記録するようにしても良い。

図８は、第１の取引期間において、買い注文ＤＢ２６ｂに登録される注文データ（買い注文データ）の例である。図８に示す例は、取引方式（発注条件）として「板寄せ」が設定された購入者端末４からの買い注文を示す注文データとなっている。売り注文ＤＢ２６ａおよび買い注文ＤＢ２６ｂに格納された注文データは、第１の取引期間の注文期間終了後にマッチング処理される。

また、第１の取引期間において、プロセッサ２１は、販売者端末３または購入者端末４から注文状況についての閲覧要求を受け付ける（ＡＣＴ３３）。注文状況の閲覧要求を受信した場合（ＡＣＴ３３、ＹＥＳ）、プロセッサ２１は、注文ＤＢ２６に記録した注文データを対象として閲覧が要求された情報を出力する（ＡＣＴ３４）。これにより、販売者あるいは購入者は、取引サーバ２から提供される情報をもとに注文状況を把握することができる。また、販売者あるいは購入者は、取引サーバ２から提供される情報を参照して、注文状況に合わせて数量や価格を決定して注文をすることができる。

なお、プロセッサ２１は、注文状況として、全ての注文データに基づく注文状況だけではなく、条件に応じて制限した注文データに基づく情報を提供するようにしても良い。また、プロセッサ２１は、現在の取引に関係する情報だけでなく、過去の取引における注文状況や取引が成立した価格などの情報を提供するようにしても良い。

プロセッサ２１は、第１の取引期間における注文期間（予約期間）が終了すると（ＡＣＴ３５、ＹＥＳ）、注文の受付を終了する。注文の受付を終了すると、プロセッサ２１は、第１の取引期間中に受け付けた注文について一括して約定判定する（ＡＣＴ３６）。すなわち、プロセッサ２１は、売り注文ＤＢ２６ａに記録した売り注文と買い注文ＤＢ２６ｂに記録した買い注文とのマッチング処理を行う。

売り注文と買い注文とのマッチングは、予め定められたルールに従うものとする。たとえば、売り注文と買い注文とをマッチングさせる順番は、第１に注文価格、第２に受付した時間で定まるものとする。プロセッサ２１は、所定のルールに従って第１の取引期間内に受け付けた売り注文と買い注文とをマッチングさせ、取引の成立または不成立の判定（約定判定）を実行する。

約定判定の結果として取引が成立した注文があると、プロセッサ２１は、成立した取引内容を示す成約データを作成し、作成した成約データを成約ＤＢ２７に格納する（ＡＣＴ３７）。成約データを成約ＤＢ２７に格納すると、プロセッサ２１は、取引結果を各装置へ通知する（ＡＣＴ３８）。プロセッサ２１は、第１の取引期間中に受け付けた売り注文を出した販売者および買い注文を出した購入者にそれぞれ取引結果を通知する。

以上の処理を実行した後、プロセッサ２１は、第１の取引期間を終了する（ＡＣＴ３９）。上記処理によれば、成約ＤＢ２７には第１の取引期間における全ての成約データが格納され、生育ＤＢ２８には各成約データに対応する生育データの格納先が確保される。
なお、第１の取引期間中に受け付けた注文のうち取引が成立しなかった注文は第２の取引期間の注文として保持するようにしても良いし、破棄するようにしても良い。以下の説明では、第１の取引期間中に受け付けた注文のうち取引が成立しなかった注文は第２の取引期間の注文として保持するものとして説明する。

第１の取引期間が終了した後、取引サーバ２のプロセッサ２１は、第２の取引期間の注文開始日になると、第２の取引方式による注文の受付を開始する（ＡＣＴ４１）。本実施形態では、第２の取引期間中における第２の取引方式としてザラバ方式を想定するものとする。このため、第２の取引期間中において、プロセッサ２１は、注文を受けるごとに約定判定を実施する。

第２の取引期間中に販売者端末３から売り注文を受信した場合（ＡＣＴ４２、ＹＥＳ）、プロセッサ２１は、受信した売り注文と重複する売り注文が既に登録済みであるかを判断する（ＡＣＴ４３）。プロセッサ２１は、受信した売り注文の商品と一致する商品の売り注文が注文ＤＢ２６ｃに登録済みかを判断する。たとえば、プロセッサ２１は、受信した売り注文に対して、販売者、出荷日および品種（商品名）が同一の売り注文が売り注文ＤＢ２６ｃに存在するかを判断する。

重複する売り注文があると判断した場合（ＡＣＴ４３、ＹＥＳ）、プロセッサ２１は、受信した売り注文の数量（今回の注文数）と重複する全ての登録済みの売り注文の数量（既注文数）とを加算することによって売り注文の総量（合計注文数）を算出する（ＡＣＴ４４）。また、重複する売り注文が無いと判断した場合（ＡＣＴ４３、ＮＯ）、プロセッサ２１は、受信した売り注文の数量を売り注文の総量（合計注文数）とする。

売り注文の総量を算出すると、プロセッサ２１は、売り注文の総量が当該売り注文の商品に設定される閾値以下であるかを判断する（ＡＣＴ４５）。たとえば、ザラバ取引が当該商品（植物体）の播種後であることを想定している。植物工場では、播種後の出荷量が出荷日ごとに特定される。ザラバ取引の取引期間（第２の取引期間）において、各商品に設定される閾値は、当該商品に対する当該出荷日の出荷量から第１の取引期間で成約済みとなった数量を減算した値であるものとする。ここでは、出荷日ごとの出荷量は、顧客ＤＢ２４に販売者登録データとして登録される１日辺りの生産能力に基づく数量であるものとする。

なお、各商品（植物体）の出荷日ごとの出荷量は、播種後に顧客ＤＢ２４などのメモリに記憶されるものであっても良い。また、第２の取引期間において各商品に設定する閾値は、第１の取引期間終了後に当該出荷日の出荷量と第１の取引期間で成約済みとなった数量とから算出しても良い。この場合、第２の取引期間において各商品に設定する閾値は、顧客ＤＢ２４などのメモリに記憶しておくようにしても良い。

売り注文の総量が閾値以下である場合（ＡＣＴ４５、ＹＥＳ）、プロセッサ２１は、受信した売り注文を受付け、売り注文データとして第２の売り注文ＤＢ２６ｃに登録する（ＡＣＴ４９）。図９は、売り注文ＤＢ２６ｃに登録する注文データ（売り注文データ）の例である。図９に示す例では、取引方式（発注条件）として「ザラバ」が設定された販売者端末３からの売り注文を示す注文データとなっている。

売り注文の総量が閾値を超える場合（ＡＣＴ４５、ＹＥＳ）、プロセッサ２１は、受信した売り注文に対するエラー処理を行う（ＡＣＴ４６）。この場合、プロセッサ２１は、エラー処理として、受信した売り注文をキャンセルしても良いし、閾値以下となる数量分の売り注文を受付けるようにしても良い。売り注文をキャンセルする場合、プロセッサ２１は、当該売り注文の発信元である販売者端末３へ売り注文が数量オバーによりキャンセルする旨を通知する。

また、エラー処理として閾値以下となる数量分の売り注文を受付ける場合、プロセッサ２１は、閾値以下となる数量の売り注文として売り注文ＤＢ２６ｃに登録する。たとえば、既注文数が５００株、今回注文数が１５００株、かつ、当該商品の閾値が１０００株である場合、プロセッサ２１は、受信した注文（今回の注文）を５００株分の注文として受付ける。また、プロセッサ２１は、数量を減算して売り注文を受付けた場合、当該売り注文の発信元の販売者端末３へ受付けた数量（又はキャンセル（受付け不可）とした数量）を通知する。

また、取引サーバ２は、売り注文だけでなく、販売者端末３からの売り注文の変更（変更要求）を受け付けられるようにしても良い。ここでは、取引サーバ２は、変更内容が許容される内容であれば、変更要求に応じて売り注文ＤＢ２６ｃに登録済みの注文データを変更できるものとする。

販売者端末３から売り注文の変更（変更要求）を受信した場合（ＡＣＴ４７、ＹＥＳ）、受信した変更要求に従って変更した後の売り注文に対して重複する売り注文があるかを判断する（ＡＣＴ４３）。重複する売り注文があると判断した場合（ＡＣＴ４３、ＹＥＳ）、プロセッサ２１は、受信した変更要求に従って変更した後の売り注文の数量と重複する別の売り注文の数量とを加算することによって売り注文の総量（合計注文数）を算出する（ＡＣＴ４４）。また、重複する売り注文が無いと判断した場合（ＡＣＴ４３、ＮＯ）、プロセッサ２１は、受信した変更要求に従って変更した後の売り注文の数量を売り注文の総量（合計注文数）とする。

売り注文の総量を算出すると、プロセッサ２１は、売り注文の総量が当該売り注文の商品に設定される閾値以下であるかを判断する（ＡＣＴ４５）。売り注文の総量が閾値以下であれば（ＡＣＴ４５、ＹＥＳ）、プロセッサ２１は、受信した変更要求に従って変更した売り注文を売り注文ＤＢ２６ｃに登録（更新）する（ＡＣＴ４６）。

売り注文の総量が閾値を超える場合（ＡＣＴ４５、ＹＥＳ）、プロセッサ２１は、受信した変更要求に対するエラー処理を行う（ＡＣＴ４７）。プロセッサ２１は、エラー処理として、受信した変更要求をキャンセルしても良いし、閾値以下となる数量分の売り注文を受付けるようにしても良い。変更要求をキャンセルする場合、プロセッサ２１は、当該変更要求の発信元である販売者端末へ変更要求がエラーである旨を通知する。

また、エラー処理として閾値以下となる数量分の売り注文の変更を受付ける場合、プロセッサ２１は、閾値以下となる数量分の売り注文の変更を行う。たとえば、別の既注文数が３００株、変更する注文数（変更要求に従って変更した場合の売り注文）が２０００株、かつ、閾値が１０００株である場合、プロセッサ２１は、変更要求のうち７００株分の変更を受付ける。数量を減算して変更要求を受付けた場合、プロセッサ２１は、当該変更要求の発信元の販売者端末３へ変更を受付けた数量（又はキャンセル（受付不可）とした数量）を通知する。

また、購入者端末４からの買い注文を受信した場合（ＡＣＴ４８、ＹＥＳ）、プロセッサ２１は、受けた買い注文の内容に所定の情報を付加した注文データを生成して第２の買い注文ＤＢ２６ｄに記録する（ＡＣＴ４９）。図１０は、第２の買い注文ＤＢ２６ｄに格納する注文データ（買い注文データ）の例である。図１０に示す例は、取引方式（発注条件）として「ザラバ」が設定された購入者端末４からの買い注文を示す注文データとなっている。

買い注文ＤＢ２６ｄに注文データを登録した場合、売り注文ＤＢ２６ｃに注文データを登録した場合、或は、売り注文ＤＢ２６ｃの注文データを更新（変更）した場合、プロセッサ２１は、格納または更新した注文データに対する約定判定を行う（ＡＣＴ５０）。すなわち、プロセッサ２１は、第２の取引期間中において、販売者端末３からの売り注文または売り注文の変更要求、あるいは、購入者端末４からの買い注文を受け付ける毎に約定判定を実行する。

たとえば、売り注文ＤＢ２６ｃに注文データを登録または更新した場合、プロセッサ２１は、登録または更新された売り注文データを対象にして約定判定する。たとえば、プロセッサ２１は、当該売り注文に対し、買い注文ＤＢ２６ｄに登録されている未成約の買い注文との約定判定を行う。また、注文データ（買い注文データ）を買い注文ＤＢ２６ｄに登録した場合、プロセッサ２１は、当該買い注文データを対象にして約定判定する。プロセッサ２１は、当該買い注文データに対し、売り注文ＤＢ２６ｃに登録されている未成約の売り注文との約定判定を行う。

約定判定の結果として取引が成立（成約）すると、プロセッサ２１は、成約した内容を示す成約データを作成し、作成した成約データを成約ＤＢ２７に格納する（ＡＣＴ５１）。成約データを成約ＤＢ２７に格納すると、プロセッサ２１は、取引結果を各装置へ通知する（ＡＣＴ５２）。すなわち、プロセッサ２１は、成約した取引の売り注文を出した販売者および買い注文を出した購入者に取引結果を成約した取引内容を通知する。

また、プロセッサ２１は、第２の取引期間としての注文期間が終了すると（ＡＣＴ５３、ＹＥＳ）、第２の取引期間を終了する（ＡＣＴ５４）。第２の取引期間が終了した場合、プロセッサ２１は、成約に至らなかった注文を出した販売者および購入者へ取引が不成立となった旨を通知するようにしても良い。
なお、上述した取引処理の例では、第２の取引期間において、閲覧要求に応じた注文状況の情報公開を行う点を明示していない。しかし、取引サーバ２は、第２の取引期間においても、売り注文、買い注文および約定判定の結果（取引成立／不成立、価格、成立数）などの情報を公開するようにしても良い。

以上のように、実施形態に係る取引サーバは、売り注文または売り注文に対する変更要求を受信した場合、受信した売り注文と同じ商品の既注文があるかをチェックする。取引サーバは、同じ商品の既注文がなければ、受信した注文の数量が閾値以下であるかを判定し、同じ商品の既注文があれば、受信した注文の数量と既注文の数量とを加算した売り注文の総量が閾値以下であるかを判定する。取引サーバは、売り注文の総量が閾値以下であれば受信した注文に基づく売り注文データをデータベースに登録し、売り注文の総量が閾値を超えれば受信した売り注文に対するエラー処理を行う。

これより、本実施形態に係る取引サーバによれば、実際の生産能力または出荷量を超える売り注文を受付けないようにできる。また、取引サーバは、登録済みの売り注文の変更要求を受信した場合、実際の生産能力または出荷量を超える売り注文の変更を受付けないようにできる。

また、実施形態に係る取引サーバは、受信した注文の数量と既注文の数量とを加算した売り注文の総量が閾値を超える場合、受信した注文をキャンセル処理する。これにより、本実施形態によれば、実際の生産能力または出荷量を超える注文または変更を受付けないようにできる。

また、実施形態に係る取引サーバは、売り注文の総量が閾値を超える場合、受信した注文または変更のうち、閾値までの数量の注文または変更を登録し、閾値を超えた分の注文または変更をキャンセル処理する。これにより、実施形態によれば、実際の生産能力または出荷量に超える注文または変更を受信した場合、閾値までの数量分の注文または変更を受付けるようにできる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…取引システム、２…取引サーバ、３…販売者端末（端末装置）、４…購入者端末（端末装置）、２１…プロセッサ、２２…メモリ、２３…通信部、顧客データベース…２４、商品データベース…２５、注文データベース…２６、成約データベース…２７。

Claims (5)

1. 端末装置と通信する通信部と、
   前記端末装置からの売り注文に基づく売り注文データを記憶するデータベースと、
   前記端末装置から売り注文を受信した場合、受信した売り注文による商品の注文数量と前記データベースに登録済みの売り注文による当該商品の既注文の数量とを加算した売り注文の総量が閾値以下であるかを判定し、前記総量が閾値以下である場合には受信した売り注文に基づく売り注文データを前記データベースに記憶し、前記総量が閾値を超える場合にはエラー処理を行うプロセッサと、
   を有する取引サーバ。
2. 前記商品は、植物体であり、
   前記売り注文は、商品としての植物体を示す情報として、生産者、出荷日および品種を示す情報を含み、
   前記プロセッサは、生産者、出荷日および品種が受信した売り注文と一致する登録済みの売り注文の数量を前記既注文の数量とし、生産者、出荷日および品種が同じ売り注文の総量を判定する、
   請求項１に記載の取引サーバ。
3. 前記プロセッサは、前記端末装置から登録済みの売り注文に対する変更要求を受信した場合、受信した変更注文に従って変更した後の売り注文の総量を算出し、算出した総量が前記閾値以下であるかを判定する、
   請求項１又は２の何れか１項に記載の取引サーバ。
4. 前記プロセッサは、エラー処理として、受信した売り注文または登録済みの売り注文に対する変更要求をキャンセルする、
   請求項１乃至３の何れか１項に記載の取引サーバ。
5. 前記プロセッサは、エラー処理として、受信した売り注文による注文数量のうち前記閾値までの数量分で受信した売り注文を受付け、前記閾値を超える分の注文数量をキャンセルする、
   請求項１乃至３の何れか１項に記載の取引サーバ。