特許 7638571 入札支援方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2025-02-21

(45)【発行日】2025-03-04

(54)【発明の名称】入札支援方法

(51)【国際特許分類】

   G06Q 30/08 20120101AFI20250225BHJP

【ＦＩ】

G06Q30/08

【請求項の数】 3

(21)【出願番号】P 2024109691

(22)【出願日】2024-07-08

【審査請求日】2024-07-12

【早期審査対象出願】

(73)【特許権者】

【識別番号】523073725

【氏名又は名称】合同会社坂井豊貴事務所

(74)【代理人】

【識別番号】100138221

【弁理士】

【氏名又は名称】影山 剛士

(74)【代理人】

【識別番号】100177987

【弁理士】

【氏名又は名称】河野上 真緒

(72)【発明者】

【氏名】坂井 豊貴

【審査官】永野 一郎

(56)【参考文献】

【文献】特表２０１３－５１８３２９（ＪＰ，Ａ）

【文献】特開２０１３－０４１３５８（ＪＰ，Ａ）

【文献】特開２００２－１５７４５７（ＪＰ，Ａ）

【文献】特表２０１９－５０７３９９（ＪＰ，Ａ）

【文献】特開２０２０－１８７５２７（ＪＰ，Ａ）

【文献】特開２０１２－１９４９５６（ＪＰ，Ａ）

【文献】米国特許出願公開第２０２０／００５１１６２（ＵＳ，Ａ１）

【文献】米国特許出願公開第２００３／００４１００９（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０２３／０３８５９２３（ＵＳ，Ａ１）

【文献】中国特許出願公開第１１６７９７２９１（ＣＮ，Ａ）

【文献】特開２０１８－００５４７２（ＪＰ，Ａ）

【文献】米国特許出願公開第２００３／００１８５６２（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

商品販売の入札を支援する方法であって、
サーバ端末の制御部は、
入札案件の企画を行う主催者の主催者端末から、前記入札案件に関する入力データを受信し、
前記主催者端末から、プライシング方式の設定に関する入力データを受信し、
前記受信した、前記プライシング方式の設定に関するデータを、前記入札案件に関するデータに関連付けて、前記サーバ端末の記憶部に格納し、
前記プライシング方式の設定に関するデータに基づいて、入札者の入札額及び入札個数を含む入札内容に応じて支払額を決定する関数を設定し、
前記入札案件に対し、複数の入札者の入札者端末から、前記入札内容に関する入力データを受信し、受信した前記入札内容に関する入力データに基づいて、前記複数の入札者の中から落札者を決定し、
前記落札者の前記入札内容を前記関数に与えて前記落札者の前記支払額を決定する、方法。

【請求項2】

請求項１に記載の方法であって、
前記制御部は、前記主催者端末から、前記入札案件の入札方式に関する入力データを受信する、方法。

【請求項3】

請求項１に記載の方法であって、
前記制御部は、前記主催者端末から、前記入札案件の支払上限額に関する入力データを受信し、前記プライシング方式の設定に関するデータ及び前記支払上限額に基づいて、前記支払額が前記支払上限額以下となるように前記関数を設定する、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、入札を支援する方法に関する。

【背景技術】

【0002】

従来、同質複数財の入札として、国債の入札が挙げられる。入札ではなくオークションという語が用いられることも多くあるが、ここでは入札の語で、いわゆる入札とオークションの双方を意味する。

【0003】

国債の入札においては、非特許文献１に開示されているように、入札者から入札された金額について、高い価格から順に落札が決定し、特に、コンベンショナル方式においては、落札者の応札価格がそのまま支払額として決定する。

【先行技術文献】

【特許文献】

【0004】

【文献】日本国債入門―ダッチ方式とコンベンショナル方式を中心とした入札（オークション）制度と学術研究の紹介―（財務省）

【発明の概要】

【発明が解決しようとする課題】

【0005】

特許文献１に開示の技術は、国債の入札に関する文献であるが、同質複数財の入札には、国債以外にも、ＩＰＯで販売される新規上場株、セキュリティトークン及び暗号資産等、様々な金融商品や温室効果ガスの排出枠やクレジットが適しており、今後、オンラインにより、同質複数財の入札を支援するサービスの需要は高まるものと考えられる。また、商品販売の入札案件を企画する主催者（運営者）は、様々な商品を販売したり、同じ商品を異なる時期で販売する中で、商品及び／または時期に応じてプライシング方式を柔軟に選択したり設定したりしたい、と考えるものと予想される。

【0006】

そこで、本発明は、上記課題やニーズに鑑み、商品販売の入札案件に応じて柔軟なプライシング方式を選択可能な入札支援方法を提供する。

【課題を解決するための手段】

【0007】

本発明の一態様における商品販売の入札を支援する方法であって、サーバ端末の制御部は、入札案件の企画を行う主催者の主催者端末から、前記入札案件の入札期間に関する入力データを受信し、前記主催者端末から、前記入札案件の、複数のプライシング方式のうちいずれかのプライシング方式及び特定のプライシング方式を定める各種パラメータの少なくとも一方に関する入力データを受信し、前記受信した、前記入札期間及び前記プライシング方式に関するデータを、前記入札案件に関するデータに関連付けて、前記サーバ端末の記憶部に格納する。

【発明の効果】

【0008】

本発明によれば、商品販売の入札案件に応じてプライシング方式を柔軟に選択できたり設定できたりする入札支援方法を提供することができる。

【図面の簡単な説明】

【0009】

【図1】本発明の第一実施形態に係る、商品販売の入札を支援するシステムを示すブロック構成図である。

【図2】図１のサーバ端末１００を示す機能ブロック構成図である。

【図3】図１の入札企画の主催者端末２００を示す機能ブロック構成図である。

【図4】サーバ端末１００に格納される、入札データの一例を示す図である。

【図5】サーバ端末１００に格納される、入札者から受信する入札データの一例を示す図である。

【図6】本発明の第一実施形態に係る、入札支援方法の一例を示すフローチャートである。評価データの一例を説明する概念図である。

【図7】本発明の第一実施形態に係る、入札支援方法の他の一例を示すフローチャートである。

【図8】本発明の第二実施形態に係る、入札支援方法の一例を示すフローチャートである。

【図9】本発明の第二実施形態に係る、入札支援方法の他の一例を示すフローチャートである。

【発明を実施するための形態】

【0010】

以下、本発明の実施形態について図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また、実施形態に示される構成要素のすべてが、本発明の必須の構成要素であるとは限らない。

【0011】

＜構成＞
図１は、本発明の第一実施形態に係る、商品販売の入札を支援する方法を実行するシステムを示すブロック構成図である。本システム１は、例えば、一または複数の入札案件を管理し、各入札案件の入札処理の支援を実行する、サーバ端末１００、上記入札案件を企画する、企画の主催者の主催者端末２００、及び、上記入札案件に対して入札を行う入札者の入札者端末３００等で構成される。なお、説明の便宜上、各端末を単一または特定数のものとして記載しているが、各々数は制限されない。

【0012】

サーバ端末１００、主催者端末２００及び入札者端末３００は、ネットワークＮＷ１を介して各々接続される。ネットワークＮＷは、インターネット、イントラネット、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等により構成される。

【0013】

サーバ端末１００は、例えば、ワークステーションやパーソナルコンピュータのような汎用コンピュータとしてもよいし、或いはクラウド・コンピューティングによって論理的に実現されてもよい。

【0014】

主催者端末２００及び入札者端末３００は、例えば、パーソナルコンピュータやタブレット端末等の情報処理装置であるが、スマートフォンや携帯電話、ＰＤＡ等により構成してもよい。

【0015】

本実施形態では、システム１は、サーバ端末１００、主催者２００、及び入札者端末３００を備え、各端末のユーザが各々の端末を利用して、サーバ端末１００に対する操作を行う構成として説明するが、サーバ端末１００がスタンドアローンで構成され、サーバ端末自身に、各主催者が直接操作を行う機能を備えてもよい。

【0016】

図２は、図１のサーバ端末１００の機能ブロック構成図である。サーバ端末１００は、通信部１１０と、記憶部１２０と、制御部１３０とを備える。

【0017】

通信部１１０は、ネットワークＮＷ１を介して主催者端末２００、入札者端末３００と通信を行うための通信インターフェースであり、例えばＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等の通信規約により通信が行われる。

【0018】

記憶部１２０は、各種制御処理や制御部１３０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等から構成される。また、記憶部１２０は、入札案件に関連する各種データを格納する、入札データ格納部１２１を有する。なお、各種データを格納したデータベース（図示せず）が記憶部１２０またはサーバ端末１００外に構築されていてもよい。

【0019】

制御部１３０は、記憶部１２０に記憶されているプログラムを実行することにより、サーバ端末１００の全体の動作を制御するものであり、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等から構成される。制御部１３０の機能として、各端末からの指示や情報を受け付ける情報受付部１３１と、入札案件に関連する各種データを参照し、処理する、情報処理部１３２と、を有する。この情報受付部１３１及び情報処理部１３２は、記憶部１２０に記憶されているプログラムにより起動されてコンピュータ（電子計算機）であるサーバ端末１００により実行される。

【0020】

情報受付部１３１は、主催者端末２００及び入札者端末３００等から通信部１１０を介して情報を受付ける。例えば、主催者端末２００から、主催者により入力された、入札案件に関する条件に関する情報等を受信する。

【0021】

情報処理部１３２は、入札案件に関連する各種データ（例えば、後述する入札データ１０００等）を参照し、所定の処理を行う。

【0022】

また、制御部１３０は、図示しない、画面生成部を有することもでき、求めに応じて、主催者端末２００または入札者端末３００のユーザーインターフェースを介して表示される画面情報を生成する。例えば、記憶部１２０に格納された（図示しない）画像及びテキストデータを素材として、所定のレイアウト規則に基づいて、各種画像及びテキストをユーザーインターフェースの所定の領域に配置することで、ユーザーインターフェースを生成する。画像生成部に関連する処理は、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）によって実行することもできる。

【0023】

図３は、図１の主催者端末２００を示す機能ブロック構成図である。主催者端末２００は、通信部２１０と、表示操作部２２０と、記憶部２３０と、制御部２４０とを備える。

【0024】

通信部２１０は、ネットワークＮＷを介してサーバ端末１００と通信を行うための通信インターフェースであり、例えばＴＣＰ／ＩＰ等の通信規約により通信が行われる。

【0025】

表示操作部２２０は、ユーザが指示を入力し、制御部２４０からの入力データに応じてテキスト、画像等を表示するために用いられるユーザーインターフェースであり、主催者端末２００がパーソナルコンピュータで構成されている場合はディスプレイとキーボードやマウスにより構成され、主催者端末２００がスマートフォンまたはタブレット端末で構成されている場合はタッチパネル等から構成される。この表示操作部２２０は、記憶部２３０に記憶されている制御プログラムにより起動されてコンピュータ（電子計算機）である主催者端末２００により実行される。

【0026】

記憶部２３０は、各種制御処理や制御部２４０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭやＲＯＭ等から構成される。また、記憶部２３０は、サーバ端末１００との通信内容を一時的に記憶している。

【0027】

制御部２４０は、記憶部２３０に記憶されているプログラムを実行することにより、主催者端末２００の全体の動作を制御するものであり、ＣＰＵやＧＰＵ等から構成される。

【0028】

なお、入札者端末３００についても、主催者端末２００と実質的に同じ構成とすることができ、説明を省略する。

【0029】

図４は、サーバ端末１００に格納される入札データの一例を示す図である。

【0030】

図４に示す入札データ１０００は、入札に関連する各種データを格納する。図４において、説明の便宜上、一入札案件（例えば、X社が販売する金融商品に対応する入札ＩＤ「１０００１」で識別される入札案件）の例を示すが、複数の案件の情報を格納することができる。入札に関連する各種データとして、例えば、入札案件に関する基本データ（例えば、案件名、主催者データ（主催者ID、主催者名、業種等）、商品データ（商品名、商品カテゴリ、商品の説明等）、入札設定データ（入札方式（公開／封印入札）、入札期間、プライシング方式（ビッド支払方式、均一価格方式、スペイン方式等）、特定のプライシング方式を定める各種パラメータ（入札案件及び入札等の情報に応じて価格を決定する式を定める変数）、入札個数の範囲を定めるパラメータ、支払上限額、支払下限額、目標収益額等）、及び入札取引データ（入札者、入札額、入札個数、入札日時、落札者入札額、落札者、支払額等）を含むことができるがこれらに限られない。さらに、入札データ１０００は、案件毎、主催者毎、業種毎、商品カテゴリ毎等の入札案件データに基づいて分析された、分析データ（主催者データ、最高落札価格、最低落札価格、最高非落札価格、落札金額の性質、落札者の入札時期の性質、全入札の性質、目標収益額達成率等）を含むこともできる。

【0031】

＜処理の流れ＞
図６を参照しながら、本実施形態のシステム１が実行する、入札支援方法の処理の流れについて説明する。図６は、本発明の第一実施形態に係る、入札を支援する方法の一例を示すフローチャートである。

【0032】

まず、入札案件を企画する主催者は、主催者端末２００に実装されるブラウザまたはアプリケーションを介して、サーバ端末１００にアクセスし、サービスにログインする。そして、主催者は、入札案件を作成するため、入札案件に関する基本データ及び入札取引データ及び関連するデータの内、必要な情報を、主催者端末２００に表示される所定の画面を介して入力し、サーバ端末１００の制御部１３０の情報受付部１３１は、入力された情報を受信する。主催者が入力する情報には、複数の候補の中から選択された特定のプライシング方式及び特定のプライシング方式を定める各種パラメータの少なくとも一方といった、プライシング方式の確定に関する情報が含まれる。サーバ端末１００の制御部１３０の情報処理部１３２は、受信した基本情報を、記憶部１２０の入札データ格納部１２１に、入札データ１０００の一部として格納することで、案件登録を実行する。

【0033】

そして、ステップＳ１０１の処理として、サーバ端末１００の制御部１３０の情報受付部１３１は、通信部１１０を介して、主催者端末２００から、入札案件について、主催者より入力された、入札方式に関するデータを受信する。入札方式として、公開入札及び封印入札が挙げられ、封印入札においては、入札者が入札すると、その後に原則として入札額や入札個数といった入札内容を変更できない一方、公開入札においては、入札期間内に、入札者が入札内容を更新できる点が異なる。サーバ端末１００の制御部１３０の情報処理部１３２は、受信した入札方式に関する入力データを、記憶部１２０の入札データ格納部１２１に、入札データ１０００の一部として格納することで、入札方式の登録を実行する。以下、本例においては、同質複数財（同じものを複数個）を封印入札で販売することを前提に説明する。ただし本実施形態は、販売する財が複数個でなく１個であるときを、特殊ケースの一つとして含む。

【0034】

続いて、ステップＳ１０２の処理として、サーバ端末１００の制御部１３０の情報受付部１３１は、通信部１１０を介して、主催者端末２００から、入札案件について、主催者より入力された、入札期間に関するデータを受信する。サーバ端末１００の制御部１３０の情報処理部１３２は、受信した入札期間に関する入力データを、記憶部１２０の入札データ格納部１２１に、入札データ１０００の一部として格納することで、入札期間の登録を実行する。

【0035】

続いて、ステップＳ１０３の処理として、サーバ端末１００の制御部１３０の情報受付部１３１は、通信部１１０を介して、主催者端末２００から、入札案件について、主催者より入力された、プライシング方式に関するデータを受信する。サーバ端末１００の制御部１３０の情報処理部１３２は、受信したプライシング方式に関する入力データを、記憶部１２０の入札データ格納部１２１に、入札データ１０００の一部として格納することで、プライシング方式の登録を実行する。ここで、プライシング方式とは、入札者が入札結果の確定後に支払う支払額の設定方法のことをさす。

【0036】

入札ベクトルにある入札額のうち、入札額が高い順に、販売する財を割り当てる。ここで入札ベクトルとは、例えば、各入札者ｉの入札額ｂ＿ｉと入札個数ｑ＿ｉといった入札内容（ｂ＿ｉ，ｑ＿ｉ）の組み合わせ（ｂ，ｑ）＝（（ｂ＿１，ｑ＿１），（ｂ＿２，ｑ＿２），…，（ｂ＿ｎ，ｑ＿ｎ））のことである。財を割り当てられた入札をしていた者は、その割り当てられた個数の、落札者となる。例として、同じ財を５個販売し、入札者が４人の状況を考える。入札状況は次のようだとする。すなわち、
１） 入札者Ａは「２０円で２個」の入札をした（ｂ＿Ａ＝２０，ｑ＿Ａ＝２）。 ＊「２０円」は１個あたり入札額。
２） 入札者Ｂは「１３円で１個」の入札をした（ｂ＿Ｂ＝１３，ｑ＿Ｂ＝１）。
３） 入札者Ｃは「１１円で２個」の入札をした（ｂ＿Ｃ＝１１，ｑ＿ｃ＝２）。＊「１１円」は１個あたり入札額。
４） 入札者Ｄは「９円で１個」の入札をした（ｂ＿Ｄ＝９，ｑ＿Ｄ＝１）。
以上より、入札ベクトルは（ｂ，ｑ）＝（（２０，２），（１３，１），（１１，２），（９，１））。
ところで「入札者Ａと入札者Ｂは同一人物」のようなことはあってよい。「２０円で２個」と「１３円で１個」を両方とも入札する人は、このように二人の入札者として、ここでは表される。入札額のうち上位５つは「入札者Ａの２０円で２個」「入札者Ｂの１３円で１個」「入札者Ｃの１１円で２個」。これらが「勝ち入札」であり、落札者として、財が割り当てられる。なお、同じ入札額を付けていた入札者が複数おり、かつ割り当てる財の個数がその入札額での購入希望総数に満たない場合は、入札額以外の情報または抽選、あるいはそれらの両方を組み合わせて勝ち入札を決める。

【0037】

そのうえで、落札者が支払う支払額には、プライシング方式によって、いくつかのパターンが挙げられる。以下はその例である。
１）ビッド支払方式： 入札額をそのまま各人の価格にする。つまり「入札者Ａの２０円で２個」は２個とも２０円、「入札者Ｂの１３円で１個」は１３円、「入札者Ｃの１１円で２個」は２個とも１１円とする。主催者は計（２０＋２０）＋１３＋（１１＋１１）＝７５円を得る。
２）均一価格方式：勝ち入札の最少額を各人の価格とする。つまり「入札者Ａの２０円で２個」も、「入札者Ｂの１３円で１個」も、「入札者Ｃの１１円で２個１＋（１１＋１１）＝５５円を得る。
３）スペイン方式：勝ち入札の平均値は（２０＋２０＋１３＋１１＋１１）／５＝７５／５＝１５円。各人の１個あたり支払額は、勝ち入札の平均値を上限とする。つまり平均値１５円を超す「入札者Ａの２０円」には、１個あたり価格を１５円と抑える。一方、平均値以下である「入札者Ｂの１４円で１個」は１４円とし、同じく平均値以下である「入札者Ｃの１１円で２個」も１個あたり価格を１１円とする。主催者は計（１５＋１５）＋１３＋（１１＋１１）＝６５円を得る。

【0038】

本ステップにおいて、サーバ端末１００の制御部１３０の情報処理部１３２は、主催者が入力したプライシング方式の確定に関する情報を用いて、以下の関数Ｆを設定する。すなわち、関数Ｆは、入札ベクトル（ｂ，ｑ）に応じて、入札者ｉ＝１，２，…，ｎの支払額ベクトルＦ（ｂ，ｑ）＝（Ｆ＿１（ｂ，ｑ），Ｆ＿２（ｂ，ｑ），…，Ｆ＿ｎ（ｂ，ｑ））を与える。ここで、Ｆ＿ｉ（ｂ，ｑ）は入札者ｉの支払額を表す。つまりプライシング方式の確定に関する情報は、関数Ｆの形状を定め、関数Ｆは与えられた入札ベクトルに応じて各入札者の支払額を定める。

【0039】

続いて、ステップＳ１０４の処理として、サーバ端末１００の制御部１３０の情報処理部１３２は、上記登録した入札案件に関するデータを、入札期間、プライシング方式に関する情報を含めて、複数の入札者端末３００に送信することで、入札案件の内容を公開する。

【0040】

続いて、図７は、本発明の第一実施形態に係る、入札を支援する方法の他の一例を示すフローチャートである。本例においては、上記公開された入札案件に対して、複数の入札者から入札を受け付ける場合を想定して、以下説明する。

【0041】

ステップＳ２０１の処理として、サーバ端末１００の制御部１３０の情報受付部１３１は、通信部１１０を介して、複数の入札者端末３００から、入札案件について、入札者より入力された、入札額と入札個数に関するデータを受信する。ここで、各入札者ｉが、入札内容として自身の入札額と入札個数（ｂ＿ｉ，ｑ＿ｉ）を各入札者端末３００で入力したとき、入札ベクトルは（ｂ，ｑ）＝（（ｂ＿１，ｑ＿１），（ｂ＿２，ｑ＿２），…，（ｂ＿ｎ，ｑ＿ｎ））として表される。ただしｐ＿ｉとｑ＿ｉは主催者が事前に設定した各種パラメータによって、入札者が入力できる数の範囲が限られていたり数が固定されていたりすることがあり、数が固定されている場合には入札者はわざわざその数を入力しないで済む設定となっていることが通常である。ここで入札額及び入札個数が、例えば図５に示すように、入札者Ａは「２０円で２個」、入札者Ｂは「１３円で１個」の入札、入札Ｃは「１１円で２個」、入札Ｄは「９円で１個」の入札であったとする。サーバ端末１００の制御部１３０の情報処理部１３２は、受信した上記入札額及び個数に関する入力データを、記憶部１２０の入札データ格納部１２１に、入札データ１０００として格納する。

【0042】

続いて、ステップＳ２０２の処理として、サーバ端末１００の制御部１３０の情報受付部１３１は、通信部１１０を介して、複数の入札者より入力された、入札額と入札個数に関するデータに基づいて、入札額の高い順に落札者（勝ち入札）を決定する。例えば、上記入札額のうち上位５つは「入札者Ａの２０円で２個」「入札者Ｂの１３円で１個」「入札者Ｃの１１円で２個」であり、これらが「勝ち入札」となり、入札者Ａ、Ｂ及びＣに財が割り当てられることとなる。サーバ端末１００の制御部１３０の情報処理部１３２は、決定した落札者（勝ち入札）を、記憶部１２０の入札データ格納部１２１に、入札データ１０００として格納する。入札額が等しい入札者が複数いる場合は、入札額以外の情報に基づき勝ち入札を決めるか、ランダムに抽選で勝ち入札を決めるか、それら二つの決め方を組み合わせて勝ち入札を決める。

【0043】

続いて、ステップＳ２０３の処理として、サーバ端末１００の制御部１３０の情報処理部１３２は、記憶部１２１の入札データ格納部１２１の入札データ１０００に格納される、上記プライシング方式の確定に関する情報を参照する。

【0044】

続いて、ステップＳ２０４の処理として、サーバ端末１００の制御部１３０の情報処理部１３２は、上記プライシング方式の確定に関する情報及び入札ベクトルに基づいて、それぞれの入札者の支払額を決定する。ここで、サーバ端末１００の制御部１３０の情報処理部１３２は、入札ベクトル（ｂ，ｑ）に、支払額ベクトルＦ（ｂ，ｑ）＝（Ｆ＿１（ｂ，ｑ），Ｆ＿２（ｂ，ｑ），…，Ｆ＿ｎ（ｂ，ｑ））を与える。ここで、Ｆ＿ｉ（ｂ，ｑ）は入札者ｉの支払額を表し、値はゼロもありえる（もしｉが入札の敗者であれば、通常はこの値はゼロとなる。通常主催者はＦがそうなるよう設定する）。上記説明の通り、例えばＦがビッド支払い方式に対応する場合、入札者Ａは、２個とも２０円、入札者Ｂは、１３円、入札者Ｃは、２個とも１１円の支払額となり、主催者は計７５円を得る。また、Ｆが均一価格方式に対応する場合、入札者Ａ、入札者Ｂ、及び入札者Ｃは、すべて１個あたり１１円の支払額となり、主催者は計５５円を得る。このように、本実施形態によれば、商品販売の入札案件に応じて、主催者はプライシング方式を柔軟に設定できる。この選択によって、主催者は売上を高めることもできる。例えば、一見ビッド支払い方式は、主催者の売上は最大化されそうだが、常にそうとは限らない。入札者はプライシング方式に応じて入札額や入札個数を変えるからである。例えば均一価格方式のもとでは、最低落札価格が一単位当たり支払額となるので、入札者は安心して高い入札額を付けやすい。そして多くの入札者がそのように行動すると、最低落札価格が上昇して、主催者の売上は上がりうる。重要なのは、主催者が、自身の目的に応じて、プライシング方式を柔軟に選択したり設定したりできることである。

【0045】

図８は、本発明の第二実施形態に係る、入札支援方法の一例を示すフローチャートである。

【0046】

まず、ステップＳ３０１の処理として、サーバ端末１００の制御部１３０の情報受付部１３１は、通信部１１０を介して、主催者端末２００から、入札案件について、主催者より入力された、入札方式に関するデータを受信する。入札方式として、公開入札及び封印入札が挙げられ、封印入札においては、入札者が入札すると、その後には原則として入札額や入札個数といった入札内容を変更できない一方、公開入札においては、入札期間内に、入札者が入札内容を更新できる点が異なる。サーバ端末１００の制御部１３０の情報処理部１３２は、受信した入札方式に関する入力データを、記憶部１２０の入札データ格納部１２１に、入札データ１０００として格納することで、入札方式の登録を実行する。以下、本例においては、同質複数財（同じものを複数個）を封印入札で販売することを前提に説明する。

【0047】

続いて、ステップＳ３０２の処理として、サーバ端末１００の制御部１３０の情報受付部１３１は、通信部１１０を介して、主催者端末２００から、入札案件について、主催者より入力された、入札期間に関するデータを受信する。サーバ端末１００の制御部１３０の情報処理部１３２は、受信した入札期間に関する入力データを、記憶部１２０の入札データ格納部１２１に、入札データ１０００として格納することで、入札期間の登録を実行する。

【0048】

続いて、ステップＳ３０３の処理として、サーバ端末１００の制御部１３０の情報受付部１３１は、通信部１１０を介して、主催者端末２００から、入札案件について、主催者より入力された、支払額の上限値に関するデータを受信する。サーバ端末１００の制御部１３０の情報処理部１３２は、受信した支払額の上限値に関する入力データを、記憶部１２０の入札データ格納部１２１に、入札データ１０００として格納することで、支払額の上限値の登録を実行する。
本ステップにおいて、サーバ端末１００の制御部１３０の情報処理部１３２は、以下の関数Ｇを設定する。すなわち、関数Ｇは、「入札者が支払う価格の上限」を与え、上記支払額ベクトルＦがＧによって定義される。

【0049】

続いて、ステップＳ３０４の処理として、サーバ端末１００の制御部１３０の情報処理部１３２は、上記登録した入札案件に関するデータを、支払額の上限値の設定に関する情報を含めて、複数の入札者端末３００に送信することで、入札案件の内容を公開する。

【0050】

続いて、図９は、本発明の第二実施形態に係る、入札を支援する方法の他の一例を示すフローチャートである。本例においては、上記公開された入札案件に対して、複数の入札者から入札を受け付ける場合を想定して、以下説明する。

【0051】

ステップＳ４０１の処理として、サーバ端末１００の制御部１３０の情報受付部１３１は、通信部１１０を介して、複数の入札者端末３００から、入札案件について、入札者より入力された又は主催者が事前に設定した各種パラメータが定めた、入札額と入札個数に関するデータを受信する。ここで、各入札者ｉが、自身の入札額と入札個数（ｂ＿ｉ，ｑ＿ｉ）を各入札者端末３００で入力したとき、入札ベクトルを（ｂ，ｑ）＝（（ｂ＿１，ｑ＿１），（ｂ＿２，ｑ＿２），…，（ｂ＿ｎ，ｑ＿ｎ））で表すことができる。また、ここで、各入札者により入力された入札額及び入札個数は、例えば図５に示すように、各々、入札者Ａは「２０円で２個」、入札者Ｂは「１３円で１個」の入札、入札Ｃは「１１円で２個」、入札Ｄは「９円で１個」の入札であったとする。サーバ端末１００の制御部１３０の情報処理部１３２は、受信した上記入札額及び個数に関する入力データを、記憶部１２０の入札データ格納部１２１に、入札データ１０００として格納する。

【0052】

続いて、ステップＳ４０２の処理として、サーバ端末１００の制御部１３０の情報受付部１３１は、通信部１１０を介して、入札額と入札個数に関するデータに基づいて、落札者（勝ち入札）を決定する。例えば、上記入札額のうち上位５つは「入札者Ａの２０円で２個」「入札者Ｂの１３円で１個」「入札者Ｃの１１円で２個」であるが、これらが「勝ち入札」となり、入札者Ａ、Ｂ及びＣに財が割り当てられることとなる。サーバ端末１００の制御部１３０の情報処理部１３２は、決定した落札者（勝ち入札）を、記憶部１２０の入札データ格納部１２１に、入札データ１０００の一部として格納する。

【0053】

続いて、ステップＳ４０３の処理として、サーバ端末１００の制御部１３０の情報処理部１３２は、記憶部１２１の入札データ格納部１２１の入札データ１０００に格納される、上記プライシング方式の確定に関する情報を参照し、また、上記設定した支払額の上限値を参照する。

【0054】

続いて、ステップＳ４０４の処理として、サーバ端末１００の制御部１３０の情報処理部１３２は、上記プライシング方式の確定に関する情報及び入札額や入札個数といった入札内容に関する情報に基づいて、落札者の支払額を決定する。ここで、サーバ端末１００の制御部１３０の情報処理部１３２は、入札ベクトル（ｂ，ｑ）に、上限額ベクトルＧ（ｂ，ｑ）＝（Ｇ＿１（ｂ，ｑ），Ｇ＿２（ｂ，ｑ），…，Ｇ＿ｎ（ｂ，ｑ））を与える。そして情報処理部１３２は、ｂ＿ｉ＞Ｇ＿ｉ（ｂ，ｑ）である勝ち入札は、支払う額が Ｇ＿ｉ（ｂ，ｑ）で抑えられるとし、ｂ＿ｉ≦Ｇ＿ｉ（ｂ，ｑ）である勝ち入札は、支払う額をｂ＿ｉとする。つまり勝ち入札をつけた入札者は、一単位あたりＦ＿ｉ（ｂ，ｑ）＝ｍｉｎ｛Ｇ＿ｉ（ｂ，ｑ），ｂ＿ｉ｝円を主催者に支払い、財を受け取る。ここで例えばＧが、起こりうる各（ｂ，ｑ）に対して、Ｇ＿ｉ（ｂ，ｑ）に
イ）勝ち入札の「平均値」を対応させる関数だと、この入札方式は、スペイン方式と一致する。
ロ）勝ち入札の「最大値」を対応させる関数だと、この入札方式は、ビッド支払い方式と一致する。
ハ）勝ち入札の「最小値」を対応させる関数だと、この入札方式は、均一価格方式と一致する。
なお、Ｇは入札額や入札個数に限らず、入札者の年齢といった情報によって上限額を与えることもありえる。例えば若年入札者には少ない支払額で済むよう、相対的に低い上限額を与えるというように。すなわち、オンライン入札システムに本機能が備わることで、主催者は、様々なプライシング方式を容易に作ることができる。

【0055】

ここで、第１実施形態及び第２実施形態に開示された機能と関連して、サーバ端末１００の制御部１３０の情報処理部１３２は、ア）入札期間の終了後に、入札の統計分析結果を算出して、主催者端末２００の管理画面に表示させることができる。統計分析結果の例として、以下のものが挙げられる。
１）最高落札価格（勝ち入札の最高値）、最低落札価格（勝ち入札の最低値）、最高非落札価格（負け入札の最高値）
２）勝ち入札の金額の性質（平均値、分散等）
３）勝ち入札の入札時期の性質（日にちや時刻等）
４）すべての入札の性質（平均値、分散等）
５）すべての入札の性質（日にちや時刻等）

【0056】

また、情報処理部１３２は、イ）過去に実施された多数の入札イベントのうち、ユーザが指定する複数の入札イベントについて、入札の統計分析結果を算出して表示させることができる。統計分析結果とは、例として以下のものが挙げられる。
１）商品Xを、入札イベントAではビッド支払い方式で販売し、入札イベントBでは均一価格方式で販売したとする。このとき、この機能を用いると、Aでの上記１）の結果とBでの上記１）の結果が計算されて、両者が比較しやすいように並べて表示される。比較しやすいとは、例えば「AのほうがBよりも最低落札価格が高い」とき、Aのほうだけが赤色に表示されるといったことが挙げられる。
２）これまで共通の方式（例：ビッド支払い方式）で実施した入札イベントたちについて、統計分析結果を計算して表示する。例えば、ビッド支払い方式では、入札額の分散がいくらかになっているか、目標収益額の達成率がいくらかになっているかが、表示される。
さらに、情報処理部１３２は、上述（イ）を、複数の方式について同時に計算し、表示させることができる。これによりビッド支払い方式と均一価格方式とではどちらが目標収益額の達成率が高いか、といったことを定量的に比較できるようになる。本実施形態により、プライシング方式を柔軟に選択できたり設定できたりするのみならず、主催者は、プライシング方式の選択や設定を統計に基づいて決定することができる。

【0057】

以上、発明に係る実施形態について説明したが、これらはその他の様々な形態で実施することが可能であり、種々の省略、置換および変更を行なって実施することが出来る。これらの実施形態および変形例ならびに省略、置換および変更を行なったものは、特許請求の範囲の技術的範囲とその均等の範囲に含まれる。

【符号の説明】

【0058】

１ システム １００ サーバ端末、１１０ 通信部、１２０ 記憶部、１３０ 制御部、２００ 主催者端末、３００ 入札者端末、ＮＷ１ ネットワーク

【要約】      （修正有）

【課題】商品販売の入札案件に応じて柔軟なプライシング方式を選択可能な入札支援方法を提供する。
【解決手段】サーバ端末、主催者端末及び入札者端末を備えるシステムにおいて、商品販売の入札を支援する方法は、サーバ端末の制御部が、入札案件の企画を行う主催者の主催者端末から、入札案件の入札期間に関する入力データを受信し、主催者端末から、入札案件の、複数のプライシング方式のうち特定のプライシング方式及び特定のプライシング方式を定める各種パラメータの少なくとも一方に関する入力データを受信し、受信した入札期間及びプライシング方式に関するデータを、入札案件に関するデータに関連付けて、サーバ端末の記憶部に格納することでプライシング方式を登録し、登録した入札案件に関するデータを、入札期間、プライシング方式に関する情報を含めて、複数の入札者端末に送信することで、入札案件の内容を公開する。
【選択図】図６

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】