JP2015130063A - 販売処理プログラム、販売処理方法及び販売処理装置 - Google Patents

Abstract

【課題】商品の販売機会を増やす、販売処理プログラム、処理方法及び装置を提供する。
【解決手段】サーバ装置１０は、共通する提供場所で提供される商品について複数の仮購入を受信した場合に、商品を分割して得られる分割商品の購入の選択を複数の仮購入先に対して許容する。許容する処理として、提供場所の予約情報を参照して、前記複数の仮購入先の間で、共通する提供場所に予約された日付が同一の場合に、前記分割商品の購入の選択を複数の仮購入先に対して許容する。
【選択図】図２

Description

本発明は、販売処理プログラム、販売処理方法及び販売処理装置に関する。

インターネット等の発達に伴って商品の通信販売も発達している。例えば、複数のユーザが商品を共同で購入する共同購入を支援する技術が提案されている。かかる共同購入の技術では、複数のユーザを束ねることによって一度の注文で商品が購入される数を増やし、商品の単価を低減させることを目指す。

特開２０１０−４４４５２号公報

しかしながら、上記の技術では、以下に説明するように、商品を販売する機会が損なわれる場合がある。

すなわち、上記の共同購入の技術は、一度の注文で購入する商品の購入量を増やす場面にその適用範囲が限定される。例えば、上記の共同購入の技術では、１つの商品単体で希少価値のある商品を複数のユーザに消費させたい場合や、１つの商品単体だと、あるユーザにとっては量が多く消費しきれない場合において、１つの商品単体を複数のユーザで共同購入するのは困難である。さらに、たとえ単体の商品を分割して、複数のユーザへ提供することが可能であったとしても、商品が生物である場合には、各ユーザへ分配するために切り分けてから各ユーザの元へ配送する必要があり、商品の鮮度が低下してしまうことが危惧される。これらが原因となって、商品の購買意欲が低下する結果、商品の販売機会が損なわれる。

１つの側面では、本発明は、商品の販売機会を向上させることができる販売処理プログラム、販売処理方法及び販売処理装置を提供することを目的とする。

一態様の販売処理プログラムは、コンピュータに、共通する提供場所で提供される商品について複数の仮購入を受信した場合に、前記商品を分割して得られる分割商品の購入の選択を前記複数の仮購入先に対して許容する処理を実行させる。

商品の販売機会を向上させることができる。

図１は、実施例１に係る販売処理システムの構成を示す図である。 図２は、実施例１に係るサーバ装置の機能的構成を示すブロック図である。 図３は、会員情報の一例を示す図である。 図４は、朝市情報の一例を示す図である。 図５は、宿泊施設情報の一例を示す図である。 図６は、予約情報の一例を示す図である。 図７は、産物情報の一例を示す図である。 図８は、分割商品の仮購入時における共同購入の成立可否の場合分けの一例を示す図である。 図９は、購入用画面の一例を示す図である。 図１０は、購入用画面の一例を示す図である。 図１１は、購入用画面の一例を示す図である。 図１２は、分割商品の仮購入時における共同購入の成立可否の場合分けの一例を示す図である。 図１３は、購入用画面の一例を示す図である。 図１４は、購入用画面の一例を示す図である。 図１５は、購入用画面の一例を示す図である。 図１６は、実施例１に係る販売処理の手順を示すフローチャートである。 図１７は、実施例１に係る第２の生成処理の手順を示すフローチャートである。 図１８は、実施例１に係る監視処理の手順を示すフローチャートである。 図１９は、実施例１及び実施例２に係る販売処理プログラムを実行するコンピュータの一例について説明するための図である。

以下に添付図面を参照して本願に係る販売処理プログラム、販売処理方法及び販売処理装置について説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

図１は、実施例１に係る販売処理システムの構成を示す図である。図１に示す販売処理システム１は、ネットワーク７を介して、自治体が主催する朝市で提供される産物をクライアント端末３０Ａ〜３０Ｃのユーザに販売する販売処理サービスを実現するものである。なお、以下では、産物の通信販売について例示するが、通信販売で市場に出回っているあらゆる商品の通信販売を同様に実行できる。

［どこでも朝市］
かかる朝市で提供される産物には、その時、その場所でしか買えず、希少で、かつ新鮮でおいしいといった価値や長所がある。このため、朝市には、人々に、その地域の産物を購入して味わってみたいと思わせる魅力がある。さらに、朝市には、特有の活気やコミュニケーションにも魅力がある。このように、朝市は、（１）産物を食べられる期待感、（２）実際に産物を食べる楽しみ、（３）朝市自体を体験する楽しみなどを提供できる。

一方で、産物の消費者となる旅行者には、「時間に伴って場所を移動する」というスケジュール上の制約がある。このため、「開催時間帯が限られる朝市に行けない」、「朝市には行けるが買った産物を旅行中に調理して食べられない」、「飲食施設等でその街の産物は食べられるが朝市には行けない」といったケースも散見される。

これらのことから、上記の販売処理サービスの基盤として、商品の販売を始め、宿泊の予約サービスなどを提供するポータルサイトの事業者と、朝市の主催者である自治体とが連携することによって「どこでも朝市」という新規なサービスを提供する。

ここで、上記の「どこでも朝市」とは、ネットワーク７上に仮想的に再現された朝市から購入される産物を、現実の朝市が開催される街にある飲食施設、とりわけユーザが予約手続を行った宿泊施設と関連する飲食施設へ配送した上で調理後の産物を提供するサービスである。

かかる「どこでも朝市」によって、街の産物をできるだけ多くの旅行者に買ってもらい、消費してもらうという自治体の需要に応え、旅行という制約がある中で、上記の（１）〜（３）の朝市固有の価値を提供し、自治体の町興しに寄与することを目指す。

このような「どこでも朝市」というサービスの基盤の下、本実施例に係る販売処理システム１では、同一商品の購入要求を行う購入者の間で互いの宿泊先が共通する場合に、１未満の分割商品の選択を許容する。

これによって、１つの商品単体で希少価値のある商品や、単体でも量が多く消費しきれない商品を複数人で分割して購入する共同購入という枠に留まらず、各々が共通の宿泊先で分割商品を消費する共同消費を実現できる。この結果、販売側が一度の注文で販売したい商品の販売量の単位と、購入側が一度の注文で購入したい商品の購入量の単位とのギャップを共同購入によって低減できる。さらに、共同購入によって、複数人で購入した商品を分割せずに配送することで鮮度が損なわれることを防いだり、購入したその街の産物である商品を旅先等の現地で楽しむことを可能とする。

したがって、本実施例に係る販売処理システム１によれば、商品の販売機会を向上させることができる。

［システム構成］
図１に示すように、販売処理システム１には、サーバ装置１０と、クライアント端末３０Ａ〜３０Ｃと、主催者端末５０とが収容される。なお、図１には、システムに３つのクライアント端末及び１つの主催者端末が収容される場合を図示したが、各端末の数は図示の例に限定されず、販売処理システム１は任意の数のクライアント端末及び主催者端末を収容できる。なお、以下では、クライアント３０Ａ〜３０Ｃの各装置を区別なく総称する場合には、「クライアント端末３０」と記載する場合がある。

これらサーバ装置１０、クライアント端末３０及び主催者端末５０の間は、ネットワーク７を介して相互に通信可能に接続される。かかるネットワーク７には、有線または無線を問わず、インターネット（Internet）を始め、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。

サーバ装置１０は、クライアント端末５０に上記の販売処理サービスを提供するコンピュータである。上記のサーバ装置１０の一態様としては、パッケージソフトウェアやオンラインソフトウェアとして上記の販売処理サービスを実現する販売処理プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、サーバ装置１０は、上記の販売処理サービスを提供するＷｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の販売処理サービスを提供するクラウドとして実装することとしてもかまわない。

かかるサーバ装置１０は、一例として、上記の販売処理サービスや宿泊の予約サービスを提供するポータルサイトの事業者によって運営される。サーバ装置１０は、クライアント端末３０からの宿泊施設の予約要求にしたがって予約手続きを実行する。なお、以下では、上記の「どこでも朝市」のサービスを受けることが可能な施設の一例として、宿泊施設の予約を受け付ける場合を例示するが、「どこでも朝市」のサービスを受けることができる予約の種別は宿泊施設に限定されない。すなわち、宿泊施設の予約なしに飲食施設の予約を受け付けることができるのは言うまでもなく、飲食の予約サービスを提供する場合にも上記の「どこでも朝市」のサービスを実施できる。

例えば、サーバ装置１０は、宿泊施設の予約を受け付ける場合に、クライアント端末３０からチェックイン及びチェックアウトの日付を始め、宿泊を行う地域などの指定を受け付ける。そして、サーバ装置１０は、これらの条件指定に該当する宿泊施設を図示しない宿泊施設のデータベース等から検索する。この検索結果をクライアント端末３０に表示させる場合、サーバ装置１０は、宿泊施設とともに、宿泊プランを表示させる。かかる宿泊プランには、寝るだけの素泊まりのプランの他、食事が宿泊とパッケージされたプランも含まれる。その後、サーバ装置１０は、宿泊プランの指定とともに宿泊施設の予約要求を受け付けた場合に、当該宿泊施設の予約手続きを実行する。例えば、サーバ装置１０は、宿泊施設への連絡や決済などを代行する。この他、サーバ装置１０は、予約を行ったポータルサイトの会員を識別する会員ＩＤ（IDentifier）に、宿泊施設、チェックイン又はチェックアウトの日付などを始め、食事を含む宿泊プランが指定されている場合には、食事に対応するメニューを対応付けた情報を予約情報として登録できる。このように、宿泊施設の予約サービスでは、宿泊施設の予約を通じて、宿泊施設と関連する飲食施設、例えば宿泊施設が直営するレストランや宿泊施設の事業者が持つビル内のテナントの予約も併せて実行できる。かかる予約サービスを通じて集められた予約情報が上記の販売処理サービスに利用される。

また、サーバ装置１０は、朝市を主催する自治体等によって使用される主催者端末５０から朝市に関する各種情報の登録を受け付ける。例えば、サーバ装置１０は、主催者端末５０から朝市の開催に関する情報、例えば朝市を識別する朝市ＩＤ、開催される朝市の名称や朝市が開催される日付などの情報を受け付ける。その上で、サーバ装置１０は、これら朝市ＩＤ、朝市名および開催日が対応付けられた情報を朝市情報として登録する。このように登録された朝市情報は、一例として、後述のように、ポータルサイトのトップページで産物の販売を行う朝市をメニューとして紹介するのに利用される。さらに、サーバ装置１０は、主催者端末５０から朝市で販売される産物に関する情報、例えば産物を識別する後述の産物ＣＤ（CoDe）及び産物ＩＤ、産物の名称や産物が属する食品のカテゴリなどの情報を受け付ける。その上で、サーバ装置１０は、これら産物ＣＤ、産物ＩＤ、産物名およびカテゴリなどが対応付けられた情報を産物情報として登録する。このように登録された産物情報は、一例として、後述のように、在庫管理や注文管理に利用される。

クライアント端末３０は、サーバ装置１０から上記の予約サービスや上記の販売処理サービスの提供を受けるコンピュータである。かかるクライアント端末３０の一例としては、パーソナルコンピュータを採用できる。クライアント端末３０には、上記のパーソナルコンピュータなどの据置き型の端末のみならず、各種の携帯端末装置をクライアント端末３０として採用することもできる。例えば、携帯端末装置の一例として、スマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）などの移動体通信端末、さらには、ＰＤＡ（Personal Digital Assistants）などのタブレット端末などが挙げられる。

これら予約サービスや販売処理サービスは、上記のポータルサイトに所定の登録手続きを行った会員が提供を受けることができる。例えば、クライアント端末３０を利用するエンドユーザは、個人の属性情報、例えば氏名、住所、電話番号やメールアドレスなどのアドレスをポータルサイトに登録することによって会員ＩＤおよびパスワード等のアカウントの発行を受けることができる。その上で、クライアント端末３０は、ネットワーク７上にあるポータルサイトを運営するサーバ装置１０へアクセスし、アカウントを用いたログイン認証を受けることによって上記の予約サービスや上記の販売処理サービスの提供を受けることができる。

主催者端末５０は、朝市を主催する自治体等によって使用される端末装置である。かかる主催者端末５０の一例としては、パーソナルコンピュータを採用できる。主催者端末５０には、上記のパーソナルコンピュータなどの据置き型の端末のみならず、各種の携帯端末装置を主催者端末５０として採用することもできる。例えば、携帯端末装置の一例として、スマートフォン、携帯電話機やＰＨＳなどの移動体通信端末、さらには、ＰＤＡなどのタブレット端末などが挙げられる。

例えば、主催者端末５０は、上記の朝市情報や上記の産物情報をサーバ装置１０へ登録することによってポータルサイト上に上記の「どこでも朝市」を仮想的に開催できる。一例としては、ポータルサイトのトップページにあるメニューの１つとして、「どこでも朝市」のメニューが用意される。このとき、「どこでも朝市」のメニューは、各地の朝市を指定できるＧＵＩ（Graphical User Interface）であってもよいし、朝市が開催される地域を指定できるＧＵＩであってもよいし、ユーザが宿泊施設の予約を行った地区の朝市が抜粋して表示されるＧＵＩであってもかまわない。

［サーバ装置１０の構成］
図２は、実施例１に係るサーバ装置１０の機能的構成を示すブロック図である。図２に示すように、サーバ装置１０は、通信Ｉ／Ｆ（interface）部１１と、記憶部１３と、制御部１５とを有する。なお、サーバ装置１０は、図２に示す機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや音声出力デバイスなどの機能部を有することとしてもかまわない。

通信Ｉ／Ｆ部１１は、他の装置、例えばクライアント端末３０や主催者端末５０との間で通信制御を行うインタフェースである。かかる通信Ｉ／Ｆ部１１の一態様としては、ＬＡＮカードなどのネットワークインタフェースカードを採用できる。例えば、通信Ｉ／Ｆ部１１は、クライアント端末３０から飲食施設の利用を含む宿泊予約、さらには上記の「どこでも朝市」を介して産物に関する購入予約や決済を受け付けたり、また、産物の一覧画面や数量選択画面をクライアント端末３０へ送信したりする。また、通信Ｉ／Ｆ部１１は、主催者端末５０から朝市情報や産物情報のアップロードを受け付けたり、上記の「どこでも朝市」を介して受け付けた産物の注文を主催者端末５０へ送信したりする。なお、図１には、図示を省略したが、「どこでも朝市」を介して産物の受注があった場合には、産物、産物が飲食施設に届く日時、産物を調理によって提供する日時などを宿泊施設または宿泊施設に関連する飲食施設によって使用される端末に送信することもできる。

記憶部１３は、制御部１５で実行されるＯＳ（Operating System）、予約制御プログラムや販売処理プログラムなどの各種プログラムを記憶する記憶デバイスである。記憶部１３の一態様としては、フラッシュメモリなどの半導体メモリ素子、ハードディスク、光ディスクなどの記憶装置が挙げられる。なお、記憶部１３は、上記の種類の記憶装置に限定されるものではなく、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory)であってもよい。

記憶部１３は、制御部１５で実行されるプログラムに用いられるデータの一例として、会員情報１３ａと、朝市情報１３ｂと、宿泊施設情報１３ｃと、予約情報１３ｄと、産物情報１３ｅとを記憶する。これら会員情報１３ａ、朝市情報１３ｂ、宿泊施設情報１３ｃ、予約情報１３ｄ及び産物情報１３ｅ以外にも、他の電子データ、例えば「どこでも朝市」に関する産物の受注データなども併せて記憶することもできる。

このうち、会員情報１３ａは、ポータルサイトの会員に加入するユーザに関する情報である。かかる会員情報１３ａの一態様としては、会員ＩＤ、氏名およびアドレスなどの項目が対応付けられた情報を採用できる。例えば、会員情報１３ａは、クライアント端末３０によってポータルサイトへの会員登録がなされる度に、当該会員登録を行った会員に採番された会員ＩＤ、氏名およびアドレスを対応付けることによって記憶部１３に登録できる。

図３は、会員情報１３ａの一例を示す図である。図３には、３名の会員が抜粋して例示されているが、会員の人数は任意の人数であってかまわない。図３の例では、会員ＩＤ「Ｒ００１」の鈴木一郎が持つ電子メールのアドレスが「suzuki01@xxx.co.jp」であることを意味する。また、図３の例では、会員ＩＤ「Ｒ００２」の佐藤次郎が持つ電子メールのアドレスが「satou02@xxx.ne.jp」であることを意味する。さらに、会員ＩＤ「Ｒ００３」の香川三太が持つ電子メールのアドレスが「kagawa03@xxx.com」であることを意味する。なお、図３には、会員ＩＤ、氏名およびアドレスなどの項目を例示したが、この他にもユーザが指定する決済方法、デビットカード、クレジットカードや電子マネー等の決済情報をさらに記憶することとしてもかまわない。また、図３には、会員情報１３ａがテーブル形式で管理される場合を例示したが、他の形式、例えばＣＳＶ（Comma Separated Values）で管理することとしてもかまわない。

朝市情報１３ｂは、朝市に関する情報である。かかる朝市情報１３ｂの一態様としては、朝市ＩＤ、朝市名、開催日、制限時間及び取扱品目などの項目が対応付けられたデータを採用できる。例えば、朝市情報１３ｂは、主催者端末５０からのアップロードによって記憶部１３に登録することができる。

ここで言う「制限時間」とは、仮購入に関する手続継続を制限する時間を指す。これに関連して、「仮購入」とは、１つの産物が複数に分割された分割商品が複数のユーザによって共同購入される場合に分割商品が購入予約された数量が産物の分割数に達するまで受け付けられる仮の購入予約のことを指す。以下では、上記の仮購入を行うユーザのことを「仮購入者」と記載するとともに、販売処理システム１上で仮購入者として管理される会員ＩＤのことを「仮購入者ＩＤ」と記載する場合がある。また、「取扱品目」とは、朝市で取り扱われる産物の品目を指し、例えば、朝市で提供される産物の産物ＣＤが列挙して登録される。

図４は、朝市情報１３ｂの一例を示す図である。図４には、各地の朝市のうち函館朝市と佐世保朝市との２つの朝市の例が抜粋されている。図４の例では、朝市ＩＤ「Ａ００１」の函館朝市が２０１３年１１月１日及び２０１３年１１月８日に開催されることを意味する。さらに、函館朝市では、後述する産物ＣＤ「Ｐ００１」、「Ｐ００２」や「Ｐ０５０」などの産物が販売されることを意味する。さらに、函館朝市では、仮購入者が仮購入によって産物を１５分間にわたって押さえることができることを意味する。また、図４の例では、朝市ＩＤ「Ａ００３」の佐世保朝市が２０１３年１１月１日に開催されることを意味する。さらに、佐世保朝市では、仮購入者が仮購入によって産物を２０分間にわたって押さえることができることを意味する。なお、図４には、朝市情報１３ｂがテーブル形式で管理される場合を例示したが、他の形式、例えばＣＳＶで管理することとしてもかまわない。

宿泊施設情報１３ｃは、宿泊施設に関する情報である。かかる宿泊施設情報１３ｃの一態様としては、朝市ＩＤ、宿泊施設ＩＤ及び宿泊施設名などの項目が対応付けられたデータを採用できる。例えば、宿泊施設情報１３ｃは、新規の朝市ＩＤが採番される度に当該朝市が開催される場所の周辺、例えば１００ｍ、５００ｍや１Ｋｍ以内に存在する宿泊施設を図示しない地図情報を参照して抽出し、抽出された各宿泊施設のＩＤ及び名称を当該朝市の朝市ＩＤと対応付けることによって記憶部１３に登録できる。

図５は、宿泊施設情報１３ｃの一例を示す図である。図５には、図４と同様に、函館朝市と佐世保朝市との２つの朝市の例が抜粋されている。図５の例では、朝市ＩＤ「Ａ００１」の函館朝市の周辺にＸ国際ホテルおよびＹ観光ホテルが存在することを意味する。さらに、図５の例では、朝市ＩＤ「Ａ００３」の佐世保朝市の周辺にＰ倶楽部ホテルが存在することを意味する。なお、図５には、宿泊施設情報１３ｃがテーブル形式で管理される場合を例示したが、他の形式、例えばＣＳＶで管理することとしてもかまわない。また、図５には、宿泊施設の一例としてホテルが例示されているが、他の宿泊施設、例えば旅館、民宿、カプセルホテルなどであってもかまわない。

予約情報１３ｄは、予約に関する情報である。かかる予約情報１３ｄの一態様としては、会員ＩＤ、宿泊施設ＩＤ及び宿泊日などの項目が対応付けられたデータを採用できる。ここで言う「宿泊日」とは、ユーザが宿泊施設で宿泊する予定日の日付を指し、例えば、ユーザがチェックインを行う日付を記録できる。例えば、予約情報１３ｄは、クライアント端末３０によって宿泊施設の予約がなされる度に、会員ＩＤ、宿泊施設ＩＤ及びチェックインの日付を対応付けることによって記憶部１３に登録できる。

図６は、予約情報１３ｄの一例を示す図である。図６には、会員ＩＤ「Ｒ００１」〜「Ｒ００３」の鈴木一郎、佐藤次郎、香川三太の３名の予約情報が抜粋して例示されている。図６の例では、会員ＩＤ「Ｒ００１」の鈴木一郎及び会員ＩＤ「Ｒ００２」の佐藤次郎が同一の宿泊日に同一の宿泊先、すなわちＸ国際ホテルを予約していることを意味する。一方、会員ＩＤ「Ｒ００３」の香川三太は、会員ＩＤ「Ｒ００１」の鈴木一郎及び会員ＩＤ「Ｒ００２」の佐藤次郎と同一の宿泊日であるものの、異なる宿泊先、すなわちＰ倶楽部ホテルを予約していることを意味する。なお、図６には、予約情報１３ｄがテーブル形式で管理される場合を例示したが、他の形式、例えばＣＳＶで管理することとしてもかまわない。

産物情報１３ｅは、産物に関する情報である。かかる産物情報１３ｅの一態様としては、産物ＣＤ、産物名、カテゴリ、最大購入可能人数、入庫数、在庫数、産物ＩＤ、仮購入者ＩＤ、一時確保者ＩＤ、購入者ＩＤなどの項目が対応付けられたデータを採用できる。例えば、産物情報１３ｅの一部は、朝市の主催者である自治体が使用する主催者端末５０または自治体を代行するポータルサイトの事業者が使用する端末装置のいずれかによって記憶部１３に登録される。

上記の「産物ＣＤ」とは、１つの種類の産物ごとに付与される識別情報を指し、また、「産物ＩＤ」とは、同じ種類の産物の個々に付与される識別情報を指す。例えば、産物ＩＤは、産物ＣＤに付与された番号へ枝番を順番に付与される場合を例示する。一例としては、産物「幻の柚子」という産物名に産物ＣＤ「Ｐ０５０」が付与されるとしたとき、各々の個体には、「Ｐ０５０−１」、「Ｐ０５０−２」といった要領で産物ＩＤが採番される。また、「最大購入可能人数」とは、１つの産物を共同で購入できる最大の人数を指し、例えば、１である場合には、共同購入には対応しておらず、２以上である場合には、最大購入可能人数で設定されている人数までであれば、複数のユーザによって共同購入できることを意味する。なお、「カテゴリ」とは、産物が属する分類を指し、産物ＣＤや産物ＩＤよりも広い範囲を意味する場合がある。

ここで、産物は、上記の産物ＣＤまたは産物ＩＤのうちいずれかの単位で在庫および注文が管理される。例えば、最大購入可能人数が「１」である場合には、産物ＣＤによって産物の在庫および注文が管理される。一方、最大購入可能人数が「２」以上である場合には、産物ＩＤによって産物の在庫および注文が管理される。これは、共同購入を認めない産物の場合には、各々の個体を識別せずとも全体で在庫および出庫の数の整合が取れれば十分である一方で、共同購入を認める産物の場合には、１つの産物に複数のユーザを紐付けることによって仮購入を管理するケースが生まれるからである。このことから、上記の各項目のうち「産物ＩＤ」及び「仮購入者ＩＤ」は、最大購入可能人数が「２」以上である場合、すなわち産物の共同購入が認められる場合に限って使用される。

また、「入庫数」とは、朝市で入庫される産物の数を指す。また、「在庫数」とは、朝市で入庫される産物のうち販売先が未定である産物の数を指す。また、「一時確保者」とは、ショッピングカートの機能を利用して未決済の状態で産物を一時的に確保するユーザを指す。例えば、ショッピングカートへの商品の登録を行ったユーザの会員ＩＤが登録される場合を例示するが、これに併せてユーザが利用するブラウザやＷｅｂリクエストに付与されるセッションＩＤを登録することもできる。このように、ショッピングカートへの登録が行われた商品は、未決済であるものの、一時的、例えばブラウザが閉じられることによってセッションＩＤが破棄されるまで在庫として計上されず、他のユーザがショッピングカートへの登録や購入を選択できない状態で確保される。また、「購入者ＩＤ」とは、産物の購入を行ったユーザの会員ＩＤを指し、例えば、決済方法の設定を終えたユーザを購入者としてもよいし、また、決済を終えたユーザを購入者とすることとしてもかまわない。

上記の「仮購入者」及び「一時確保者」は、ユーザが産物を一時的に確保できる点で共通するものの、その性質は一部異なる。すなわち、上記の一時確保者によってショッピングカートに登録された産物は、一時確保者によってショッピングカートへの登録が削除されたり、ブラウザが閉じられたりされるまでは他のユーザによる選択は許可されない。一方、上記の仮購入者によって仮購入が行われた産物は、分割商品が仮購入された数量が産物の分割数に達するまで他のユーザによる仮購入が許容される。このとき、分割商品が仮購入された数量が産物の分割数に達していないからといって他のユーザによる仮購入が無条件に許可される訳ではない。詳細は後述するが、上述の共同消費を実現するために、既に仮購入を行ったユーザと同一の宿泊施設への予約を行ったユーザに絞って仮購入が許可される。

図７は、産物情報１３ｅの一例を示す図である。図７には、函館朝市の産物として、鯛、幻の鮎及び幻の柚子の３つの産物の情報が抜粋して示されている。図７の例では、産物「鯛」及び産物「幻の鮎」がカテゴリ「魚」に属する一方で、産物「幻の柚子」がカテゴリ「柑橘類」に属することを意味する。

これらの産物のうち、「幻の鮎」は、最大購入可能人数が「１」であることから共同購入が認められていないことを意味し、そして、朝市に入庫する１１個の「幻の鮎」のうち１つがＲ０２３のユーザによって購入され、在庫数が「１０個」となっていることを意味する。

一方、産物「鯛」は、最大購入可能人数が「２」であることから２人による共同購入が認められていることを意味する。そして、産物「鯛」は、朝市に１つしか入庫しておらず、その１つがＲ０６２及びＲ０４９のユーザの共同購入の成立後にショッピングカートに登録されており、在庫がないことを意味する。このように、ＩＤ単位で管理される１つの産物につき複数の一時確保者が対応付けて登録されている場合には、共同購入を行う各ユーザによってショッピングカートへの登録が共同してなされていることを意味する。なお、ＣＤ単位で管理される産物の場合には、複数の一時確保者が登録されていたとしても、当該産物のショッピングカートへの登録を行ったユーザの会員ＩＤが羅列されているに過ぎず、この場合には共同購入を意味しない。

また、産物「幻の柚子」においても、２人による共同購入が認められていることを意味する。そして、朝市にＰ０５０−１、Ｐ０５０−２及びＰ０５０−３の３つの産物「幻の柚子」が入庫されており、その在庫は、産物ＩＤごとに管理されている。例えば、Ｐ０５０−１については、２つに分割されるＰ０５０−１の幻の柚子のうち１／２個がＲ００２の佐藤次郎からの仮購入を受け付けた状態にあり、残りの１／２個が他のユーザから仮購入を受け付けることが可能な状態にあることを意味する。また、Ｐ０５０−２については、２つに分割されるＰ０５０−２の幻の柚子のうち１／２個がＲ００３の香川三太からの仮購入を受け付けた状態にあり、残りの１／２個が他のユーザから仮購入を受け付けることが可能な状態にあることを意味する。また、Ｐ０５０−３については、仮購入、一時確保および購入がなされておらず、幻の柚子単体が１個在庫として残っている状態であり、Ｐ０５０−３のみ丸ごと１個での購入を受け付けることが可能な状態にあることを意味する。これらのことから、１／２個の状態である在庫が２つと、１個の状態である在庫が１つ、在庫として存在する。

なお、図７には、産物情報１３ｅがテーブル形式で管理される場合を例示したが、他の形式、例えばＣＳＶで管理することとしてもかまわない。また、産物情報１３ｅには、産物の値段を始め、広告の配信に用いる産物の特長や長所などのセールスポイントをさらに含めて記憶することとしてもよい。

制御部１５は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１５は、プロセッサ上で上記の販売処理プログラムに対応する機能を販売処理部１７として仮想的に実現する。なお、図２には、上記の販売処理プログラムに対応する機能部を抜粋して図示したが、上記の予約制御プログラムに対応する機能部をさらに有することとしてもかまわない。

販売処理部１７は、共通する提供場所で提供される商品について、複数の仮購入を受信した場合に、商品を分割して得られる分割商品の購入の選択を複数の仮購入先に対して許容する処理部である。

図２に示すように、販売処理部１７は、受付部１７ａと、特定部１７ｂと、生成部１７ｃと、更新部１７ｄと、通知部１７ｅと、決済部１７ｆとを有する。

受付部１７ａは、クライアント端末３０から産物の指定を受け付ける処理部である。

一態様としては、受付部１７ａは、クライアント端末３０に表示されるＷｅｂページ、例えばポータルサイトが提供するトップページを介して、閲覧対象とする朝市および開催日の指定を受け付ける。例えば、受付部１７ａは、クライアント端末３０へ送信するＨＴＭＬ文書に、朝市情報１３ｂに含まれる朝市及び開催日を選択肢とするプルダウンメニューを含める。これによって、朝市ＩＤ及び開催日をメニュー選択によって指定させることができる。また、受付部１７ａは、クライアント端末３０へ送信するＨＴＭＬ文書に、朝市及び開催日を入力可能な入力フォームを含める。これによって、入力フォームを用いたキーワード検索によって朝市ＩＤ及びその開催日を指定させることもできる。なお、ここでは、プルダウンメニューや入力フォームをＧＵＩ（Graphical User Interface）として例示したが、他のユーザインタフェースを用いることとしてもかまわない。

このように朝市が指定された後に、受付部１７ａは、朝市情報１３ｂに含まれる取扱品目のうち、当該指定を受け付けた朝市ＩＤ及び開催日に対応する取扱品目を読み出す。そして、受付部１７ａは、先に取扱品目として読み出された産物ＣＤの各々に対応する産物が登載された一覧画面を生成した上で当該一覧画面をクライアント端末３０へ送信する。その上で、受付部１７ａは、クライアント端末３０に表示された一覧画面上で産物の一覧の中から産物の指定を受け付ける。

他の一態様としては、受付部１７ａは、ポータルサイトのログイン認証時に用いられたアカウントを用いて、朝市および開催日の指定を自動的に受け付けることもできる。例えば、受付部１７ａは、記憶部１３に記憶された予約情報１３ｄの中からクライアント端末３０によってポータルサイトへのログイン認証時に使用されたユーザの会員ＩＤを含むレコードを検索する。かかるレコードの検索によって、当該ユーザが宿泊する予定のある宿泊施設ＩＤ及び宿泊日を抽出できる。そして、受付部１７ａは、宿泊施設情報１３ｃに含まれる朝市ＩＤのうち、先に抽出された宿泊施設ＩＤに対応付けられた朝市ＩＤを絞り込む。その上で、受付部１７ａは、朝市情報１３ｂに含まれる開催日を参照して、先に絞り込まれた朝市ＩＤのうち開催日が宿泊日の日付と一致する朝市ＩＤを抽出する。これによって、ユーザが宿泊施設を予約した日付であり、かつ宿泊施設の周辺にある朝市に関する産物の一覧画面を自動的に表示させることもできる。

特定部１７ｂは、在庫数を特定する処理部である。

一態様としては、特定部１７ｂは、産物情報１３ｅに含まれる産物の最大購入可能人数のうち、受付部１７ａによって指定が受け付けられた産物の産物ＣＤに対応する最大購入可能人数を参照する。そして、特定部１７ｂは、受付部１７ａによって指定が受け付けられた産物の最大購入可能人数が複数人であるか否か、すなわち当該指定を受け付けた産物に共同購入が認められるか否かを判定する。

このとき、特定部１７ｂは、最大購入可能人数が複数人でない場合、すなわち当該指定を受け付けた産物に共同購入が認められない場合には、当該指定を受け付けた産物の産物ＣＤを用いて、産物の在庫数を特定する。例えば、特定部１７ｂは、産物情報１３ｅに含まれる在庫数のうち当該指定を受け付けた産物の産物ＣＤに対応する在庫数を読み出す。また、特定部１７ｂは、当該指定を受け付けた産物の産物ＣＤに対応するレコードに登録がある一時確保者ＩＤ及び購入者ＩＤの数を集計し、該集計された集計値を入庫数から差し引くことによって在庫数を算出することもできる。このように、共同購入が認められていない産物の場合には、ユーザによって購入される個数の単位が１以上であり、１未満の端数が生じないので、全てのユーザには同じ在庫数が表示されることになる。

一方、特定部１７ｂは、最大購入可能人数が複数人である場合、すなわち当該指定を受け付けた産物に共同購入が認められる場合には、次のような処理を実行する。すなわち、特定部１７ｂは、当該指定を受け付けた産物の産物ＩＤごとに、産物ＩＤに対応する産物情報１３ｅのレコード内の仮購入者ＩＤ、一時確保者ＩＤ及び購入者ＩＤの有無を照査することによって図示しない内部メモリに保持された在庫数を計数する。

具体的には、特定部１７ｂは、当該指定を受け付けた産物の産物ＣＤに含まれる産物ＩＤのうち１つを選択する。続いて、特定部１７ｂは、産物情報１３ｅに含まれるレコードのうち先に選択された産物ＩＤに対応するレコードが持つ購入者ＩＤのフィールドに会員ＩＤの登録があるか否かを判定する。このとき、購入者ＩＤのフィールドに会員ＩＤの登録がある場合には、当該産物ＩＤに対応する産物が既に販売済みであることがわかる。この場合には、当該産物ＩＤに対応する産物は在庫にカウントされない。一方、特定部１７ｂは、購入者ＩＤのフィールドに会員ＩＤの登録がない場合には、産物情報１３ｅに含まれるレコードのうち先に選択された産物ＩＤに対応するレコードが持つ一時確保者ＩＤのフィールドに会員ＩＤの登録があるか否かをさらに判定する。このとき、一時確保者ＩＤのフィールドに会員ＩＤの登録がある場合には、当該産物ＩＤに対応する産物の購入は一時確保者に優先権がある。この場合にも、当該産物ＩＤに対応する産物は在庫にカウントされない。そして、特定部１７ｂは、一時確保者ＩＤのフィールドに会員ＩＤの登録がない場合には、産物情報１３ｅに含まれるレコードのうち先に選択された産物ＩＤに対応するレコードが持つ仮購入者ＩＤのフィールドに会員ＩＤの登録があるか否かをさらに判定する。

ここで、仮購入者ＩＤのフィールドに会員ＩＤの登録がある場合には、当該ユーザからの仮購入の受け付けを許容するか否かを判定する。具体的には、特定部１７ｂは、産物の指定を行ったユーザと仮購入者との間で、互いの宿泊施設及び宿泊日が同一であるか否かを判定する。例えば、特定部１７ｂは、予約情報１３ｄに含まれる宿泊施設ＩＤのうちポータルサイトのログイン認証時に使用された会員ＩＤに対応する宿泊施設ＩＤ及び宿泊日を読み出す。これとともに、特定部１７ｂは、予約情報１３ｄに含まれる宿泊施設ＩＤのうち仮購入者ＩＤに登録がある会員ＩＤに対応する宿泊施設ＩＤ及び宿泊日を読み出す。その上で、特定部１７ｂは、互いの宿泊施設ＩＤ及び宿泊日が同一であるか否かを判定する。

このとき、互いの宿泊施設ＩＤ及び宿泊日が同一である場合には、産物の指定を行ったユーザと仮購入者との宿泊先及び宿泊日が同一であることがわかる。この場合には、現地の宿泊先でユーザ及び仮購入者で１つの産物を共同で消費できるので、当該ユーザの仮購入を許容できる。したがって、特定部１７ｂは、当該産物の最大購入可能人数、すなわち分割数に対応する１未満の端数を内部メモリに保持された在庫数に加算する。例えば、図７に示した産物ＩＤ「Ｐ０５０−１」の幻の柚子を例に挙げれば、幻の柚子の分割数は「２」であり、かつ既に会員ＩＤ「Ｒ００２」の佐藤次郎によって先に仮購入がなされているので、残りの１／２個が在庫数に加算される。このように、分割数を分母とし、分割数から仮購入者ＩＤの登録がある会員ＩＤの数が差し引かれた減算値を分子として１未満の分数を内部メモリに保持された在庫数に加算すればよい。

一方、互いの宿泊施設ＩＤ及び宿泊日のうち少なくともいずれか一方が異なる場合には、産物の指定を行ったユーザと仮購入者とで１つの産物を共同で消費できないことがわかる。この場合には、仮購入は許容できないので、当該産物ＩＤに対応する在庫にはカウントされない。

また、仮購入者ＩＤのフィールドにも会員ＩＤの登録がない場合には、当該指定を受け付けた産物は、購入も、一時確保も、仮購入もなされていないことが判明する。この場合には、ユーザは１／２個、もしくは、１個の数量選択が可能であることがわかる。特定部１７ｂは、内部メモリに保持された在庫数１を在庫としてカウントする。

このように、特定部１７ｂは、産物ＣＤに含まれる全ての産物ＩＤの選択を終了するまで、上記の産物の在庫数の計数を繰り返し実行する。その後、全ての産物ＩＤを対象に在庫数が計数された時点で内部メモリに保持されている在庫数が、当該ユーザにとっての在庫数として求まる。

このことから、同一の宿泊先及び宿泊日で仮購入を行った仮購入者が存在する産物ＩＤには、在庫数として１未満の端数が提示される一方で、産物に対して仮購入者がいるもののその仮購入者の中に当該ユーザと同一の宿泊先及び宿泊日である仮購入者が存在しない場合には、在庫数として１未満の端数が提示されない。言い換えれば、同一の宿泊先及び宿泊日で仮購入を行った仮購入者が存在するユーザは、仮購入が認められる分、同一の宿泊先及び宿泊日で仮購入を行った仮購入者が存在しないユーザよりも在庫数が多く表示される場合がある。

生成部１７ｃは、購入用画面を生成する処理部である。

一態様としては、生成部１７ｃは、産物を購入する数量を選択するＧＵＩを含む購入用画面を生成する。具体的には、生成部１７ｃは、特定部１７ｂによって産物の在庫数が特定された後に、内部メモリに保持された産物の在庫数を参照して、産物の在庫数が「０」よりも大きいか否かを判定する。そして、生成部１７ｃは、産物の在庫数が「０」よりも大きい場合には、当該産物の在庫の中に仮購入の登録がない産物ＩＤのレコードが存在するか否かを判定する。このとき、当該産物の在庫の中に仮購入の登録がない産物ＩＤのレコードが存在する場合には、産物の指定を行ったユーザが最初の仮購入を行うことができることが判明する。よって、生成部１７ｃは、分割商品の選択を許容する。一方、当該産物の在庫の中に仮購入の登録がない産物ＩＤのレコードが存在しない場合には、産物の指定を行ったユーザが最初の仮購入を行うことができないことが判明する。この場合には、生成部１７ｃは、産物の在庫数に１未満の端数が存在するか否かを判定する。これによって、産物の指定を行ったユーザが２番目以降に仮購入を行う条件を有するか否か、すなわち最初に仮購入を行ったユーザとの間で宿泊先及び宿泊日が同一であるか否かを判別できる。そして、産物の在庫数に１未満の端数が存在する場合には、産物の指定を行ったユーザが２番目以降に仮購入を行う資格を持つことがわかる。この場合には、生成部１７ｃは、分割商品の選択を許容する。

このように分割商品の仮購入を許容する場合、生成部１７ｃは、１未満の数量を選択肢に持つ数量選択のＧＵＩを含む購入用画面を生成する。例えば、生成部１７ｃは、産物に設定された分割数に対応する１未満の分数または小数を選択肢に持つプルダウンメニューやラジオボタンを購入用画面に含める。このとき、生成部１７ｃは、産物の在庫数の表示を購入用画面にさらに含めることもできる。さらに、生成部１７ｃは、当該ユーザの仮購入によって共同購入が成立するか否かによって購入用画面に表示させるメッセージを変えてもよい。例えば、生成部１７ｃは、当該ユーザの仮購入によって共同購入が成立する場合、一例として、仮購入がなされた場合には共同購入が成立する旨のメッセージをさらに購入用画面に含める。これによって、購買意欲を高めることができる。一方、生成部１７ｃは、当該ユーザが仮購入を行った時点では共同購入が成立しない場合、一例として、他のユーザの仮購入を待って共同購入が成立する旨のメッセージをさらに購入用画面に含める。これによって、仮購入を行っても分割商品の購入が完了しない状況、言い換えれば他のユーザによる仮購入が共同購入の条件となる状況を明示できる。このようにして生成された購入用画面は、クライアント端末３０へ送信される。

一方、産物の在庫数に１未満の端数が存在しない場合には、産物の指定を行ったユーザが２番目以降に仮購入を行う資格も持たないことがわかる。この場合には、生成部１７ｃは、分割商品の選択を許容せず、整数の数量を選択肢に持つ数量選択のＧＵＩを含む購入用画面を生成する。このようにして生成された購入用画面も、クライアント端末３０へ送信される。

なお、産物の在庫数が「０」である場合には、在庫数が「０」とされた購入用画面を生成することとしてもかまわない。この場合には、数量を選択させるプルダウンメニュー等のＧＵＩには、選択肢を表示させないか、「０」の選択肢に絞って表示させるか、あるいは入荷待ちの旨を表示させることができる。また、産物の在庫数が「０」である場合には、産物一覧画面上で産物を指定された後に生成される購入用画面の代わりに、「在庫なし」や「入荷待ち」等のメッセージをポップアップさせてもよい。または、産物一覧画面上に在庫なしであることを表示させる、または、在庫がない産物は産物一覧画面に表示させないこととしてもかまわない。

更新部１７ｄは、産物情報１３ｅに対する更新を実行する処理部である。

一態様としては、更新部１７ｄは、クライアント端末３０に表示された購入用画面上で産物の購入要求を受け付けた場合に、当該購入要求が分割商品の仮購入であるか否かを判定する。このとき、更新部１７ｄは、購入要求が分割商品の仮購入でない場合、すなわちショッピングカートへの登録が行われた場合に、産物情報１３ｅに含まれる産物ＣＤのレコードのうち当該ショッピングカートへの登録が行われた産物の産物ＣＤに対応する一時確保者ＩＤのフィールドに当該ショッピングカートへの登録を行ったユーザの会員ＩＤを登録する。例えば、最大購入可能人数が「１」である産物の購入要求を受け付けたならば、更新部１７ｄは、産物情報１３ｅに含まれるレコードのうち当該購入要求を受け付けた産物の産物ＣＤに対応する一時確保者ＩＤのフィールドへ当該購入要求を行ったユーザの会員ＩＤを登録する。また、最大購入可能人数が「２」以上である産物の購入要求を受け付けたならば、更新部１７ｄは、産物情報１３ｅに含まれるレコードのうち当該購入要求を受け付けた産物の産物ＣＤに対応付けられている産物ＩＤのレコードであり、かつ仮購入者ＩＤ及び一時確保者ＩＤの両方のフィールドに空きがあるレコードの一時確保者ＩＤのフィールドへ当該購入要求を行ったユーザの会員ＩＤを登録する。

一方、更新部１７ｄは、購入要求が分割商品の仮購入である場合に、当該仮購入によって共同購入が成立するか否かを判定する。すなわち、更新部１７ｄは、産物情報１３ｅに含まれる産物ＩＤのレコードのうち仮購入者ＩＤが登録されているか否かを判定する。当該仮購入を行ったユーザを加えた仮購入者の登録人数が産物の分割数に達するレコードが存在するか否かを判定する。このとき、更新部１７ｄは、仮購入を受け付けたユーザと同一の宿泊先及び同一の宿泊日で予約を行った仮購入者が登録されている産物ＩＤのレコードが産物情報１３ｅに複数存在する場合には、仮購入者の登録人数が産物の分割数に最も近い産物ＩＤのレコードを対象に共同購入の成立可否を判定する。

ここで、更新部１７ｄは、当該仮購入によって共同購入が成立する場合に、共同購入が成立する産物ＩＤのレコードから仮購入者ＩＤのフィールドに登録された会員ＩＤを一時確保者ＩＤのフィールドへ移行登録する。これによって、当該産物ＩＤのレコードでこれ以上の仮購入が受け付けられるのを抑制して共同購入が成立した状態を維持管理する。その上で、更新部１７ｄは、当該産物ＩＤのレコードに仮購入者として登録されていたユーザに共同購入が成立した旨を後述の通知部１７ｅに通知させる。

一方、更新部１７ｄは、当該ユーザの仮購入によって共同購入が成立しない場合に、仮購入を行ったユーザの会員ＩＤを産物情報１３ｅ内の仮購入者ＩＤのフィールドへ登録する。このとき、更新部１７ｄは、仮購入を受け付けたユーザと同一の宿泊先及び同一の宿泊日で予約を行った仮購入者が登録されている産物ＩＤのレコードが産物情報１３ｅに複数存在する場合には、仮購入者の登録人数が産物の分割数に最も近い産物ＩＤのレコードを対象に、仮購入者ＩＤのフィールドへの会員ＩＤの登録を実行する。これによって、当該仮購入を行ったユーザが仮購入者として管理されることになる。

このように、更新部１７ｄは、ショッピングカートへの登録または分割商品の仮購入を受け付けた場合には、産物情報１３ｅに含まれるレコードのうちショッピングカートへの登録または分割商品の仮購入を受け付けた産物の産物ＣＤまたは産物ＩＤのレコードが持つ在庫数を更新する。例えば、ショッピングカートへの登録を受け付けた場合には、整数単位で産物が販売される。このため、更新部１７ｄは、ショッピングカートへの登録を受け付けた整数の個数を現在の在庫数から減算する更新を実行する。一方、分割商品の仮購入を受け付けた場合には、１未満の分数または小数の単位で分割商品が販売される。このため、更新部１７ｄは、仮購入を受け付けた分数または小数の個数を現在の在庫数から減算する更新を実行する。

他の一態様としては、更新部１７ｄは、後述の決済部１７ｆによって決済処理が実行された場合に、次のような処理を実行する。すなわち、更新部１７ｄは、産物情報１３ｅに含まれる産物ＩＤのレコードのうち一時確保者ＩＤのフィールドに当該決済処理が実行されたユーザの会員ＩＤが登録されたレコードを対象に、当該ユーザの会員ＩＤを一時確保者ＩＤのフィールドから購入者ＩＤのフィールドへ移行登録する。これによって、当該決済処理を行ったユーザが購入者として管理されることになる。

更なる一態様としては、更新部１７ｄは、産物情報１３ｅに含まれる産物ＩＤのレコードのうち仮購入者ＩＤに会員ＩＤの登録があるレコードを対象に、仮購入を受け付けてからの経過期間を監視する。例えば、更新部１７ｄは、産物情報１３ｅに含まれる産物ＩＤのレコードのうち仮購入者ＩＤに会員ＩＤの登録があるレコードを抽出する。続いて、更新部１７ｄは、先に抽出された産物ＩＤのレコードの中からレコードを１つ選択する。その上で、更新部１７ｄは、先に選択された産物ＩＤのレコードで最初または最後に仮購入を受け付けた時点から起算して仮購入の経過時間が所定の制限時間に達するか否かを判定する。かかる制限時間の一例としては、朝市情報１３ｂに含まれる制限時間のうち当該産物を提供する朝市に対応付けられた制限時間を採用できる。このとき、更新部１７ｄは、仮購入の経過時間が制限時間に達する場合には、産物ＩＤのレコードが持つ仮購入者ＩＤのフィールドに登録されている会員ＩＤを削除する。これによって、既に仮購入を行った仮購入者との間で宿泊先及び宿泊日が同一であるユーザに絞って仮購入を受け付けるといった寡占状態が一定の時間制限で解除される。このため、改めて宿泊先を問わずに仮購入や一時確保を受け付けることができる結果、仮購入者の登録人数が所定の人数に到達せずに産物を販売し損なう事態を抑制できる。その上で、更新部１７ｄは、当該産物ＩＤのレコードに仮購入者として登録されていたユーザに仮購入が解除された旨を後述の通知部１７ｅに通知させる。

通知部１７ｅは、各種の通知を実行する処理部である。

一態様としては、通知部１７ｅは、更新部１７ｄによって共同購入が成立すると判定された場合に、産物情報１３ｅを参照して、当該共同購入が成立する産物ＩＤのレコード内の仮購入者ＩＤのフィールドに登録された会員ＩＤを持つ仮購入者の各ユーザに共同購入が成立した旨の通知もしくは決済を促す通知を実行する。このとき、通知部１７ｅは、各種の通知形態を採用できる。例えば、通知部１７ｅは、仮購入者の各ユーザが持つセッションＩＤを参照して、クライアント端末３０上で動作するブラウザに上記の通知を実行できる。また、通知部１７ｅは、会員情報１３ａに含まれるアドレスを参照して、仮購入者の各ユーザをあて先とし、上記の通知内容が記述された電子メールを送信することもできる。これによって、共同購入が成立した各ユーザは、決済処理に進むことができる。

他の一態様としては、通知部１７ｅは、更新部１７ｄによって仮購入の経過時間が制限時間に達すると判定された場合に、産物情報１３ｅを参照して、仮購入の経過時間が制限時間に達する産物ＩＤのレコード内の仮購入者ＩＤのフィールドに登録された会員ＩＤを持つ仮購入者の各ユーザに仮購入が解除された旨の通知を実行する。この場合にも、通知部１７ｅは、上述した各種の通知形態を採用できる。

決済部１７ｆは、産物の代金に関する決済処理を実行する処理部である。一態様としては、決済部１７ｆは、クライアント端末３０上で動作するブラウザから決済要求を受け付けた場合に、当該決済要求を行うユーザが指定する決済方法で産物の代金を決済する決済処理を実行する。例えば、決済部１７ｆは、会員情報１３ａとして登録させておいた決済情報、例えばデビットカードやクレジットカードのカード情報を用いて、ユーザが金融機関に持つ口座から産物の代金に対応する金額を朝市の主催者の口座へ振り込むことができる。

なお、制御部１５には、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などに販売処理プログラムを実行させることによって実現できる。また、上記の販売処理部１７は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などのハードワイヤードロジックによっても実現できる。

［具体例１］
ここで、図８〜図１１を用いて、上記の販売処理サービスの具体例１について説明する。図８は、分割商品の仮購入時における共同購入の成立可否の場合分けの一例を示す図である。また、図９〜図１１は、購入用画面の一例を示す図である。これら図８〜図１１には、図３に示した会員ＩＤ「Ｒ００１」の鈴木一郎が図７に示した産物ＣＤ「Ｐ０５０」の幻の柚子を仮購入する場合の例が示されている。なお、図８〜図１１では、幻の柚子が２分割される場合を想定して以下の説明を行う。

図８には、産物ＣＤ「Ｐ０５０」の幻の柚子の在庫数が３個であるという状況の仮定の下、下記の（イ）〜（ハ）の３つのケースの場合分けが図示されている。このうち、ケース（イ）として、他のユーザの誰からも仮購入を受けていない場合が例示されている。また、ケース（ロ）として、会員ＩＤ「Ｒ００１」の鈴木一郎と同一の宿泊施設を同一の宿泊日に予約している会員ＩＤ「Ｒ００２」の佐藤次郎から先だって仮購入を受け付けている場合が例示されている。さらに、ケース（ハ）として、会員ＩＤ「Ｒ００１」の鈴木一郎と異なる宿泊施設を予約している会員ＩＤ「Ｒ００３」の香川三太から先だって仮購入を受け付けている場合が例示されている。

このうち、上記のケース（イ）の場合、図９に示す購入用画面が会員ＩＤ「Ｒ００１」の鈴木一郎が使用するクライアント端末３０に送信される。この場合、幻の柚子の在庫数が３個であり、他のユーザの誰からも仮購入を受けていないので、会員ＩＤ「Ｒ００１」の鈴木一郎は、幻の柚子を購入する数量を最大で３個まで選択できる。さらに、会員ＩＤ「Ｒ００１」の鈴木一郎は、他のユーザによって仮購入されていない幻の柚子が３個残っているので、幻の柚子「１／２個」を仮購入することができる。その一方で、会員ＩＤ「Ｒ００１」の鈴木一郎が幻の柚子「１／２個」を仮購入したとしても、鈴木一郎は最初の仮購入を行うことになるので、共同購入は成立しない。よって、図９に示すように、数量の選択肢として「３」、「２」、「１」及び「１／２」を含むプルダウンメニューとともに、一例として、次のようなメッセージを購入画面に表示できる。かかるメッセージの一例としては、「まだ仮購入です。１／２個を購入した場合、後で同じホテルの宿泊者が１／２個を購入した場合に共同購入が成立します。」というメッセージを表示できる。

また、上記のケース（ロ）の場合、図１０に示す購入用画面が会員ＩＤ「Ｒ００１」の鈴木一郎が使用するクライアント端末３０に送信される。この場合、幻の柚子の在庫数が３個であり、会員ＩＤ「Ｒ００１」の鈴木一郎と同一の宿泊施設を同一の宿泊日に予約している会員ＩＤ「Ｒ００２」の佐藤次郎から先だって仮購入を受け付けている。よって、会員ＩＤ「Ｒ００１」の鈴木一郎は、最大で在庫数「３個」のうち会員ＩＤ「Ｒ００２」の佐藤次郎が仮購入していない２個まで数量を指定できる。さらに、会員ＩＤ「Ｒ００１」の鈴木一郎は、他のユーザによって仮購入されていない幻の柚子が２個残っているので、幻の柚子「１／２個」を仮購入することもできる。その上、会員ＩＤ「Ｒ００１」の鈴木一郎が幻の柚子「１／２個」を仮購入する場合には、鈴木一郎の仮購入によって仮購入者の数が２人となり、共同購入が成立する。よって、図１０に示すように、数量の選択肢として、「２」、「１」及び「１／２」を含むプルダウンメニューとともに、一例として、次のようなメッセージを購入画面に表示できる。かかるメッセージの一例としては、「１／２個を購入した場合、他のユーザとの共同購入が成立します。」というメッセージを表示できる。

さらに、上記のケース（ハ）の場合、図１１に示す購入用画面が会員ＩＤ「Ｒ００１」の鈴木一郎が使用するクライアント端末３０に送信される。この場合、幻の柚子の在庫数が３個であり、会員ＩＤ「Ｒ００１」の鈴木一郎と異なる宿泊施設を予約している会員ＩＤ「Ｒ００３」の香川三太から先だって仮購入を受け付けている。よって、最大で在庫数「３個」のうち会員ＩＤ「Ｒ００３」の香川三太が仮購入していない２個まで数量を指定できる。そして、会員ＩＤ「Ｒ００１」の鈴木一郎は、他のユーザによって仮購入されていない幻の柚子が２個残っているので、幻の柚子「１／２個」を仮購入することもできる。一方、会員ＩＤ「Ｒ００１」の鈴木一郎が幻の柚子「１／２個」を仮購入したとしても、佐藤次郎とは共同購入を行うことができず、鈴木一郎は最初の仮購入を行うことになるので、共同購入は成立しない。よって、図１１に示すように、数量の選択肢として、「２」、「１」及び「１／２」を含むプルダウンメニューとともに、一例として、上記の（イ）と同様のメッセージを購入画面に表示できる。

このように、他のユーザによって仮購入されていない幻の柚子が残っている場合には、図８〜図１１に示したように、１／２個を選択するボタンが表示されることになる。また、宿泊先が同一である他のユーザが先に仮購入を行っているか否かによって上記のケース（ロ）とケース（ハ）とのように、在庫数の表示が変わる。

なお、上記のケース（ロ）及び上記のケース（ハ）で制限時間までに仮購入者が２名に達しなかった場合には、会員ＩＤ「Ｒ００２」の佐藤次郎または会員ＩＤ「Ｒ００３」の香川三太が仮購入者ＩＤのエントリから削除される。この場合には、全てのユーザに図９に示す購入用画面と同様の画面が表示されることになる。

［具体例２］
図１２〜図１５を用いて、上記の具体例１とは異なる具体例２について説明する。図１２は、分割商品の仮購入時における共同購入の成立可否の場合分けの一例を示す図である。また、図１３〜図１５は、購入用画面の一例を示す図である。これら図１２〜図１５においても、図３に示した会員ＩＤ「Ｒ００１」の鈴木一郎が図７に示した産物ＣＤ「Ｐ０５０」の幻の柚子を仮購入する場合の例が示されている。なお、図１２〜図１５においても、幻の柚子が２分割される場合を想定して以下の説明を行う。

図１２には、産物ＣＤ「Ｐ０５０」の幻の柚子の在庫数が１個であるという状況の仮定の下、上記の具体例１で例示した（イ）〜（ハ）の３つのケースの場合分けが図示されている。

このうち、上記のケース（イ）の場合、図１３に示す購入用画面が会員ＩＤ「Ｒ００１」の鈴木一郎が使用するクライアント端末３０に送信される。この場合、幻の柚子の在庫数が１個であり、他のユーザの誰からも仮購入を受けていないので、会員ＩＤ「Ｒ００１」の鈴木一郎は、幻の柚子を購入する数量を最大で１個まで選択できる。さらに、会員ＩＤ「Ｒ００１」の鈴木一郎は、他のユーザによって仮購入されていない幻の柚子が１個残っているので、幻の柚子「１／２個」を仮購入することができる。その一方で、会員ＩＤ「Ｒ００１」の鈴木一郎が幻の柚子「１／２個」を仮購入したとしても、鈴木一郎は最初の仮購入を行うことになるので、共同購入は成立しない。よって、図１３に示すように、数量の選択肢として「１」及び「１／２」を含むプルダウンメニューとともに、一例として、次のようなメッセージを購入画面に表示できる。かかるメッセージの一例としては、「まだ仮購入です。１／２個を購入した場合、後で同じホテルの宿泊者が１／２個を購入した場合に共同購入が成立します。」というメッセージを表示できる。

また、上記のケース（ロ）の場合、図１４に示す購入用画面が会員ＩＤ「Ｒ００１」の鈴木一郎が使用するクライアント端末３０に送信される。この場合、幻の柚子の在庫数が１個であり、会員ＩＤ「Ｒ００１」の鈴木一郎と同一の宿泊施設を同一の宿泊日に予約している会員ＩＤ「Ｒ００２」の佐藤次郎から先だって仮購入を受け付けている。このため、会員ＩＤ「Ｒ００１」の鈴木一郎は、他のユーザによって仮購入されていない幻の柚子が１個も残っていないので、整数の単位では数量を指定できない。ところが、会員ＩＤ「Ｒ００１」の鈴木一郎は、会員ＩＤ「Ｒ００２」の佐藤次郎と共同購入することはできるので、幻の柚子「１／２個」を仮購入することはできる。よって、図１４に示すように、数量の選択肢として、「１／２」を含むプルダウンメニューとともに、一例として、次のようなメッセージを購入画面に表示できる。かかるメッセージの一例としては、「１／２個を購入した場合、他のユーザとの共同購入が成立します。」というメッセージを表示できる。

さらに、上記のケース（ハ）の場合、図１５に示す購入用画面が会員ＩＤ「Ｒ００１」の鈴木一郎が使用するクライアント端末３０に送信される。この場合、幻の柚子の在庫数が１個であり、会員ＩＤ「Ｒ００１」の鈴木一郎と異なる宿泊施設を予約している会員ＩＤ「Ｒ００３」の香川三太から先だって仮購入を受け付けている。このため、他のユーザによって仮購入されていない幻の柚子が１個も残っておらず、また、会員ＩＤ「Ｒ００３」の香川三太が仮購入を行っている幻の柚子を共同購入することもできない。したがって、会員ＩＤ「Ｒ００１」の鈴木一郎は、整数の単位でも分数の単位でも、数量を指定することはできない。よって、図１５に示すように、数量の選択肢がない購入用画面が表示されることになる。

このように、他のユーザによって仮購入されていない幻の柚子が残っていない場合には、図１２〜図１５に示したように、宿泊先が同一である他のユーザが先に仮購入を行っているか否か、すなわち上記のケース（ロ）または上記のケース（ハ）であるかによって１／２個を選択するボタンが表示されるか否かが変わる。

なお、上記のケース（ロ）及び上記のケース（ハ）で制限時間までに仮購入者が２名に達しなかった場合には、会員ＩＤ「Ｒ００２」の佐藤次郎または会員ＩＤ「Ｒ００３」の香川三太が仮購入者ＩＤのエントリから削除される。この場合には、全てのユーザに図１３に示す購入用画面と同様の画面が表示されることになる。

［処理の流れ］
続いて、本実施例に係るサーバ装置１０の処理の流れについて説明する。なお、以下では、サーバ装置１０によって実行される（１）販売処理、（２）第２の生成処理、（３）監視処理の順に説明を行うこととする。

（１）販売処理
図１６は、実施例１に係る販売処理の手順を示すフローチャートである。この処理は、クライアント端末３０に表示されるＷｅｂページ、例えばポータルサイトが提供するトップページを介して、閲覧対象とする朝市および開催日の指定を受け付けた場合に開始される。

図１６に示すように、クライアント端末３０から閲覧対象とする朝市および開催日の指定を受け付けると（ステップＳ１０１）、受付部１７ａは、次のような処理を実行する。すなわち、受付部１７ａは、朝市情報１３ｂに含まれる朝市ＩＤ及び開催日のうちステップＳ１０１で指定を受け付けた朝市ＩＤ及び開催日に対応する取扱品目を読み出し、例えば図７に示す産物情報１３ｅを参照して産物ＣＤに対応する産物名を取得する（ステップＳ１０１５）。その上で、受付部１７ａは、取扱品目として読み出された産物ＣＤの各々に対応する産物が登載された一覧画面を生成する（ステップＳ１０２）。このようにして生成された産物の一覧画面は、クライアント端末３０へ送信される。

その後、受付部１７ａは、クライアント端末３０に表示された産物の一覧画面上で産物の一覧の中から産物の指定を受け付ける（ステップＳ１０３）。続いて、特定部１７ｂは、産物情報１３ｅに含まれる産物の最大購入可能人数を参照して、ステップＳ１０３で指定が受け付けられた産物の最大購入可能人数が複数人であるか否か、すなわち当該指定を受け付けた産物に共同購入が認められるか否かを判定する（ステップＳ１０４）。

このとき、最大購入可能人数が複数人でない場合、すなわち当該指定を受け付けた産物に共同購入が認められない場合（ステップＳ１０４Ｎｏ）には、下記の第１の生成処理によって販売用画面が生成される（ステップＳ１０５）。すなわち、ステップＳ１０５では、ステップＳ１０３で指定を受け付けた産物の産物ＣＤを用いて特定された産物の在庫数を用いて、整数の数量を選択肢に持つ数量選択のＧＵＩを含む購入用画面が第１の生成処理によって生成される。

一方、最大購入可能人数が複数人である場合、すなわち当該指定を受け付けた産物に共同購入が認められる場合（ステップＳ１０４Ｙｅｓ）には、下記の第２の生成処理を実行する。詳細は図１７を用いて後述するが、ステップＳ１０６では、ステップＳ１０３で指定を受け付けた産物の産物ＩＤを用いて特定された産物の在庫数から分割商品の選択の可能または不可能を判定した上で、数量選択のＧＵＩを含む購入用画面が第２の生成処理によって生成される。

その後、生成部１７ｃは、ステップＳ１０５またはステップＳ１０６で生成された購入用画面をクライアント端末３０へ送信する（ステップＳ１０７）。そして、更新部１７ｄは、クライアント端末３０に表示された購入用画面上で産物の購入要求を受け付けると（ステップＳ１０８）、当該購入要求が分割商品の仮購入であるか否かを判定する（ステップＳ１０９）。

このとき、購入要求が分割商品の仮購入でない場合、すなわちショッピングカートへの登録が行われた場合（ステップＳ１０９Ｎｏ）には、更新部１７ｄは、産物情報１３ｅに含まれる産物ＣＤのレコードうち当該ショッピングカートへの登録が行われた産物の産物ＣＤのレコードが持つ一時確保者ＩＤのフィールドに当該ショッピングカートへの登録を行ったユーザの会員ＩＤを登録する（ステップＳ１１０）。

一方、購入要求が分割商品の仮購入である場合（ステップＳ１０９Ｙｅｓ）には、更新部１７ｄは、当該仮購入によって共同購入が成立するか否かをさらに判定する（ステップＳ１１１）。

このとき、当該仮購入によって共同購入が成立する場合（ステップＳ１１１Ｙｅｓ）には、更新部１７ｄは、共同購入が成立する産物ＩＤのレコードから仮購入者ＩＤのフィールドに登録された会員ＩＤを一時確保者ＩＤのフィールドへ移行登録する（ステップＳ１１２）。その上で、更新部１７ｄは、当該産物ＩＤのレコードに仮購入者として登録されていたユーザに共同購入が成立した旨を後述の通知部１７ｅに通知させる（ステップＳ１１３）。

また、ユーザの仮購入によって共同購入が成立しない場合（ステップＳ１１１Ｎｏ）には、更新部１７ｄは、仮購入を行ったユーザの会員ＩＤを産物情報１３ｅ内の仮購入者ＩＤのフィールドへ登録する（ステップＳ１１４）。

上記のステップＳ１１０、ステップＳ１１２またはステップＳ１１４のように、ショッピングカートへの登録または分割商品の仮購入を受け付けた場合には、更新部１７ｄは、産物情報１３ｅに含まれるレコードのうちショッピングカートへの登録または分割商品の仮購入を受け付けた産物の産物ＣＤまたは産物ＩＤのレコードが持つ在庫数を更新する（ステップＳ１１５）。

その後、クライアント端末３０上で動作するブラウザから決済要求を受け付けた場合（ステップＳ１１６Ｎｏ）には、上記のステップＳ１０２〜ステップＳ１１５までの処理を繰り返し実行する。

また、クライアント端末３０上で動作するブラウザから決済要求を受け付けた場合（ステップＳ１１６Ｙｅｓ）には、決済部１７ｆは、当該決済要求を行うユーザが指定する決済方法で産物の代金を決済する決済処理を実行する（ステップＳ１１７）。

そして、更新部１７ｄは、産物情報１３ｅに含まれる産物ＩＤのレコードのうち一時確保者ＩＤのフィールドに当該決済処理が実行されたユーザの会員ＩＤが登録されたレコードを対象に、当該ユーザの会員ＩＤを一時確保者ＩＤのフィールドから購入者ＩＤのフィールドへ移行登録し（ステップＳ１１８）、処理を終了する。

（２）第２の生成処理
図１７は、実施例１に係る第２の生成処理の手順を示すフローチャートである。この処理は、図１６に示したステップＳ１０６の処理に対応するサブルーチンであり、最大購入可能人数が複数人である場合、すなわち当該指定を受け付けた産物に共同購入が認められる場合に処理が起動される。

図１７に示すように、特定部１７ｂは、図６に示す予約情報１３ｄを参照してログインユーザの会員ＩＤに対応する宿泊先情報、例えば宿泊施設ＩＤや宿泊日等を取得する（ステップＳ３００）。そして、特定部１７ｂは、図７に示す産物情報１３ｅを参照して、ステップＳ１０３で指定を受け付けた産物の産物ＣＤに対応する産物ＩＤのうち１つを選択する（ステップＳ３０１）。続いて、特定部１７ｂは、産物情報１３ｅに含まれるレコードのうちステップＳ３０１で選択された産物ＩＤに対応する購入者ＩＤのフィールドに会員ＩＤの登録があるか否かを判定する（ステップＳ３０２）。

このとき、購入者ＩＤのフィールドに会員ＩＤの登録がある場合（ステップＳ３０２Ｎｏ）には、当該産物ＩＤに対応する産物が既に販売済みであることがわかる。この場合には、当該産物ＩＤは産物の在庫としてカウントせず、ステップＳ３０９の処理へ移行する。

一方、購入者ＩＤのフィールドに会員ＩＤの登録がない場合（ステップＳ３０２Ｙｅｓ）には、特定部１７ｂは、産物情報１３ｅに含まれるレコードのうちステップＳ３０１で選択された産物ＩＤに対応する一時確保者ＩＤのフィールドに会員ＩＤの登録があるか否かをさらに判定する（ステップＳ３０３）。

このとき、一時確保者ＩＤのフィールドに会員ＩＤの登録がある場合（ステップＳ３０３Ｎｏ）には、当該産物ＩＤの購入は一時確保者に優先権がある。この場合にも、当該産物ＩＤは産物の在庫としてカウントせず、ステップＳ３０９の処理へ移行する。

そして、一時確保者ＩＤのフィールドに会員ＩＤの登録がない場合（ステップＳ３０３Ｙｅｓ）には、特定部１７ｂは、産物情報１３ｅに含まれるレコードのうちステップＳ３０１で選択された産物ＩＤに対応する仮購入者ＩＤのフィールドに会員ＩＤの登録があるか否かをさらに判定する（ステップＳ３０４）。

ここで、仮購入者ＩＤのフィールドに会員ＩＤの登録がある場合（ステップＳ３０４Ｙｅｓ）には、当該ユーザからの仮購入の受け付けを許容することができるか否かの判定に移行する。特定部１７ｂは、産物の指定を行ったユーザと仮購入者との間で、互いの宿泊施設及び宿泊日が同一であるか否かを判定する（ステップＳ３０５及びステップＳ３０６）。

このとき、互いの宿泊施設ＩＤ及び宿泊日が同一である場合（ステップＳ３０５ＹｅｓかつステップＳ３０６Ｙｅｓ）には、産物の指定を行ったユーザと仮購入者との宿泊先及び宿泊日が同一であることがわかる。この場合には、現地の宿泊先でユーザ及び仮購入者で１つの産物を共同で消費できるので、当該ユーザの仮購入を許容できる。したがって、特定部１７ｂは、当該産物ＩＤをログインユーザに表示する在庫としてカウントするとともに、当該産物の最大購入可能人数を用いて算出した、分割数に対応する１未満の端数を内部メモリに保持された在庫数に加算する（ステップＳ３０７）。

一方、互いの宿泊施設ＩＤ及び宿泊日のうち少なくともいずれか一方が異なる場合（ステップＳ３０５ＮｏまたはステップＳ３０６Ｎｏ）には、産物の指定を行ったユーザと仮購入者とで１つの産物を共同で消費できないことがわかる。この場合には、仮購入は許容できないので、当該産物ＩＤに対応する産物はログインユーザに表示する在庫としてカウントせず、ステップＳ３０９の処理へ移行する。

また、仮購入者ＩＤのフィールドにも会員ＩＤの登録がない場合（ステップＳ３０４Ｎｏ）には、当該指定を受け付けた産物は、購入も、一時確保も、仮購入もなされていないことが判明する。この場合には、特定部１７ｂは、内部メモリに保持された在庫数を１つインクリメントする（ステップＳ３０８）。

このように、特定部１７ｂは、産物ＣＤに含まれる全ての産物ＩＤの選択を終了するまで（ステップＳ３０９Ｎｏ）、上記のステップＳ３０１〜ステップＳ３０８までの処理を繰り返し実行する。その後、全ての産物ＩＤを対象に在庫数が計数された時点で内部メモリに保持されている在庫数が、当該ユーザにとっての在庫数として求まる。

そして、産物ＣＤに含まれる全ての産物ＩＤの選択を終了すると（ステップＳ３０９Ｙｅｓ）、生成部１７ｃは、内部メモリに保持された産物の在庫数を参照して、産物の在庫数が「０」よりも大きいか否かを判定する（ステップＳ３１０）。

続いて、当該ユーザの在庫として求まった在庫数を用いて、数量の選択を可能とする数量選択のＧＵＩを含む購入用画面を生成する処理を実施する。産物の在庫数が「０」よりも大きい場合（ステップＳ３１０Ｙｅｓ）には、生成部１７ｃは、当該産物の在庫の中に仮購入の登録がない産物ＩＤのレコードが存在するか否かを判定する（ステップＳ３１１）。

このとき、当該産物の在庫の中に仮購入の登録がない産物ＩＤのレコードが存在しない場合（ステップＳ３１１Ｙｅｓ）すなわち、在庫すべてに仮購入者がいる場合には、産物の指定を行ったユーザが最初の仮購入を行うことができないことが判明する。この場合には、生成部１７ｃは、それぞれの産物ＩＤの在庫数として内部メモリに保持されている１未満の端数を取得する（ステップＳ３１２）。

そして、産物の在庫数に１未満の端数が存在する場合（ステップＳ３１２）には、産物の指定を行ったユーザが２番目以降に仮購入を行う資格を持つことがわかる。この場合には、生成部１７ｃは、分割商品の選択が可能であると判定する（ステップＳ３１３）。

一方、当該産物の在庫の中に仮購入の登録がない産物ＩＤのレコードが存在する場合（ステップＳ３１１Ｎｏ）には、産物の指定を行ったユーザが最初の仮購入を行うことができることが判明する。この場合には、生成部１７ｃは、後述のステップＳ３１４で生成する購入用画面に他のユーザの仮購入を待って共同購入が成立する旨のメッセージを付加することを決定し（ステップＳ３１２５）、分割商品の選択が可能であると判定する（ステップＳ３１３）。

このように分割商品の仮購入が可能である場合、生成部１７ｃは、１未満の数量を選択肢に持つ数量選択のＧＵＩを含む購入用画面を生成する（ステップＳ３１４）。例えば、生成部１７ｃは、産物に設定された分割数に対応する１未満の分数または小数を選択肢に持つプルダウンメニューやラジオボタンを購入用画面に含める。

このとき、当該ユーザの仮購入によって共同購入が成立する場合（ステップＳ３１５Ｙｅｓ）、生成部１７ｃは、仮購入がなされた現時点で共同購入が成立する旨のメッセージをさらに購入用画面に付加し（ステップＳ３１６）、処理を終了する。

一方、当該ユーザが仮購入を行った場合に共同購入が成立しない場合（ステップＳ３１５Ｎｏ）、生成部１７ｃは、他のユーザの仮購入を待って共同購入が成立する旨のメッセージをさらに購入用画面に付加し（ステップＳ３１７）、処理を終了する。

なお、産物の在庫数が「０」である場合（ステップＳ３１０Ｎｏ）には、購入用画面を生成せずにそのまま処理を終了する。ここでは、購入用画面を生成せずに処理を終了する場合を例示したが、在庫数が非表示または「０」とされた購入用画面を生成することとしてもかまわない。

（３）監視処理
図１８は、実施例１に係る監視処理の手順を示すフローチャートである。この処理は、図１６に示した販売処理が実行されている間にバックグラウンドで実行される処理であり、一定周期または定期時刻などの任意のタイミングで繰り返し実行される。

図１８に示すように、更新部１７ｄは、産物情報１３ｅに含まれる産物ＩＤのレコードのうち仮購入者ＩＤに会員ＩＤの登録があるレコードを抽出する（ステップＳ５０１）。続いて、更新部１７ｄは、ステップＳ５０１で抽出された産物ＩＤのレコードの中からレコードを１つ選択する（ステップＳ５０２）。

その上で、更新部１７ｄは、ステップＳ５０２で選択された産物ＩＤのレコードで最初または最後に仮購入を受け付けた時点から起算して仮購入の経過時間が所定の制限時間に達するか否かを判定する（ステップＳ５０３）。なお、仮購入の経過時間が制限時間に達しない場合（ステップＳ５０３Ｎｏ）には、ステップＳ５０４及びステップＳ５０５をとばし、ステップＳ５０６へ移行する。

このとき、仮購入の経過時間が制限時間に達する場合（ステップＳ５０３Ｙｅｓ）には、更新部１７ｄは、産物ＩＤのレコードが持つ仮購入者ＩＤのフィールドに登録されている会員ＩＤを削除する（ステップＳ５０４）。その上で、更新部１７ｄは、当該産物ＩＤのレコードに仮購入者として登録されていたユーザに仮購入が解除された旨を通知部１７ｅに通知させる（ステップＳ５０５）。

その後、ステップＳ５０１で抽出された産物ＩＤのレコードの中から全てのレコードを選択し終えるまで（ステップＳ５０６Ｎｏ）、上記のステップＳ５０２〜ステップＳ５０５までの処理を繰り返し実行する。そして、ステップＳ５０１で抽出された産物ＩＤのレコードの中から全てのレコードを選択し終えた場合に（ステップＳ５０６Ｙｅｓ）、処理を終了する。

［実施例１の効果］
上述してきたように、本実施例に係るサーバ装置１０は、同一商品の購入要求を行う購入者の間で互いの宿泊先が共通する場合に、１未満の分割商品の選択を許容する。

これによって、１つの商品単体で希少価値のある商品や単体でも量が多く消費しきれない商品を複数人で分割して消費できるとともに、１つの商品を複数人が購入する共同購入という枠に留まらず、各々が共通の宿泊先で分割商品を消費する共同消費を実現できる。この結果、販売側が一度の注文で商品を販売したい販売量の単位と購入側が一度の注文で商品を購入したい購入量の単位とのギャップを共同消費によって低減できる。さらに、商品の分割後に配送することによって鮮度が損なわれたり、商品が産物である場合に旅先等の現地で消費を楽しむことができなかったりといった共同購入が生むハードルも共同消費によってクリアできる。

したがって、本実施例に係るサーバ装置１０によれば、商品の販売機会を向上させることができる。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［応用例１］
上記の実施例１では、仮購入が受け付けられてない産物ＩＤのレコードへの仮購入を無制限に認める場合を例示したが、仮購入が受付中である産物ＩＤのレコード数が所定数以上である場合には、仮購入を制限することとしてもかまわない。これによって、産物を分割せずとも購入するユーザに一定の購入枠を残しておくことができる。

［応用例２］
上記の実施例１では、クライアント端末３０から指定を受け付けた産物を対象に分割商品の選択表示や１未満の在庫数の表示を実行する場合を例示したが、朝市が提供する各産物の一覧を対象に分割商品の選択表示や１未満の在庫数の表示を実行することとしてもかまわない。

［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、サーバ装置１０は、ポータルサイトの事業者が運営する装置と、朝市の主催者が運営する装置とに分散させることもできる。この場合には、図２に示した記憶部１３に記憶された各情報を朝市の主催者が運営する装置に記憶させるとともに、図２に示した販売処理部１７を朝市の主催者が運営する装置に実装させればよい。さらに、ポータルサイトの事業者のＷｅｂページから朝市の主催者のＷｅｂページへのリンクを設け、ポータルサイトを経由して朝市の主催者のＷｅｂページへアクセスさせることもできる。これによって、知名度に勝るポータルサイトを入り口とし、ポータルサイトの事業者から朝市の主催者へ会員ＩＤ等のアカウントを引き継がせることができる。また、ポータルサイトの事業者のＷｅｂページを介さず、朝市の主催者が開設するＷｅｂページへ直接アクセスさせることもできる。

［販売処理プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１９を用いて、上記の実施例と同様の機能を有する販売処理プログラムを実行するコンピュータの一例について説明する。

図１９は、実施例１及び実施例２に係る販売処理プログラムを実行するコンピュータの一例について説明するための図である。図１９に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図１９に示すように、上記の実施例１で示した販売処理部１７と同様の機能を発揮する販売処理プログラム１７０ａが予め記憶される。この販売処理プログラム１７０ａについては、図２に示した各々の販売処理部１７の各構成要素と同様、適宜統合又は分離しても良い。すなわち、ＨＤＤ１７０に格納される各データは、常に全てのデータがＨＤＤ１７０に格納される必要はなく、処理に必要なデータのみがＨＤＤ１７０に格納されれば良い。

そして、ＣＰＵ１５０が、販売処理プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これによって、図１９に示すように、販売処理プログラム１７０ａは、販売処理プロセス１８０ａとして機能する。この販売処理プロセス１８０ａは、ＨＤＤ１７０から読み出した各種データを適宜ＲＡＭ１８０上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、販売処理プロセス１８０ａは、図２に示した販売処理部１７にて実行される処理、例えば図１６〜図１８に示す処理を含む。また、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。

なお、上記の販売処理プログラム１７０ａについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）コンピュータに、
共通する提供場所で提供される商品について複数の仮購入を受信した場合に、前記商品を分割して得られる分割商品の購入の選択を前記複数の仮購入先に対して許容する処理
を実行させることを特徴とする商品の販売処理プログラム。

（付記２）前記許容する処理として、
提供場所の予約情報を参照して、前記複数の仮購入先の間で前記共通する提供場所が予約された日付が共通する場合に、前記分割商品の購入の選択を前記複数の仮購入先に対して許容することを特徴とする付記１に記載の販売処理プログラム。

（付記３）前記コンピュータに、
前記複数の仮購入先に対して前記分割商品の購入の選択が許容されてから所定の時間が経過するまでに前記仮購入の受信数が前記分割商品の分割数に到達しない場合に、前記仮購入を解除する処理をさらに実行させることを特徴とする付記１または付記２に記載の販売処理プログラム。

（付記４）前記コンピュータに、
前記商品の提供場所が前記複数の仮購入先の間で共通する場合に当該商品の在庫を計数し、前記商品の提供場所が前記複数の仮購入先の間で共通しない場合に当該商品の在庫を計数せずに、商品の在庫数を特定する処理をさらに実行させ、
前記許容する処理として、
前記複数の仮購入を受信した場合に、前記特定された商品の在庫数の表示を含み、前記分割商品の購入の選択を許容する購入用の画面を生成することを特徴とする付記１、２または３に記載の販売処理プログラム。

（付記５）コンピュータが、
共通する提供場所で提供される商品について複数の仮購入を受信した場合に、前記商品を分割して得られる分割商品の購入の選択を前記複数の仮購入先に対して許容する処理
を実行することを特徴とする商品の販売処理方法。

（付記６）共通する提供場所で提供される商品について複数の仮購入を受信した場合に、前記商品を分割して得られる分割商品の購入の選択を前記複数の仮購入先に対して許容する販売処理部
を有することを特徴とする販売処理装置。

１ 販売処理システム
７ ネットワーク
１０ サーバ装置
１１ 通信Ｉ／Ｆ部
１３ 記憶部
１３ａ 会員情報
１３ｂ 朝市情報
１３ｃ 宿泊施設情報
１３ｄ 予約情報
１３ｅ 産物情報
１５ 制御部
１７ 販売処理部
１７ａ 受付部
１７ｂ 特定部
１７ｃ 生成部
１７ｄ 更新部
１７ｅ 通知部
１７ｆ 決済部
３０Ａ，３０Ｂ，３０Ｃ クライアント端末
５０ 主催者端末

Claims (5)

1. コンピュータに、
   共通する提供場所で提供される商品について複数の仮購入を受信した場合に、前記商品を分割して得られる分割商品の購入の選択を前記複数の仮購入先に対して許容する処理
   を実行させることを特徴とする商品の販売処理プログラム。
2. 前記許容する処理として、
   提供場所の予約情報を参照して、前記複数の仮購入先の間で前記共通する提供場所が予約された日付が共通する場合に、前記分割商品の購入の選択を前記複数の仮購入先に対して許容することを特徴とする請求項１に記載の販売処理プログラム。
3. 前記コンピュータに、
   前記複数の仮購入先に対して前記分割商品の購入の選択が許容されてから所定の時間が経過するまでに前記仮購入の受信数が前記分割商品の分割数に到達しない場合に、前記仮購入を解除する処理をさらに実行させることを特徴とする請求項１または請求項２に記載の販売処理プログラム。
4. コンピュータが、
   共通する提供場所で提供される商品について複数の仮購入を受信した場合に、前記商品を分割して得られる分割商品の購入の選択を前記複数の仮購入先に対して許容する処理
   を実行することを特徴とする商品の販売処理方法。
5. 共通する提供場所で提供される商品について複数の仮購入を受信した場合に、前記商品を分割して得られる分割商品の購入の選択を前記複数の仮購入先に対して許容する販売処理部
   を有することを特徴とする販売処理装置。