JP2013182352A - 参加せり情報処理装置および方法 - Google Patents

Abstract

【課題】希望した車両が購入できた以降の関係者の手間を軽減することを可能とした、出品物（中古車）のせり取引を行なうシステムに備えられる参加せり情報処理装置を提供することである。
【解決手段】提案する参加せり情報処理装置は、車両のせり取引を行なうせり応札端末の利用者の会員番号毎に、商談を希望する複数の購入希望車両のせりの情報を記憶した記憶部と、複数の購入希望車両のせりのうちの１つで落札したかどうかを判定する落札判定手段と、該落札判定手段により、せりの１つで車両が落札されたと判定された場合に、残りの購入希望車両のせりの流札時の商談希望をキャンセルする商談キャンセル手段と、を備える。
【選択図】図４

Description

本発明は、出品物（中古車）を出品する複数の出品者と複数の応札者とがネットワークを通してせり取引（オークション：auction）を行い、応札者が所望とする商品を応札するせりシステムに備えられる参加せり情報処理技術に関する。

中古車を出品物とするオークション取引がある。
このオークション取引は、主として業者が応札を行い、１台についてのオークションが平均１分程度で完結するものである。

全国では１００程度のオークション取引を行なう会場があり、平日（月〜金）の５日間で毎日ほぼ均等に分散して実施されることから、平日の１日に約２０会場で中古車オークションが行なわれていることになる。

このせりシステムは、出品者が出品する出品物（中古車）の情報（年式、車名、走行距離、画像（映像）など）を設定する１台以上の業務端末と、業務端末から設定された出品物（中古車）の情報を受信する業務サーバ・映像サーバと、業務サーバ・映像サーバからオークションの出品物の情報を取得し、当日のスケジュールに沿って、配下の複数のせり応札端末にブロードキャスト（同報）するせり制御装置と、を有する。

１台につき１分程度という短いオークション（せり）の実施時間においては、せり制御装置が出品物（中古車）の価格を決めて、現在価格情報として出品物情報と対応付けて配下の複数のせり応札端末にブロードキャストする。

そして、それら複数のせり応札端末のうちで、現在価格に応札したせり応札端末からの応札情報をカウントし、所定数以上の端末から応札情報を受信したかどうかを判断する。

例えば、１台以上のせり応札端末から応札情報を受信した場合、出品物の価格を一定額（例えば５０００円）加算して、その一定額が加算された価格を現在価格情報として出品物情報と対応付けて配下の複数のせり応札端末にブロードキャストする。これを約１分間のせり時間がオーバーするまで繰り返すか、または、上げた価格で応札する応札端末がなくなるまで繰り返す。そして、１つのせりが終了する。

最終的な応札価格が出品者の希望落札価格を上回った場合、そのせりは出品物（中古車）の落札という形で終了するが、最終的な応札価格が出品者の希望落札価格を下回った場合、そのせりは出品物（中古車）の流札という形で終了する。

通常は、せりに参加するに先立って、購入したい出品物（同一車種の中古車）が出品されるせりを絞り込んでおき、その絞り込んだ複数台の中古車が出品されるせりに対し、流札したときに購入できるように商談希望を依頼する。例えば次の（１）〜（５）に示すような流れである。
（１）購入したい出品物（中古車）にせり応札端末から応札を行なうがそのせりが希望落札価格に達せず終了したために流札となる。
（２）せりが流札となったために、商談で購入することが可能となり、出品者が商談担当者に流札となったせりについて、商談希望がある旨を連絡する。
（３）商談担当者が購入希望者（せり応札端末の利用者、会員）に商談可能である旨を連絡する。
（４）商談担当者が出品者と購入希望者の間に入り、交渉を行なう。この交渉の過程で、双方の希望額の提示、購入ＯＫ／ＮＧの連絡が行なわれる。
（５）商談担当者は、１つの流札となったせりにつき、商談リストを基に、その商談リストの先頭の者から順に、上記（３）、（４）を行ない、購入ＯＫとなった時点で、その流札となった１つのせりに対する商談が終了する。

せりへの参加者（会員）は通常、同一車種（車名）の車両（中古車）を１台購入できればよい、と考えるケースが多い。

そこで、商談や落札により希望する車種の車両が購入できた場合は、会員は事前に商談希望していた複数のせりのうちの残りのものについて、商談キャンセルの手続き、連絡を行なうことが必要になる。

しかし、購入希望者が自ら商談キャンセルの手続きを行なわなければならず、手間が発生している。

また、購入希望者が上記商談希望していた複数のせりのいずれかで落札するか、落札できずに商談で車両を購入した場合に、上記複数のせりの残りに対し、連絡を忘れて、商談担当者から購入希望者に連絡をとるという手間が発生している。

上記したように、１日ではかなりの数のせりが実施されていて、そのうちの１割が流札で終了するといわれる現状では、希望した車両が購入できた以降の関係者（せり応札端末を利用する会員、商談担当者）の手間を軽減するニーズは多い。

なお、周辺技術として、特許文献１では、インターネットを通して行なうネットオークションにおける処理方法として（オークション終了後の商談においてではなく、オークション時における処理方法として）、複数の商品を同一商品グループに設定し、同一商品グループに登録された商品が落札された場合に、同一商品グループに基づく入札を終了する技術が示されている。

特開２００５−２２８２３１号公報

本発明は、上記問題を解決するためになされたものであり、希望した車両が購入できた以降の関係者の手間を軽減することを可能とした、出品物（中古車）のせり取引を行なうシステムに備えられる参加せり情報処理装置および方法を提供することを目的とする。

提案する参加せり情報処理装置は、車両のせり取引を行なうせり応札端末の利用者の会員番号毎に、商談を希望する複数の購入希望車両のせりの情報を記憶した記憶部を備えた参加せり情報処理装置であり、複数の購入希望車両のせりのうちの１つで落札したかどうかを判定する落札判定手段と、該落札判定手段により、せりの１つで車両が落札されたと判定された場合に、残りの購入希望車両のせりの流札時の商談希望をキャンセルする商談キャンセル手段と、を備えるものである。

提案する参加せり情報処理装置では、落札判定手段により、せりの１つで車両が落札されたと判定された場合に、残りの購入希望車両のせりにおいて、その１つ以上の残りのせりの流札時の商談希望をキャンセルしているので、希望した車両が購入できた以降に、関係者（せり応札端末を利用する会員、商談担当者）間で人手による連絡をとる手間が省略でき、システム運営を一層効率化できる。

本発明の一実施形態に係る中古車のせり業務システムおよびせりシステムを含むせりの全体システムを示す図である。 本実施形態に係るせり応札端末の外観斜視図である。 本実施形態に係るせり応札端末のモニター部を上、正面、側面から見た図である。 業務サーバの機能ブロック図である。 出品物情報テーブルのデータ構造を示す図である。 会員毎参加希望せり情報テーブルのデータ構造を示す図である。 スケジュール・テーブルのデータ構造を示す図である。 出品物毎商談リストのデータ構造を示す図である。 検索要求パケットのデータ構造を示す図である。 検索結果パケットのデータ構造を示す図である。 フラグ設定情報パケットのデータ構造を示す図である。 次時間帯せり情報パケットのデータ構造を示す図である。 本実施形態に係る会員が指定した検索条件で業務サーバが行なう検索処理のフローチャートである。 せり制御装置の機能ブロック図である。 次時間帯せり情報テーブルのデータ構造を示す図である。 現在価格情報パケットのデータ構造を示す図である。 せり結果情報パケットのデータ構造を示す図である。 落札通知パケットのデータ構造を示す図である。 せり制御装置側のせり処理のフローチャートである。 せり応札端末の機能ブロック図である。 参加希望せり情報テーブルのデータ構造を示す図である。 表示位置情報テーブル、および、選択枠情報のデータ構造を示す図である。 せり応札情報パケットのデータ構造を示す図である。 せり応札端末側のせり応札処理のフローチャートである。 図１５ＡのステップＳ２５の詳細フローチャートである。 図１５ＡのステップＳ２６の詳細フローチャートである。 図１５ＡのステップＳ２７の詳細フローチャートである。 本実施形態に係るせり結果に基づき業務サーバが行なう商談キャンセル処理のフローチャートである。 図１６のステップＳ６８の商談リスト作成処理の詳細フローチャートである。 商談結果情報パケットのデータ構造を示す図である。 本実施形態に係る業務端末からの商談結果に基づき業務サーバが行なう商談キャンセル処理のフローチャートである。 参加希望せり情報テーブルのデータ構造（変形例：フラグ未設定時）を示す図である。 参加希望せり情報テーブルのデータ構造（変形例：フラグ設定時）を示す図である。

以下、本発明に係る実施の形態について図面を参照して詳細に説明する。
図１は、本発明の一実施形態に係る中古車のせり業務システムおよびせりシステムを含むせりの全体システムを示す図である。

図１に示すように、せりシステム１５の上流側に、出品者側せり業務システム１０がある。

出品者側せり業務システム１０は、ｍ台の業務端末１１−１、・・・、１１−ｍと、業務サーバ１２と、映像サーバ１３とを備える。

ｍ台の業務端末１１−１、・・・、１１−ｍから出品者により出品物（中古車）の各種情報が業務サーバ１２および映像サーバ１３にアップロードされる。

せりシステム１５は、ｎ台のせり応札端末１８−１、・・・、１８−ｎと、せり制御装置１６と、調整人端末（実際はレーン毎に設けられているが、ここでは、簡単に１台とする）１７と、せり会場内にせりの状況を表示する表示装置１９と、を備える。

せり業務システム１０とせりシステム１５の各装置は通信ネットワーク１４を通して接続されている。

図２は、本実施形態に係るせり応札端末の外観斜視図である。
図２に示すように、せり応札端末は、モニター部２１とコントローラ部３０とを備えている。

カードリーダ２３はモニター部２１の表示画面２９の下部に設けられ、利用者のクレジットカードなどの与信確認を、通信ネットワークを通して行なう。これにより、落札時のリアルタイム決済を実現する。

テンキーボード２４は、利用者がせり応札端末にログインするにあたり、利用者ＩＤ、暗証番号、等を入力するものである。

指示手段としてのマウス２５は、後述する検索条件指定時、検索要求送信時などにプルダウンメニュー（不図示）からの選択、送信ボタン（不図示）押下などに使用するものである。

また、モニター部２１の両脇に設けられた応札ボタン器具２２−１、２２−２の先端の応札ボタンを押下することで、表示画面２９の左側、右側のいずれか対応する側にせり情報が表示されているせりに対し応札ボタンが押下されたときの現在価格で応札することができる。

図３（ａ）は、本実施形態に係るせり応札端末のモニター部を上から見た図であり、図３（ｂ）は、モニター部を正面から見た図であり、図３（ｃ）は、モニター部を側面から見た図である。

図３（ｂ）に示すように、せり応札端末のモニター部２１の表示画面２９には、左右に２つのせり情報（連続した２レーン分のせり情報）を表示する表示枠２７、２８が設けられている。

なお、複数の中古車のせりが同一時間帯に実施される場合に、それら中古車のせりは複数のレーンで行なわれる、といわれる。

モニター部２１の両脇に設置された応札ボタン器具２２−１、２２−２のそれぞれ先端に設けられた応札ボタン２６−１、２６−２のいずれかを押下して、表示されている、２レーン分のせり情報のいずれかに応札可能としている。

例えば、８レーンのせりを同時に実施するせり会場の場合、図３（ａ）に示すテンキーボード２４のいずれかのキーに対応付けられたレーン切替ボタンを押下し続けることにより同一時間帯における８レーンのうち固定の２レーンの４組（ＡレーンとＢレーン、ＣレーンとＤレーン、ＥレーンとＦレーン、ＧレーンとＨレーン）を順次切り替えてディスプレイに表示することが可能である。これにより、同一時間帯に実施される複数のレーン（せり）への応札を可能としている。

せり情報表示枠２７を例にとり、表示される情報を説明すると、図３（ｂ）に示すように、上部には、レーン情報２７−１、出品番号２７−２、現在価格情報２７−３が表示され、中央部には、出品物に関する情報（車名、走行距離、など）のＰＤＦイメージ２７−４が表示され、下部には、出品物の画像情報（出品する中古車を斜め前方や斜め後方から写した静止画像など）２７−５が表示される。

図４は、業務サーバの機能ブロック図である。
図４に示すように、業務サーバ１２は、通信インターフェイス部３２、検索処理部３４、検索結果送信部３５、次時間帯せり情報送信部３６、フラグ設定情報受信部３７、せり結果情報受信部３８、商談結果情報受信部３９、メモリ４０、落札者用処理部４５、非落札者用処理部４６、商談リスト作成部４７、を備える。

記憶部であるメモリ４０には、出品物情報テーブル４１、会員毎参加希望せり情報テーブル４２、スケジュール・テーブル４３、出品物毎商談リスト４４、が記憶される。

出品物情報テーブル４１は、図５Ａに示すように、出品番号４１−１、スタート価格４１−２、希望落札価格４１−３、走行距離４１−４、車名４１−５、年式４１−６、評価点４１−７、色４１−８の各項目を有する。

図１の出品者側に設けられた業務端末１１−１、・・・、１１−ｍのそれぞれから出品物（中古車）に関する情報がこの出品物情報テーブル４１中に登録される。

会員は図１のせり応札端末１８−１、・・・、１８−ｎのいずれかからログインして、中古車のせりに参加するが、この際、参加するせりを絞り込むために、会員の検索条件に合う出品物を、業務サーバ１２が、この出品物情報テーブル４１から検索する。

具体的には、せり応札端末の検索条件指定画面（不図示）からマウス２５等により必要な指定を行い、その指定結果を、図６Ａに示すような検索要求パケット４８として業務サーバ１２に送信する。

図６Ａに示すように、検索要求パケット４８は、（検索要求であることを示す）パケットの識別情報４８−１、会員番号４８−２、スタート価格（例えば○○万円以下などとプルダウンメニューから選択）４８−３、（出品者側で出品物登録時に指定済みの）希望落札価格４８−４、走行距離（例えば○万Ｋｍ以下などとプルダウンメニューから指定）４８−５、車名（「車種」という場合もある。「プリウス」、「クラウン」、「アルト」などをプルダウンメニューから指定）４８−６、年式（例えば平成○年以降などと指定）４８−７、評価点（ここでは、５段階評価）４８−８、色（車体の色）４８−９、の各項目を備える。

検索要求パケット４８中の各項目は当然のこととして、検索条件を示すものである。
せり応札端末から検索要求パケット４８を業務サーバ１２が通信インターフェイス部３２を通して受信すると、検索要求パケット４８に指定された検索時の条件をキーとして、検索処理部３４が出品物情報テーブル４１を検索し、検索結果送信部３５が検索結果を、図６Ｂに示すような検索結果パケット４９として検索要求の送信元のせり応札端末に送信する。

図６Ｂに示すように、検索結果パケット４９は、（検索結果であることを示す）パケットの識別情報４９−１、出品物毎の出品物情報４９−１０−１、４９−１０−２、・・・のそれぞれが有する、出品番号４９−２、スタート価格４９−３、希望落札価格４９−４、走行距離４９−５、車名４９−６、年式４９−７、評価点４９−８、色４９−９、の各項目を備える。

なお、上記検索結果は、会員が当日参加したいせりを示している会員毎の情報であるので、他のデータとともに、会員毎参加希望せり情報テーブル４２に記憶される。換言すると、会員毎参加希望せり情報テーブル４２には、利用者の会員番号毎に、その会員番号の利用者が参加するせり情報が記憶されている。

図５Ｂに示すように、会員毎参加希望せり情報テーブル４２は、出品番号４２−１、年式４２−２、車名４２−３、走行距離４２−４、商談フラグ４２−５、グループフラグ４２−６、の各項目を備え、会員番号４５に紐付けられている。

なお、ここでは、例えば、年式「平成１０年以降」、車名「クラウン」、走行距離「５００００Ｋｍ以下」という条件で検索して得た結果を示している。正確には、図５Ａと同様の項目を備えるべきであるが、簡単のため省略した。

商談フラグとは、せりが流札になったときに出品物（中古車）を購入するための商談に参加希望するかどうかを決めるフラグである。また、グループフラグは、複数のせりを１つのグループとして設定するためのもので、そのグループ内のいずれか１つのせりで出品物が落札（購入）できた場合、残りのせりについて、商談をキャンセルする処理を実施可能とするために設けたものである。

商談フラグ、グループフラグは、後述する商談キャンセル処理を実行するために、業務サーバ１２側で設定する必要がある。

その設定方法（初期状態ではオフを示す「０（ゼロ）」に設定されている）としては、せり応札端末のモニター部２１を確認しつつ、マウス２５等で商談フラグ、グループフラグをオン（「１」）に変更し、その旨を、図６Ｃに示すように、フラグ設定情報パケット５１として業務サーバ１２に送信する。

図６Ｃは、フラグ設定情報パケットのデータ構造を示す図である。
図６Ｃに示すように、フラグ設定情報パケット５１は、（フラグ設定情報であることを示す）パケットの識別情報５１−１、会員番号５１−２、商談フラグ、グループ・フラグを共にオン（「１」）にした出品の数ｐだけ続く、出品番号５１−３−１、・・・、出品番号５１−３−ｐ、の各項目を備える。

図４の業務サーバ１２側では、このフラグ設定情報パケット５１は、通信インターフェイス部３２を通して、フラグ設定情報受信部３７に受信され、会員番号５１−２の値を持つ、会員毎参加希望せり情報テーブル４２の該当部分に書き込まれる。

流札になったせりに対して出品物を購入するために商談に参加を希望する場合、商談リストに登録することになる。商談リストは出品物毎に存在するので正確には出品物毎商談リストというべきである。

図５Ｄに示すように、出品物毎商談リスト４４は、商談に参加する際の優先順位を示す順位４４−１、会員番号４４−２、の２項目を備え、出品番号４４−３に紐付けられている。なお、「順位」は商談を行なう順番を示している。出品物毎商談リスト４４の先頭から常に商談を実施するものとすれば必要ない。

図４のせり結果情報受信部３８は、通信インターフェイス部３２を通して、図１０Ｂで後述するせり結果情報パケット６８をせり制御装置１６から受信し、後述する商談キャンセル処理を実行すべく、落札者用処理部４５、非落札者用処理部４６を起動する。

また、せり結果情報パケット６８を基に、後述するように、商談リスト作成部４７により、図５Ｄの出品物毎商談リスト４４が作成される。即ち、出品物毎商談リスト４４は、当該出品物のせりが終了した後に作成される。

利用者（会員）の便宜を図る上でも、当日のせりのスケジュールは必要である。スケジュール情報は、図５Ｃに示すようなスケジュール・テーブル４３として業務サーバ１２において管理し、例えば、当日のせり開始前に、せり制御装置１６やせり応札端末に送信して共用するようにしておく。

せりが実施される時間帯は例えば３０秒程度であるが、１つのせりの開始時刻と次のせりの開始時刻の間隔を例えば１分とし、その１分間について、せりが実施される時間帯として管理する。

これは、具体的には、○時○分から１分間、という時間帯であるが、簡単のため、時間帯を「１」、「２」、「３」、・・・と連続する番号で識別することにする。この取り決めだと、当然、せりとせりの間には３０秒の休みが挟まることになる。

正確には、「時間帯識別番号」というべきだが、簡単のため、以下では、単に「時間帯」と呼ぶことにする。そして、複数の中古車のせりが同一時間帯に実施される場合に、それら中古車のせりは複数のレーンで行なわれる、といわれる。

図５Ｃは、スケジュール・テーブルのデータ構造を示す図である。
図５Ｃに示すように、スケジュール・テーブル４３は、レーン毎にそれぞれの時間帯でどの出品番号の出品物が出品されるかを示すものである。

同一時間帯におけるせりのレーン数としては、１つの会場につき、図５Ｃでは、一会場８レーンの場合が示されているが、一般には、１つの会場でレーン数は８以外であってよいし、会場毎にレーン数は異なっていてよい。近年では１つの会場当たりのレーン数は増える傾向にある。

また、出品番号を全国で一元管理し、出品番号のみでせりを特定する方法、レーン情報を全国で一元管理し、レーン情報と出品番号の組み合わせでせりを特定する方法、会場のＩＤ、レーン情報、出品番号の組み合わせでせりを特定する方法、などがせりの情報を特定する方法として考えられ、そのいずれもが採用可能である。

図４の業務サーバ１２の説明に戻る。
本実施形態では、せり制御装置１６は、通信トラフィック等の関係から、当日実施される各レーンの各時間帯の各せりの情報を一括して業務サーバ１２から取得するのではなく、現在のせりを実施している間に、次の時間帯で各レーンで実施されるせりの情報をその都度、業務サーバ１２から取得する。

業務サーバ１２側での処理としては、スケジュール・テーブル４３を参照し、所定のタイミングで、次時間帯せり情報送信部３６が、図６Ｄに示すような次時間帯せり情報パケット５２をせり制御装置１６に送信することになる。

図６Ｄは、次時間帯せり情報パケットのデータ構造を示す図である。
図６Ｄに示すように、次時間帯せり情報パケット５２は、（次時間帯せり情報であることを示す）パケットの識別情報５２−１、時間帯の情報５２−２、レーン数ｎｌだけ続く、レーン情報、次の時間帯のせりの出品番号、スタート価格（レーン情報５２−３−１、次の時間帯のせりの出品番号５２−４−１、スタート価格５２−５−１、・・・、レーン情報５２−３−ｎｌ、次の時間帯のせりの出品番号５２−４−ｎｌ、スタート価格５２−５−ｎｌ）、の各項目を備える。

図７は、本実施形態に係る会員が指定した検索条件で業務サーバが行なう検索処理のフローチャートである。

図７のステップＳ１１で、検索処理部３４は、検索要求（検索要求パケット４８）を受信したかどうかを判定する。

ステップＳ１１で検索要求パケット４８を受信しないと判定される（ステップＳ１１の判定結果がＮｏである）間は、ステップＳ１１を繰り返す。

ステップＳ１１で検索要求パケット４８を受信したと判定された場合（ステップＳ１１の判定結果がＹｅｓの場合）、ステップＳ１２で、検索処理部３４により、受信した検索要求パケット４８に含まれる条件（パケットの識別情報４８−１、会員番号４８−２の２項目、を除く残りの項目に設定された有効な値の組み合わせ）をキーとして、出品物情報テーブル４１が検索され、ヒットしたレコードが検索結果として抽出される。

そして、ステップＳ１３で、検索処理部３４により、抽出された検索結果が、検索要求パケット４８に含まれる会員番号に紐付けられる形で、図５Ｂに示すような会員毎参加希望せり情報テーブル４２としてメモリ３８内に記憶される。なお、このテーブル４２は、出品を識別可能な情報が会員番号と対応付けられている限り、項目数は加減可能である。

続く、ステップＳ１４では、検索結果送信部３５により、抽出された検索結果（該当する出品物の情報）を含む（図６Ｂの）検索結果パケット４９が生成され、検索要求の送信元のせり応札端末に送信される。そして、ステップＳ１４の検索要求の受信待ち状態に戻る。

図８は、せり制御装置の機能ブロック図である。
図８に示すように、せり制御装置１６は、通信インターフェイス部５５、次時間帯判定部５６、次時間帯せり情報取得部５７、せりスタート判定部５８、現在価格情報送信部５９、せり応札情報受信部６１、せり結果情報送信部６２、メモリ６３、を備える。

メモリ６３内には、次時間帯せり情報テーブル６４が記憶される。この次時間帯せり情報テーブル６４は、図８には示されていないが、図６Ｄの次時間帯せり情報パケット５２をせり制御装置１６で受信したとき、その内容をメモリ６３内に記憶したものである。文字通り、「次の」時間帯のせり情報が分かればよいので、受信の都度、直近のもので上書きしている。記憶内容は、パケットの識別情報５２−１を除く全項目である。

図９に示すように、次時間帯せり情報テーブル６４は、レーン情報６４−１、出品番号６４−２、スタート価格６４−３、の各項目を備え、時間帯６４−４に紐付けられている。

上記したように、せり時間を３０秒程度とし、現在のせりと、次のせりの開始時刻の間隔を１分とすると、せりとせりの間には３０秒ほどの休みがあることになる。主として、この休みの時間中に、次時間帯判定部５６は、事前に業務サーバ１２から取得したスケジュール・テーブル（不図示）を参照して、例えば現在時刻との比較などから、次の時間帯にせりがあるかどうかを判定する。

次時間帯判定部５６が、次の時間帯にせりがあると判定した場合、次時間帯せり情報取得部５７が起動される。

次時間帯せり情報取得部５７は、図９の次時間帯せり情報テーブル６４を参照して、レーン毎に、次時間帯で実行されるせり処理のための準備処理を行なうべく、出品番号６４−２、スタート価格６４−３を取得する。

せりスタート判定部５８は、次時間帯のスタートを判定する。せりスタート判定部５８が次時間帯のせりがスタートしたと判定した場合、当然のことではあるが、「次時間帯」は「現時間帯」となる。

せりスタート判定部５８が次時間帯のせりがスタートしたと判定すると、当然のことではあるが、「次時間帯」は「現時間帯」となり、現在価格情報送信部５９、せり応札情報受信部６１、および、せり結果情報送信部６２との連携により、「現時間帯」のせり処理が実行される。

すなわち、現在価格情報送信部５９により、現在のレーンにおける出品物（中古車）の現在価格が、図１０Ａの現在価格情報パケット６７として、通信インターフェイス部５５を通して配下の各せり応札端末にブロードキャストされる。

図１０Ａは、現在価格情報パケットのデータ構造を示す図である。
図１０Ａに示すように、現在価格情報パケット６７は、（現在価格情報であることを示す）パケットの識別情報６７−１、レーン情報６７−２、出品番号６７−３、現在価格６７−４、の各項目を備える。

また、図８において、せり応札情報受信部６１は、せり応札端末から集められるせり応札情報パケット（図１４で後述）を受信したことに伴う処理を実行する。

具体的には、現在価格に応札したせり応札端末からのせり応札情報をカウントし、所定数以上の端末から応札情報を受信したかどうかを判断する。

例えば、１台以上のせり応札端末から応札情報を受信した場合、出品物の価格を一定額（例えば５０００円）加算して、その一定額が加算された価格を現在価格情報として出品物情報と対応付けて配下の複数のせり応札端末にブロードキャストする。これを約１分間のオークション時間がオーバーするまで繰り返すか、または、上げた価格で応札する応札端末がなくなるまで繰り返す。

このようにして、１つのオークションが終了すると、図８のせり結果情報送信部６２は、落札されたか、流札されたかを含む図１０Ｂに示すようなせり結果情報パケット６８を業務サーバ１２に送信する。

図１０Ｂは、せり結果情報パケットのデータ構造を示す図である。
図１０Ｂに示すように、せり結果情報パケット６８は、（せり結果情報であることを示す）パケットの識別情報６８−１、レーン情報６８−２、出品番号６８−３、その出品物に対する応札の数（延べ数（ｔとする）：同一せり応札端末からのダブリもカウント）だけ続く、会員番号、応札価格の組（会員番号６８−４−１、応札価格６８−５−１、・・・、会員番号６８−４−ｔ、応札価格６８−５−ｔ）、せり結果情報（「落札」または「流札」）６８−６、の各項目を備える。

また、本実施形態では、せり制御装置１６は、せり結果情報パケット６８を業務サーバ１２に送信したときに、配下の各せり応札端末に、図１０Ｃに示すような落札通知パケット６９をブロードキャストする。

図１０Ｃは、落札通知パケットのデータ構造を示す図である。
図１０Ｃに示すように、落札通知パケット６９は、（落札通知であることを示す）パケットの識別情報６９−１、出品番号６９−２、（落札者の）会員番号６９−３、の各項目を備える。なお、会員番号６９−３に有効な値（５桁の数字などフォーマットに整合するもの）が設定されている場合は、そのせりは落札されたものとして扱われ、無効な値（フォーマットに整合しない値）が設定されていた場合は、そのせりは流札したものとして扱われる。

図１１は、せり制御装置側のせり処理のフローチャートである。なお、このフローチャートの処理は、１つのレーンに注目して、そのレーン内でのせり処理を示すものである。全体としては、レーン数分の処理が並列に実行される。

図１１のステップＳ２１で、次時間帯判定部５６により、スケジュール・テーブル（図８では不図示）が参照されて、次の時間帯のせりがあるかどうかが判定される。

ステップＳ２１で次の時間帯のせりがないと判定された場合（ステップＳ２１の判定結果がＮｏの場合）、一連の処理を終了する。

ステップＳ２１で次の時間帯のせりがあると判定された場合（ステップＳ２１の判定結果がＹｅｓの場合）、ステップＳ２２で、業務サーバ１２から受信した対象レーン内の次の時間帯のせりの情報を、メモリ６３内の次時間帯せり情報テーブル６４から取得する。

そして、続く、ステップＳ２３で、せりスタート判定部５８により、次の時間帯のせりがスタートしたかどうかが判定される。

ステップＳ２３で次の時間帯のせりがスタートしていないと判定される限り（ステップＳ２３の判定結果がＮｏである間は）、ステップＳ２３の判定処理が繰り返される。

ステップＳ２３で次の時間帯のせりがスタートしたと判定された場合（ステップＳ２３の判定結果がＹｅｓである場合）、続くステップＳ２４で、現在価格情報送信部５９により、図１０Ａに示した出品番号と現在価格とを有する現在価格情報パケット６７が配下の各せり応札端末にブロードキャストされる。

そして、続く、ステップＳ２５で、せり応札情報受信部６１により、応札したせり応札端末のそれぞれから受信したせり応札情報パケット６８の数がカウントされる。

そして、ステップＳ２６で、せり応札情報受信部６１により、そのカウントした端末数が０（ゼロ）に等しいかどうかが判定される。

ステップＳ２６で端末数が０（ゼロ）に等しくないと判定された場合（ステップＳ２６の判定結果がＮｏの場合）、１台以上のせり応札端末から応札があったことになる。この場合、続く、ステップＳ２８で、タイムアウトかどうかが判定される。

ステップＳ２８でタイムアウトではないと判定された場合（ステップＳ２８の判定結果がＮｏの場合）、ステップＳ２９で、現在価格を所定額（例えば５０００円）アップして、ステップＳ２４に戻り、現在価格情報送信部５９により、そのアップした価格を現在価格とした現在価格情報パケット６７が配下の各せり応札端末にブロードキャストされる。

ステップＳ２８でタイムアウトと判定された場合（ステップＳ２８の判定結果がＹｅｓの場合）、ステップＳ３１で、現在価格が希望落札価格以上であるかどうかが判定される。

ステップＳ３１で現在価格が希望落札価格以上であると判定された場合（ステップＳ３１の判定結果がＹｅｓの場合）、ステップＳ３３に進む。

ステップＳ３１で現在価格が希望落札価格より小さいと判定された場合（ステップＳ３１の判定結果がＮｏの場合）、ステップＳ３２に進む。

一方、ステップＳ２６で端末数が０（ゼロ）に等しいと判定された場合（ステップＳ２６の判定結果がＹｅｓの場合）、ステップＳ２７でタイムアウトかどうかが判定される。

ステップＳ２７でタイムアウトではないと判定された場合（ステップＳ２７の判定結果がＮｏの場合）、ステップＳ２５に戻り、せり応札端末からの応札をカウントする。

ステップＳ２７でタイムアウトと判定された場合（ステップＳ２７の判定結果がＹｅｓの場合）、ステップＳ３０で、現在価格の１つ前の価格（ここでは、５０００円減算した価格）が希望落札価格以上であるかどうかが判定される。なお、現在価格がスタート価格の場合は、「現在価格の１つ前の価格」を「スタート価格」と読み替える。

ステップＳ３０で現在価格の１つ前の価格が希望落札価格以上であると判定された場合（ステップＳ３０の判定結果がＹｅｓの場合）、ステップＳ３３に進む。

ステップＳ３０で現在価格の１つ前の価格が希望落札価格より小さいと判定された場合（ステップＳ３０の判定結果がＮｏの場合）、ステップＳ３２に進む。

ステップＳ３０あるいはステップＳ３１のＹｅｓ判定から制御を渡されたステップＳ３３では、せり結果情報送信部６２により、図１０Ｂのせり結果情報パケット６８のせり結果情報６８−６に「落札」に相当する値がセットされ、業務サーバ１２に送信される。そして、ステップＳ２１に戻る。

ステップＳ３０あるいはステップＳ３１のＮｏ判定から制御を渡されたステップＳ３２では、せり結果情報送信部６２により、図１０Ｂのせり結果情報パケット６８のせり結果情報６８−６に「流札」に相当する値がセットされ、業務サーバ１２に送信される。そして、ステップＳ２１に戻る。

図１２は、せり応札端末の機能ブロック図である。
図１２に示すように、せり応札端末７０は、通信インターフェイス部７１、次時間帯判定部７２、次時間帯情報設定部７４、せりスタート判定部７５、応札処理部７８、応札情報送信部７９、現在価格情報受信部８１、メモリ８２、を備える。

メモリ８２には、スケジュール・テーブル８４（これは、図５Ｃのスケジュール・テーブル４３と同じものである）、参加希望せり情報テーブル８６（検索要求を行なった結果として受信したものである）、選択枠情報９１、表示位置情報テーブル８９、が記憶される。

図１３Ｂは、表示位置情報テーブル、および、選択枠情報のデータ構造を示す図である。

ここにいう、表示位置情報テーブルでは、スケジュール・テーブル８４を基に、次の時間帯（せりスタート後は「現時間帯」）で、それぞれが固定の表示位置を持っている各レーンにどのせりの情報（出品番号）を表示させるかを示すものである。

図１３Ｂに示すように、表示位置情報テーブル８９は、レーン情報８９−１、出品番号９１−２、現在価格８９−３の３項目を備える。

現在価格８９−３には当初、スタート価格が設定される。
なお、どの枠番号（選択枠）の左側はどのレーンを表示させ、右側はどのレーンを表示させるか、という固定した表示位置関係はメモリ８２内に別途保持されている。

図１３Ａに示すように、参加希望せり情報テーブル８６は、出品番号８６−１、年式８６−２、車名８６−３、走行距離８６−４、商談フラグ８６−５、グループフラグ８６−６、の各項目を備える。

上記したように、せり時間を３０秒程度とし、現在のせりの開始時刻と、次のせりの開始時刻の間隔を１分とすると、せりとせりの間には３０秒ほどの休みがあることになる。主として、この休みの時間中に、次時間帯判定部７２は、事前にせり制御装置１６から取得したスケジュール・テーブル８４を参照して、例えば現在時刻との比較などから、次の時間帯にせりがあるかどうかを判定する。

次時間帯判定部７２が、次の時間帯にせりがあると判定した場合、次時間帯情報設定部７４が起動される。

次時間帯情報設定部７４は、スケジュール・テーブル８４の記憶内容から次の時間帯に各レーンで実施されるせりについての情報（出品番号、スタート価格）を図１３Ｂの表示位置情報テーブル８９に設定する。また、選択枠情報９１に初期値（例えば「１」）を設定する。

せりスタート判定部７５は、次時間帯のスタートを判定する。せりスタート判定部７５が次時間帯がスタートしたと判定した場合、当然のことではあるが、「次時間帯」は「現時間帯」となる。

せりスタート判定部７５が次時間帯のせりがスタートしたと判定すると、「次時間帯」は「現時間帯」となり、応札処理部７８、応札情報送信部７９、および、現在価格情報受信部８１との連携により、「現時間帯」のせり応札処理が実行される。

すなわち、画面表示更新処理部７８−１とせり情報の選択枠切替部７８−２、モニター部２１の左側側面に設置される左側応札ボタン器具７８−３、右側側面に設置される右側応札ボタン器具７８−４を備える応札処理部７８において、画面表示更新処理部７８−１が、せり制御装置１６から次々と送信されてくる現在価格情報パケット６７の内容で、画面上のせり情報表示枠の表示内容を順次更新する。

また、選択枠切替部７８−２は、右向き矢印ボタンや左向き矢印ボタンであり、それら矢印ボタンを利用者（会員）がせり応札端末で押下することで、８レーン（Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ）中から固定で決まられた２レーンの４組（（Ａ、Ｂ）（Ｃ、Ｄ）（Ｅ、Ｆ）（Ｇ、Ｈ））のどれを表示するかを切り替えるものである。

図１３Ｂ（ｂ）に示す選択枠情報９１は、モニター部２１の表示画面２９上に表示すべき、選択枠情報（枠番号）を表示していて、これは、例えば次のような固定の対応関係が設定されている。

枠番号「１」・・・Ａレーンを画面左側に表示し、Ｂレーンを画面右側に表示。
枠番号「２」・・・Ｃレーンを画面左側に表示し、Ｄレーンを画面右側に表示。
枠番号「３」・・・Ｅレーンを画面左側に表示し、Ｆレーンを画面右側に表示。
枠番号「４」・・・Ｇレーンを画面左側に表示し、Ｈレーンを画面右側に表示。

例えば、右向き矢印ボタン押下の場合、枠番号を１つだけインクリメントする（ただし、枠番号「４」をインクリメントすると、枠番号「１」になるものとする）。

また、左向き矢印ボタン押下の場合、枠番号を１つだけデクリメントする（ただし、枠番号「１」をデクリメントすると、枠番号「４」になるものとする）。

また、現在選択されている枠で、上記した枠番号とレーンとの固定の関係を基に、現時間帯における各レーンのせりの情報が表示画面の左側、右側にそれぞれ表示される。

そして、左側応札ボタン器具７８−３の応札ボタンが押下されたか、右側応札ボタン器具７８−４の応札ボタンが押下されたかに応じて、どのレーンのせりに応札したかが決まる。

応札したレーン（せり）に対しては、そのときの現在価格が設定された、図１４に示すようなせり応札情報パケット１０１が応札情報送信部７９により作成され、せり制御装置１６に送信される。

図１４は、せり応札情報パケットのデータ構造を示す図である。
図１４に示すように、せり応札情報パケット１０１は、（せり応札情報であることを示す）パケットの識別情報１０１−１、（応札した）レーン情報１０１−２、出品番号１０１−３、会員番号１０１−４、応札価格（応札したときの現在価格）１０１−５、の各項目を備える。

また、図１２において、現在価格情報受信部８１は、せり制御装置１６からの図１０Ａの現在価格情報パケット６７をせりスタートとともに受信して、その現在価格情報パケット６７に含まれる出品番号をキーとして、表示位置情報テーブル８９を検索し、ヒットした行の現在価格８９−３の値を、その現在価格情報パケット６７に含まれる現在価格６７−４に設定された値で上書きする。

図１５Ａは、本実施形態に係るせり応札端末側のせり応札処理のフローチャートである。

図１５ＡのステップＳ４１で、参加レーンの設定が行なわれる。ここでは、上述したように、検索要求パケットが業務サーバ１２に送信され、検索結果パケットを受け取り、参加希望せり情報テーブル８６に格納される。その後、必要に応じて、上記したように、商談フラグ、グループフラグの設定が行なわれる。

なお、レーンと出品番号を直接プルダウンメニューなどから指定してもよい。この場合、業務サーバ１２に対して、検索要求パケットの代わりに、指定された複数のレーン番号、出品番号の組に対し、せりの情報を取得するためのせり情報取得パケットを送信することになる。

続く、ステップＳ４２では、次時間帯判定部７２によりスケジュール・テーブル８４が参照されて、次の時間帯のせりがあるかどうかが判定される。

ステップＳ４２で次の時間帯のせりがないと判定された場合（ステップＳ４２の判定結果がＮｏの場合）、一連の処理を終了する。

ステップＳ４２で次の時間帯のせりがあると判定された場合（ステップＳ４２の判定結果がＹｅｓの場合）、ステップＳ４３で、次時間帯情報設定部７４により、スケジュール・テーブル８４の記憶内容から次の時間帯に各レーンで実施されるせりについての情報（出品番号、現在価格）が図１３Ｂの表示位置情報テーブル８９に設定される。また、選択枠情報９１に初期値（例えば「１」）が設定される。

続く、ステップＳ４４では、せりスタート判定部７５により、次の時間帯のせりがスタートしたかどうかが判定される。

ステップＳ４４で次の時間帯のせりがスタートしていないと判定される限り（ステップＳ４４の判定結果がＮｏである間は）、ステップＳ４４の判定処理が繰り返される。

ステップＳ４４で次の時間帯のせりがスタートしたと判定された場合（ステップＳ４４の判定結果がＹｅｓである場合）、続くステップＳ４５で、画面表示更新処理部７８−１により、選択枠情報９１が参照されて、画面表示で、選択枠情報９１に設定されている値に応じて、表示画面の左側に表示すべきレーン（せり）の情報と、右側に表示すべきレーン（せり）の情報とが更新される。

続く、ステップＳ４６では、選択枠切替部７８−２により表示画面２９に表示すべき枠番号の値の切替が利用者（会員）の矢印ボタン押下の有無検出という形で行なわれる。

続く、ステップＳ４７では、そのとき、表示画面２９の左側・右側に表示されているせりの情報において、左側応札ボタン器具７８−３の応札ボタンが押下されたか、右側応札ボタン器具７８−４の応札ボタンが押下されたかに応じて、所望とするせりに応札する応札処理（具体的には、応札ボタン押下検出処理）が行なわれる。

そして、ステップ４８では、タイマー（不図示）により、現時間帯のせりがタイムアウトになったかどうかが判定される。

ステップＳ４８で現時間帯のせりがタイムアウトになっていないと判定された場合（ステップＳ４８の判定結果がＮｏの場合）、ステップＳ４５に戻る。

ステップＳ４８で現時間帯のせりがタイムアウトになったと判定された場合（ステップＳ４８の判定結果がＹｅｓの場合）、ステップＳ４２に戻る。

図１５Ｂは、図１５ＡのステップＳ４５の詳細フローチャートである。画面表示更新処理部７８−１によるこのような画面表示の更新処理を行なうことで、選択枠情報９１に設定された枠番号に相当する各レーン（各せり）の情報が表示画面２９の左側、右側にそれぞれ直近の価格情報で更新されて表示されることになる。

図１５ＡのステップＳ４４のＹｅｓ判定、あるいは、ステップＳ４８のＮｏ判定から図１５ＢのステップＳ４５−１に制御が渡される。

ステップＳ４５−１では、図１３Ｂの選択枠情報９１の値が参照され、その値に応じて分岐先が決まる。

すなわち、選択枠情報９１の値が「１」の場合、ステップＳ４５−２で、Ａレーン、Ｂレーンをそれぞれ表示画面２９の左側、右側とし、図１３Ｂの表示位置情報テーブル８９の現在価格８９−３に設定される表示対象となっている出品物の直近の価格情報で更新し、ステップＳ４６に進む。

また、選択枠情報９１の値が「２」の場合、ステップＳ４５−２で、Ｃレーン、Ｄレーンをそれぞれ表示画面２９の左側、右側とし、図１３Ｂの表示位置情報テーブル８９の現在価格８９−３に設定される表示対象となっている出品物の直近の価格情報で更新し、ステップＳ４６に進む。

また、選択枠情報９１の値が「３」の場合、ステップＳ４５−３で、Ｅレーン、Ｆレーンをそれぞれ表示画面２９の左側、右側とし、図１３Ｂの表示位置情報テーブル８９の現在価格８９−３に設定される表示対象となっている出品物の直近の価格情報で更新し、ステップＳ４６に進む。

また、選択枠情報９１の値が「４」の場合、ステップＳ４５−４で、Ｇレーン、Ｈレーンをそれぞれ表示画面２９の左側、右側とし、図１３Ｂの表示位置情報テーブル８９の現在価格８９−３に設定される表示対象となっている出品物の直近の価格情報で更新し、ステップＳ４６に進む。

図１５Ｃは、図１５ＡのステップＳ４６の詳細フローチャートである。
図１５ＡのステップＳ４５から制御を渡された図１５ＣのステップＳ４６−１では、選択枠切替部７８−２の構成要素としての右向き矢印ボタンが押下されたかどうかが判定される。

ステップＳ４６−１で右向き矢印ボタンが押下されたと判定された場合（ステップＳ４６−１の判定結果がＹｅｓの場合）、ステップＳ４６−２で、選択枠情報９１に記憶される値を１つだけインクリメントする（「１」ならば「２」、「２」ならば「３」、「３」ならば「４」、「４」ならば「１」）。そして、ステップＳ４６−３に進む。

ステップＳ４６−１で右向き矢印ボタンが押下されていないと判定された場合（ステップＳ４６−１の判定結果がＮｏの場合）、直ちに、ステップＳ４６−３に進む。

ステップＳ４６−３では、選択枠切替部７８−２の構成要素としての左向き矢印ボタンが押下されたかどうかが判定される。

ステップＳ４６−３で左向き矢印ボタンが押下されたと判定された場合（ステップＳ４６−３の判定結果がＹｅｓの場合）、ステップＳ４６−４で、選択枠情報９１に記憶される値を１つだけデクリメントする（「１」ならば「４」、「２」ならば「１」、「３」ならば「２」、「４」ならば「３」）。そして、図１５ＡのステップＳ４７に進む。

ステップＳ４６−３で左向き矢印ボタンが押下されていないと判定された場合（ステップＳ４６−３の判定結果がＮｏの場合）、直ちに、図１５ＡのステップＳ４７に進む。

図１５Ｄは、図１５ＡのステップＳ４７の詳細フローチャートである。
図１５ＡのステップＳ４６から制御を渡された図１５ＤのステップＳ４７−１では、モニター部２１の左側側面に設置された左側応札ボタン器具７８−３の先端の応札ボタンが押下されたかどうかが判定される。

ステップＳ４７−１で左側応札ボタン器具７８−３の応札ボタンが押下されたと判定された場合（ステップＳ４７−１の判定結果がＹｅｓの場合）、ステップＳ４７−２で、対応するせりに対する応札情報（せり応札情報パケット１０１）をせり制御装置１６に送信する（例えば、選択枠情報９１に値「１」が設定されていれば、Ａレーンで実施されているせりの情報である）。そして、ステップＳ４７−３に進む。

ステップＳ４７−１で左側応札ボタン器具７８−３の応札ボタンが押下されていないと判定された場合（ステップＳ４７−１の判定結果がＮｏの場合）、直ちに、ステップＳ４７−３に進む。

ステップＳ４７−３では、モニター部２１の右側側面に設置された右側応札ボタン器具７８−４の先端の応札ボタンが押下されたかどうかが判定される。

ステップＳ４７−３で右側応札ボタン器具７８−４の応札ボタンが押下されたと判定された場合（ステップＳ４７−３の判定結果がＹｅｓの場合）、ステップＳ４７−４で、対応するせりに対する応札情報（せり応札情報パケット１０１）をせり制御装置１６に送信する（例えば、選択枠情報９１に値「１」が設定されていれば、Ｂレーンで実施されているせりの情報である）。そして、図１５ＡのステップＳ４８に進む。

ステップＳ４７−３で右側応札ボタン器具７８−４の応札ボタンが押下されていないと判定された場合（ステップＳ４７−３の判定結果がＮｏの場合）、直ちに、図１５ＡのステップＳ４８に進む。

上述したように、本実施形態では、希望した車両が購入できた以降の関係者（せり応札端末を利用する会員、商談担当者）の手間を軽減することを課題としている。

システム上で商談フラグを設定するタイミングとしては、代表的には、各せりの開始時刻前に、当日参加するせりについて商談フラグをせり応札端末上からオン（「１」）に設定することが考えられる。以下に、図１６を参照しつつ説明する。

図１６は、本実施形態に係るせり結果に基づき業務サーバが行なう商談キャンセル処理のフローチャートである。このフローチャートの処理は、図４のせり結果情報受信部３８、落札者用処理部４５、非落札者用処理部４６、および、商談リスト作成部４７がメモリ４０内の必要な情報にアクセスして実行する。

図１６のステップＳ６１で、せり結果情報受信部３８により、せり制御装置１６から図１０Ｂのせり結果情報パケット６８を受信したかどうかが判定される。

ステップＳ６１でせり結果情報パケット６８を受信していないと判定される間（ステップＳ６１の判定結果がＮｏである間）は、ステップＳ６１の判定処理が繰り返される。

ステップＳ６１でせり結果情報パケット６８を受信したと判定された場合（ステップＳ６１の判定結果がＹｅｓである場合）、ステップＳ６２で、せり結果情報受信部３８がせりに参加した会員のリストを作成する。例えば、図１０Ｂのせり結果情報パケット６８において、会員番号６８−４−１、・・・、６８−４−ｔを先頭からダブリを排除して会員リストを作成すればよい。

続く、ステップＳ６３では、せり結果情報受信部３８により、生成した会員リストにおいて、次の位置はあるかどうかが判定される。なお、初回にステップＳ６３が実行される場合、「次の位置」は「先頭位置のレコード」と読み替えるものとする。

ステップＳ６３で次の位置はないと判定された場合（ステップＳ６３の判定結果がＮｏの場合）、そのせりでは誰も応札せず、生成した会員リストにも誰の会員番号も含まれていないか、または、すでにこの図１６のフローの後続のステップを何回か繰り返し、リストの次の位置に会員番号がなくなった場合が考えられる。この場合、せり結果情報受信部３８は、ステップＳ６１のせり結果情報パケット６８の受信待ち状態に戻る。

ステップＳ６３で次の位置に会員番号があると判定された場合（ステップＳ６３の判定結果がＹｅｓの場合）、ステップＳ６４で、せり結果情報受信部３８は、ステップＳ６２で作成した会員リストの次の会員（番号）を取得する。

そして、ステップＳ６５で、せり結果情報受信部３８により、ステップＳ６４で取得した会員番号の会員が希望車種を落札できたかどうかが判定される。具体的には、ステップＳ６４で取得した会員番号と、ステップＳ６１で今回受信した、図１０Ｂのせり結果情報パケット６８のせり結果情報６８−６に設定される会員番号とを比較する。

即ち、せり結果情報受信部３８は、購入希望車両のせりの１つで希望車両を落札したか否かを判定する落札判定手段として機能する。

ステップＳ６５で希望車種を（自分が）落札できたと判定された場合（ステップＳ６５の判定結果がＹｅｓの場合）、すなわち、ステップＳ６４で取得した会員番号と、ステップＳ６１で今回受信したせり結果情報パケット６８のせり結果情報６８−６の会員番号とが一致した場合、ステップＳ７０で、落札者用処理部４５がその会員番号に紐付けられた、図５Ｂの会員毎参加希望せり情報テーブル４２に対し、グループ登録された車種（車名）をキャンセル扱いとする。

具体的には、落札者用処理部４５は、グループフラグがオン（「１」）に設定されているすべてのレコードについて、商談フラグとグループフラグの項目の値をすべてオフ（「０（ゼロ）」）に設定する。そして、ステップＳ６３に戻る。

即ち、落札者用処理部４５は、落札判定手段であるせり結果情報受信部３８により購入希望車両のせりの１つで希望車両を落札したと判定された場合に、落札したせりと同グループとして登録されている残りの購入希望車両のせりに関する流札時の商談希望をキャンセルする商談キャンセル手段として機能する。

ステップＳ６５で希望車種を落札できなかったと判定された場合（ステップＳ６５の判定結果がＮｏの場合）、すなわち、ステップＳ６４で取得した会員番号と、ステップＳ６１で今回受信したせり結果情報パケット６８のせり結果情報６８−６の会員番号とが一致しない場合、ステップＳ６７で、非落札者用処理部４７により、希望車種は他の落札者がいる車かどうかが判定される。すなわち、今回受信したせり結果情報パケット６８のせり結果情報６８−６の会員番号に有効な値が設定されているかどうかが判定される。

ステップＳ６７で希望車種は（自分でない）他の落札者がいる車であると判定された場合（ステップＳ６７の判定結果がＹｅｓの場合）、すなわち、今回受信したせり結果情報パケット６８のせり結果情報６８−６の会員番号に有効な値が設定されていた場合、ステップＳ６９で、ステップＳ６４で取得した会員番号に紐付けられた、図５Ｂの会員毎参加希望せり情報テーブル４２に対し、結果情報パケット６８の出品番号６８−３の行の商談フラグ４２−５の値をオフ（「０（ゼロ）」）にし、ステップＳ６３に戻る。

ステップＳ６７で希望車種は他の落札者がいない車であると判定された場合（ステップＳ６７の判定結果がＮｏの場合）、すなわち、今回受信したせり結果情報パケット６８のせり結果情報６８−６の会員番号に無効な値が設定されていた場合、ステップＳ６８で、図４の商談リスト作成部４７により、商談リスト作成処理が実行され、ステップＳ６３に戻る。

図１７は、図１６のステップＳ６８の商談リスト作成処理の詳細フローチャートである。

図１６のステップＳ６７から制御を渡された図１７のステップＳ６８−１では、図１６のステップＳ６１で今回受信した、図１０Ｂのせり結果情報パケット６８のせり結果情報６８−６の値が無効であるかどうかが判定される。

ステップＳ６８−１でせり結果情報６８−６の値が無効ではないと判定された場合（ステップＳ６８−１の判定結果がＮｏの場合）、図１６のステップＳ６１に戻る。

ステップＳ６８−１でせり結果情報６８−６の値が無効であると判定された場合（ステップＳ６８−１の判定結果がＹｅｓの場合）、このせりは流札であったことになり、続く、ステップＳ６８−２で、図１０Ｂのせり結果情報パケット６８の末尾の会員番号６８−４−ｔを取得する。

そして、その取得した会員番号６８−４−ｔに紐付けられた、図５Ｂの会員毎参加希望せり情報テーブル４２において、結果情報パケット６８の出品番号６８−３の行の商談フラグ４２−５の値がオン（「１」）であれば、図５Ｄの出品物毎商談リスト４４の先頭行の会員番号４４−２の項目に、その会員番号６８−４−ｔの値を設定する。

なお、ステップＳ６８−２で、図５Ｄに示すように、結果情報パケット６８の出品番号６８−３の値を図５Ｄの出品物毎商談リスト４４の出品番号４４−３に設定する。

そして、続く、ステップＳ６８−３で、（図１０Ｂのパケット６８内の会員番号の）現在位置は先頭であるか（これより前には、パケットの識別情報６８−１、レーン情報６８−２、出品番号６８−３のみあるか）が判定される。

ステップＳ６８−３で現在位置は先頭であると判定された場合（ステップＳ６８−３の判定結果がＹｅｓの場合）、処理しているパケット６８においてこれ以上取得できる会員番号はなくなるので、図１６のステップＳ６１に戻る。

ステップＳ６８−３で現在位置は先頭ではないと判定された場合（ステップＳ６８−３の判定結果がＮｏの場合）、ステップＳ６８−４で、パケット６８の会員番号の現在位置から先頭方向に１つさかのぼった会員番号６８−４−ｋ（ｋは１以上、ｔ−１以下）を取得する。

そして、ステップＳ６８−５で、取得した会員番号が現在作成中の図５Ｄの出品物毎商談リスト４４に含まれているかどうかが判定される。

ステップＳ６８−５で取得した会員番号が現在作成中の商談リスト４４に含まれていると判定された場合（ステップＳ６８−５の判定結果がＹｅｓの場合）、ステップＳ６８−３に戻る。

ステップＳ６８−５で取得した会員番号が現在作成中の商談リスト４４に含まれていないと判定された場合（ステップＳ６８−５の判定結果がＮｏの場合）、ステップＳ６８−６で、その取得した会員番号６８−４−ｋに紐付けられた、図５Ｂの会員毎参加希望せり情報テーブル４２において、結果情報パケット６８の出品番号６８−３の行の商談フラグ４２−５の値がオン（「１」）であれば、図５Ｄの出品物毎商談リスト４４に、会員番号４４−２の項目に、その会員番号６８−４−ｔの値を設定した行（レコード）を追加する。そして、ステップＳ６８−３に戻る。

なお、商談キャンセル処理を行なうタイミングとしては、この他に、流札したせりにおける出品物に対して商談を実施して会員が出品物（中古車）を購入するケースが考えられる。

この場合、図１８に示すような商談結果情報パケット１０２が業務端末から業務サーバ１２に送信されることになる。

図１８は、商談結果情報パケットのデータ構造を示す図である。
図１８に示すように、商談結果情報パケット１０２は、（商談結果情報であることを示す）パケットの識別情報１０２−１、出品番号１０２−２、（出品物を購入した会員の）会員番号１０２−３、の３項目を備える。

図１９は、本実施形態に係る業務端末からの商談結果に基づき業務サーバが行なう商談キャンセル処理のフローチャートである。

図１９のステップＳ８１で、図４の商談結果情報受信部３９により、業務端末から図１８の商談結果情報パケット１０２を受信したかどうかが判定される。

ステップＳ８１で商談結果情報パケット１０２を受信していないと判定される間（ステップＳ８１の判定結果がＮｏである間）は、ステップＳ８１の判定処理が繰り返される。

ステップＳ８１で商談結果情報パケット１０２を受信したと判定された場合（ステップＳ８１の判定結果がＹｅｓである場合）、ステップＳ８２で、図１８の商談結果情報パケット１０２の（購入者の）会員番号１０２−３が取得される。

そして、続く、ステップＳ８３で、その取得された会員番号１０２−３に紐付けられた、図５Ｂの会員毎参加希望せり情報テーブル４２に対し、グループ登録された車種（車名）に対する商談をキャンセル扱いとする。

すなわち、グループフラグがオン（「１」）に設定されているすべてのレコードについて、商談フラグとグループフラグの項目の値をすべてオフ（「０（ゼロ）」）に設定する。そして、ステップＳ８１に戻る。

なお、以上の説明では、せり応札端末側から会員が商談フラグを事前にオンにすることで、せりが実施される前のタイミングで、各せりが流札になったとき商談に参加するかどうかを決めていた。

以下に、本実施形態の変形例として、商談フラグの設定タイミングを各せりの実施後とした場合の商談キャンセル処理について説明する。

図２０Ａおよび図２０Ｂは、本実施形態の変形例における参加希望せり情報テーブルのデータ構造（変形例：フラグ未設定時）を示す図である。

図２０Ａおよび図２０Ｂを参照すると、図１３Ａに示す参加希望せり情報テーブル８６と比較し、せり結果１０３−７の項目が追加されている。

図１０Ｃの落札通知パケット６９がせり制御装置１６から配下の各せり応札端末にブロードキャストされると、本変形例では、その落札通知パケット６９を受信したせり応札端末は、落札通知パケット６９の出品番号６９−２が自端末の図１３Ａの参加希望せり情報テーブル８６に含まれているかどうかを判定する。

落札通知パケット６９の出品番号６９−２がテーブル８６に含まれていないと判定された場合、その受信した落札通知パケット６９は破棄される。

落札通知パケット６９の出品番号６９−２がテーブル８６に含まれていると判定された場合、落札通知パケット６９の（落札者の）会員番号６９−３に設定された値を参照して、図２０Ａの参加希望せり情報テーブル１０３のせり結果１０３−７に反映させる。

例えば、その会員番号６９−３に設定された値が有効な値（会員番号のフォーマットを満たしている値（５桁の数字であるなど））であり、自端末にログインしている会員の会員番号と異なっていれば、数字を「＊＊＊＊＊」などと化けさせて画面２９上に（せり参加時の画面表示モード以外の）該当する表示モードのときに表示させる。

自端末にログインしている会員の会員番号と一致していれば、その会員番号を示す数字をそのまま画面２９上に該当する表示モードのときに表示させる。

一方、その会員番号６９−３に設定された値が無効な値であれば、そのせりは流札になったということを示している。この場合、本変形例の参加希望せり情報テーブルの該当する行（レコード）のせり結果１０３−７の欄に「流札」と表示される。

例えば、図２０Ａでは、参加を希望したせり１０件がすべて終了した時点で、参加を希望したせり１０件のうちの３件（出品番号「０００４」、「００２６」、「００２９」にそれぞれ該当するもの）が流札となっている。

そして、本変形例では、流札となったせりに対してのみ、せり実施後の「商談フラグ」、「グループフラグ」の設定（入力）が可能となるように入力機能を制限している。

図２０Ａの参加希望せり情報テーブル１０３に対し、「商談フラグ」、「グループフラグ」を設定したものが図２０Ｂの参加希望せり情報テーブル１０３である。

この場合、図１９のフローチャートに示した方法で業務端末からの商談結果に基づき業務サーバが商談キャンセル処理を実行することになる。この場合、すでに出品物毎商談リスト４４が作成されている可能性があるため、参加希望せり情報テーブル１０３に加えて出品物毎商談リスト４４も更新することが望ましい。

以上説明したように、本実施形態によれば、落札判定手段（図４のせり結果情報受信部３８および落札者用処理部４５）により、せりの１つで車両が落札されたと判定された場合に、残りの購入希望車両のせりにおいて、その１つ以上の残りのせりの流札時の商談希望をキャンセルしているので、希望した車両が購入できた以降に、関係者（せり応札端末を利用する会員、商談担当者）間で人手による連絡をとる手間が省略でき、システム運営を一層効率化できる。

また、本実施形態の変形例によれば、落札判定手段により、複数の購入希望車両のせりのすべてのせりで車両が落札できなかったと判定された場合に、複数の購入希望車両のせりのうちで、流札したせりをグループとし、商談を実施して購入できた車両があったときに、そのグループの残りの車両につき、図４の商談結果情報受信部３９により、商談をキャンセルしているので、希望した車両が購入できた以降に、関係者（せり応札端末を利用する会員、商談担当者）間で人手による連絡をとる手間が省略でき、システム運営を一層効率化できる。

１０ 出品者側せり業務システム
１１−１、１１−２、・・・、１１−ｍ 業務端末
１２ 業務サーバ
１３ 映像サーバ
１４ 通信ネットワーク
１５ せりシステム
１６ せり制御装置
１７ 調整人端末
１８−１、１８−２、・・・、１８−ｎ、７０ せり応札端末
１９ 表示装置
２１ モニター部
２２−１、２２−２ 応札ボタン器具
２３ カードリーダ
２４ テンキーボード
２５ マウス
２６−１、２６−２ 応札ボタン
３０ コントローラ部
２７、２８ せり情報の表示枠
２７−１ レーン情報
２７−２ 出品番号
２７−３ 価格情報
２７−４ 出品物に関する情報のＰＤＦイメージ
２７−５ 出品物の画像情報
２９ 表示画面
３２、５５、７１ 通信インターフェイス部
３４ 検索処理部
３５ 検索結果送信部
３６ 次時間帯せり情報送信部
３７ フラグ設定情報受信部
３８ せり結果情報受信部
３９ 商談リスト作成部
４０、６３、８２ メモリ
４１ 出品物情報テーブル
４２ 会員毎参加希望せり情報テーブル
４３、８４ スケジュール・テーブル
４４ 出品物毎商談リスト
４５ 落札者用処理部
４６ 非フラグ設定情報パケット
４７ 商談リスト作成部
４８ 検索要求パケット
４９ 検索結果パケット
５１ フラグ設定情報パケット
５２ 次時間帯せり情報パケット
５６、７２ 次時間帯判定部
５７ 次時間帯せり情報取得部
５８、７５ せりスタート判定部
５９ 現在価格情報送信部
６１ せり応札情報送信部
６２ せり結果情報送信部
６４ 次時間帯せり情報テーブル
６７ 現在価格情報パケット
６８ せり結果情報パケット
６９ 落札通知パケット
７４ 次時間帯情報設定部
７８ 応札処理部
７８−１ 画面表示更新処理部
７８−２ 選択枠切替部
７８−３ 左側応札ボタン器具
７８−４ 右側応札ボタン器具
７９ 応札情報送信部
８１ 現在価格情報受信部
８６、１０３ 参加希望せり情報テーブル
８９ 表示位置情報テーブル
９１ 選択枠情報
１０１ せり応札情報パケット
１０２ 商談結果情報パケット

Claims (4)

1. 車両のせり取引を行なうせり応札端末の利用者の会員番号毎に、商談を希望する複数の購入希望車両のせりの情報を記憶した記憶部を備えた参加せり情報処理装置において、
   前記複数の購入希望車両のせりのうちの１つで落札したかどうかを判定する落札判定手段と、
   該落札判定手段により、該購入希望車両のせりの１つで車両が落札されたと判定された場合に、残りの購入希望車両のせりの流札時の商談希望をキャンセルする商談キャンセル手段と、
   を備えることを特徴とする参加せり情報処理装置。
2. 前記購入希望車両のせりの情報は、流札後の商談に参加希望するかどうかを示す商談フラグと、参加希望するせりのどの範囲をグループ化するかを示すグループフラグとを有し、
   前記商談キャンセル手段は、商談希望をキャンセルする際に、キャンセル対象となるせりの範囲を前記グループフラグを基に判断し、商談フラグとグループフラグとを共にオフとすることを特徴とする請求項１記載の参加せり情報処理装置。
3. 車両のせり取引を行なうせり応札端末の利用者の会員番号毎に、商談を希望する複数の購入希望車両のせりの情報を記憶した記憶部を備えた参加せり情報処理装置が実行する参加せり情報処理方法において、
   前記参加せり情報処理装置が、複数の購入希望車両のせりのうちの１つで落札したかどうかを判定する落札判定ステップと、
   前記参加せり情報処理装置が、前記落札判定ステップで、前記購入希望車両のせりの１つで車両が落札されたと判定された場合に、残りの購入希望車両のせりの流札時の商談希望をキャンセルする商談キャンセル・ステップと、を備えることを特徴とする参加せり情報処理方法。
4. 前記購入希望車両のせりの情報は、流札後の商談に参加希望するかどうかを示す商談フラグと、参加希望するせりのどの範囲をグループ化するかを示すグループフラグとを有し、
   前記商談キャンセル・ステップで、商談希望をキャンセルする際に、キャンセル対象となるせりの範囲を前記グループフラグを基に判断し、商談フラグとグループフラグとを共にオフとすることを特徴とする請求項３記載の参加せり情報処理方法。