JP6839743B1

JP6839743B1 - 商品購入システム

Info

Publication number: JP6839743B1
Application number: JP2019178459A
Authority: JP
Inventors: 黒田　訓行; 訓行黒田
Original assignee: Daiwa House Industry Co Ltd
Current assignee: Daiwa House Industry Co Ltd
Priority date: 2019-09-30
Filing date: 2019-09-30
Publication date: 2021-03-10
Anticipated expiration: 2039-09-30
Also published as: JP2021056712A

Abstract

【課題】通信販売を利用する顧客の心理的な抵抗を軽減し、商品の配送を効率化する。【解決手段】商品購入システム１００は、複数の住居１０から商品の購入要求１１９を受け付け可能な購入要求受付部と、購入要求受付部が受け付けた購入要求１１９を蓄積する購入要求保持部と、購入要求保持部に蓄積された購入要求１１９を商品毎に集約し、複数の住居１０のいずれとも異なる配達場所１６を配達先として指定し、集約された購入要求１１９に基づき商品を注文する注文実行部と、注文実行部が注文した商品の数および商品の代金を、各々の住居１０に配分する配分処理部と、を備える。【選択図】図１

Description

本発明は、商品購入システムに関する。

近年、データ通信技術を利用した通信販売が広く普及している。例えば、特許文献１には、広告がテレビ放映された商品について、通信端末を利用した注文を可能とする装置が開示されている。

特開２０１９−１２１１８０号公報

通信販売で商品を購入する顧客は、商品を配達するために自宅住所や氏名等の個人情報を提供する必要があった。このため、通信販売の利用に際し、顧客に心理的な抵抗を感じさせる可能性があった。また、商品を配達する事業者は、個人による小口の注文に応じて、少量の商品を多くの場所に配達しなければならず、物流の効率化が難しいという課題があった。

本発明は上記背景に鑑みなされたものであり、通信販売を利用する顧客の心理的な抵抗を軽減し、商品の配送を効率化することを目的とする。

本発明を適用した一態様は、住居に居住する居住者の居住者端末、及び、商品の通信販売を行う事業者が使用する事業者装置と通信する管理サーバを備え、前記管理サーバは、複数の前記居住者端末から、商品、商品の数量、および、配達場所を指定する情報を含む購入要求を受け付け可能な購入要求受付部と、前記購入要求受付部が受け付けた前記購入要求を蓄積する購入要求保持部と、前記購入要求保持部に蓄積された前記購入要求を前記商品毎、及び、前記配達場所毎に集約して注文情報を生成し、前記注文情報を前記事業者装置に送信することにより前記居住者とは異なる注文者として前記商品を注文する注文実行部と、前記注文実行部が注文した前記商品の数および前記商品の代金を、各々の前記住居に配分する配分処理部と、を備え、前記注文情報は、前記商品の情報と、前記注文実行部により集約された前記商品の購入数を示す情報と、複数の前記住居のいずれとも異なる前記配達場所を配達先として指定する情報と、を含み、前記住居の場所を示す情報を含まない、ことを特徴とする商品購入システムである。

上記商品購入システムにおいて、各々の前記住居は前記配達場所に対応付けられ、前記購入要求受付部は、前記住居に対応付けられた前記配達場所を含む前記購入要求を受け付ける構成であってもよい。

上記商品購入システムにおいて、前記購入要求受付部は、前記住居を特定可能な情報に対応付けられた識別情報を含む前記購入要求を受け付け、前記注文実行部は、前記住居の住所と所在地を含まない前記注文情報を生成する構成であってもよい。

上記商品購入システムにおいて、前記注文実行部は、前記購入要求保持部に蓄積された前記購入要求を集約し、いずれかの商品の購入数が前記商品について設定された条件を満たすか否かを判定し、前記商品の購入数が前記条件を満たす場合に、前記商品の購入数に基づき前記商品を注文する構成であってもよい。

上記商品購入システムにおいて、前記管理サーバは、前記注文実行部により集約された前記購入要求の中に、前記住居への前記商品の輸送の希望を示す情報を含む前記購入要求がある場合、この前記購入要求に対応して配分される数の前記商品の前記配達場所から前記住居への輸送を発注する配送発注部を備える構成であってもよい。

本発明によれば、顧客の個人情報を利用せずに商品の配達が可能となるため、商品を購入する顧客の心理的な抵抗を軽減しできる。商品の注文及び配送を集約化することにより、配送の効率化を図ることができる。

本発明の一実施形態に係る商品購入システムの構成を示す図。注文管理サーバのブロック図。居住者情報の構成例を示す図。購入要求の構成例を示す図。商品購入システムの動作を示すフローチャート。購入要求ＵＩの例を示す図。注文管理サーバの動作を示すフローチャート。

［１．商品購入システムの構成］
以下、図面を参照して本発明の実施形態について説明する。
図１は、本発明の一実施形態に係る商品購入システム１００の構成を示す図である。商品購入システム１００は、注文管理サーバ２０を含む。注文管理サーバ２０は、居住者Ｒが使用する居住者端末１２、および、商品を販売する事業者が使用する事業者サーバ４０と、通信ネットワーク１０２を通じて通信可能に接続されている。

居住者Ｒは、住居１０に居住する人物である。住居１０は、例えば、注文管理サーバ２０を運営する運営事業者が管理する対象の不動産である。運営事業者の管理とは、例えば、建物のメンテナンス等の管理業務をいう。注文管理サーバ２０は、後述するように、居住者Ｒに関する情報を、居住者情報ＤＢ２３２（図２）に記憶している。

住居１０は、一戸建ておよび集合住宅のいずれであってもよく、賃貸住宅であってもよいし、居住者Ｒが所有する不動産であってもよい。注文管理サーバ２０は複数の住居１０を管理対象とすることができ、図１には、注文管理サーバ２０の管理対象として、複数の住居１０ａ、１０ｂを示す。管理対象の住居１０の数、および、注文管理サーバ２０に接続される居住者端末１２の数に制限はなく、図１に示した構成は一例である。住居１０ａ、１０ｂは、例えば、同じ建物の異なる居室であってもよいし、異なる建物であってもよい。居住者端末１２ａは住居１０ａの居住者Ｒが使用する装置であり、居住者端末１２ｂは住居１０ｂの居住者Ｒが使用する装置である。住居１０ａ、１０ｂを区別しない場合は住居１０と表記する。同様に、居住者端末１２ａ、１２ｂを区別しない場合は居住者端末１２と表記する。居住者端末１２は、居住者Ｒの操作によるデータの入力を受け付けて、通信ネットワーク１０２を通じて通信を実行し、各種の画面を表示できればよい。居住者端末１２は、例えば、パーソナルコンピュータ、スマートフォン、携帯型電話機等の電子機器である。

通信ネットワーク１０２は、各種の機器を相互に通信可能に接続する。通信ネットワーク１０２の具体的態様は限定されず、例えば、専用回線、公衆回線、あるいはインターネット等の通信ネットワークを含んで構成される。通信ネットワーク１０２は、基地局を経由する移動体無線通信網を含んでもよい。また、通信ネットワーク１０２は、複数の通信ネットワークを含む広域ネットワークであってもよい。また、通信ネットワーク１０２は、回線交換装置やサーバ等の各種装置を含んでいてもよい。

事業者サーバ４０は、商品の通信販売を行う事業者が使用する装置であり、通信ネットワーク１０２を経由して注文情報１３１を受信した場合に、注文情報１３１に基づき商品の注文を受け付ける。注文情報１３１は、例えば、商品、購入数、配達先、および支払い方法を指定する情報を含む。事業者サーバ４０は、注文情報１３１により指定された商品を、指定された数だけ販売する処理を行い、注文情報１３１により指定された方法で商品の代金を決済する。事業者サーバ４０は、注文情報１３１により指定される商品配送事業者に対して配送を依頼する。注文管理サーバ２０が通信する事業者サーバ４０の数に制限はなく、図１には、一例として、事業者が使用する装置として事業者サーバ４０ａ、４０ｂを示す。事業者サーバ４０ａ、４０ｂを区別しない場合は事業者サーバ４０と表記する。

商品配送事業者は、例えば車両１８により、指定された配達場所１６に商品を配達する事業者であり、事業者サーバ４０を使用または運営する事業者と同一であってもよい。また、商品を配達する手段は車両１８に限らず、鉄道や自動二輪車が利用されてもよく、車両１８は一例である。

商品購入システム１００では、後述するように、事業者サーバ４０が、住居１０とは異なる場所の配達場所１６を指定する注文情報１３１を生成する。配達場所１６は、商品が居住者Ｒの手元に届く前に一時的に保管または貯蔵される場所であり、住居１０とは異なる場所である。従って、事業者サーバ４０が受信する注文情報１３１には、住居１０の住所または所在地は含まれず、配達場所１６の住所や場所を指定する情報が配達先として含まれる。配達場所１６は、コンビニエンスストアや郵便局等の店舗であってもよいし、公共の施設であってもよいし、倉庫であってもよいし、宅配ロッカーやコインロッカー等の設備であってもよい。また、配達場所１６は、住居１０に付属して設置されてもよい。また、配達場所１６が車両で構成され、この車両が、商品を注文した居住者Ｒの住居１０を巡回して、商品の受け取りを可能としてもよい。

商品購入システム１００は、住居１０に居住する居住者Ｒが、商品を購入するサービスを提供する。居住者Ｒは、商品の購入を希望する場合に、居住者端末１２を操作し、購入を希望する商品および数を指定する。これにより、居住者端末１２は、購入要求１１９を注文管理サーバ２０に送信する。注文管理サーバ２０は、居住者端末１２から購入要求１１９を受信し、購入要求１１９をいったん蓄積して、購入する商品毎に数をとりまとめる。注文管理サーバ２０は、蓄積している購入要求１１９について所定の条件が成立した場合に、購入要求１１９を集約して注文情報１３１を生成し、事業者サーバ４０に送信する。注文情報１３１が示す注文は、居住者Ｒが注文した内容を示す購入要求１１９を集約したものであるため、１つの注文情報１３１により注文された商品は、車両１８等によって一括して配達場所１６に配達される。このため、商品の配送を集約化し、効率化を図ることができる。

注文情報１３１は、上述したように、例えば、商品、購入数、配達先、および支払い方法を指定する情報を含むが、住居１０の場所を含む居住者Ｒの個人情報を含まない。注文情報１３１は、事業者サーバ４０に対する商品の注文であり、注文の主体、すなわち注文者は注文管理サーバ２０を使用する事業者である。このため、事業者サーバ４０を使用する事業者には、注文情報１３１が居住者Ｒによる注文に関する情報であることは伝わらず、各々の居住者Ｒが注文した数も伝わらない。また、商品の配達先である配達場所１６は住居１０とは異なる場所であるため、商品の配達のために居住者Ｒの個人情報を提供する必要もない。従って、居住者Ｒは、事業者サーバ４０に個人情報を提供することなく商品を購入できる。

［２．注文管理サーバの構成］
図２は、注文管理サーバ２０の機能的構成を示すブロック図である。
注文管理サーバ２０は、通信部２０１、処理部２１０、および、記憶部２３０を有する。
通信部２０１は、無線通信及び又は有線通信を行う送受信機であり、通信ネットワーク１０２を介して通信を実行する。通信部２０１は、処理部２１０の制御に従って、居住者端末１２との間で通信を実行し、購入要求１１９を受信する。通信部２０１は、処理部２１０の制御に従って、注文情報１３１を生成し、事業者サーバ４０ａまたは事業者サーバ４０ｂに送信する。

処理部２１０は、例えば、ＣＰＵ等のプロセッサを備えるコンピュータである。処理部２１０には、記憶部２３０が接続される。記憶部２３０は、処理部２１０が実行するコンピュータ・プログラム、および、処理部２１０によって処理される各種データを、処理部２１０によって読み取り可能に記憶する。記憶部２３０は、制御用プログラム２３１、居住者情報ＤＢ２３２、購入要求保持部２３３、購入条件２３４、および、注文履歴ＤＢ２３５を格納する。ＤＢはデータベースの略である。

処理部２１０および記憶部２３０を構成するハードウェアは特定の態様に限定されない。例えば、処理部２１０は、単一のプロセッサで構成されてもよい。また、処理部２１０は、プロセッサと、ＲＯＭ、ＲＡＭ等を統合したデバイスであってもよい。記憶部２３０は、プログラムやデータを不揮発的に記憶する不揮発性記憶装置で構成されてもよく、具体的には、ハードディスク等の磁気的記憶装置や、フラッシュＲＯＭ等の半導体記憶デバイスを備えてもよい。また、記憶部２３０は、処理部２１０が実行するプログラムやデータ等を一時的に記憶する揮発性記憶装置を備えてもよい。また、処理部２１０と記憶部２３０とは統合された１つのデバイスであってもよい。

制御用プログラム２３１は、処理部２１０のプロセッサが実行するプログラムである。居住者情報ＤＢ２３２、および、注文履歴ＤＢ２３５は、記憶部２３０の記憶領域を利用して構成されるデータベースである。

居住者情報ＤＢ２３２は、住居１０に居住する居住者Ｒに関する居住者情報２４１を記憶するデータベースである。居住者情報２４１はデータベースのレコードに相当し、例えば、１人の居住者Ｒに対し１つの居住者情報２４１が居住者情報ＤＢ２３２に格納される。

図３は、居住者情報２４１の構成例を示す図である。
居住者情報２４１は、例えば、居住者ＩＤ２４１ａ、氏名２４１ｂ、住居情報２４１ｃ、配達場所２４１ｄ、および、決済情報２４１ｅを含む。居住者ＩＤ２４１ａは、１人の居住者Ｒに割り当てられる固有の識別情報である。氏名２４１ｂは居住者Ｒの氏名である。住居情報２４１ｃは、住居１０を特定可能な情報である。

住居情報２４１ｃは、住所２４１ｆ、および、住居管理情報２４１ｇを含む。住所２４１ｆは住居１０の所在地を指定する情報であり、住居１０が集合住宅である場合は居室を特定する情報を含む。住居管理情報２４１ｇは、注文管理サーバ２０を使用する事業者が住居１０の管理のために住居１０に付与する情報であり、例えば、管理契約に基づき住居１０に付与される固有の識別情報である。

配達場所２４１ｄは、居住者Ｒが注文した商品を配達する配達場所１６を特定する情報である。上述したように、居住者Ｒが購入要求１１９により注文した商品は住居１０に直接配達されず、いったん配達場所１６に配達される。商品購入システム１００では、例えば複数の配達場所１６を利用可能であり、注文管理サーバ２０を使用する事業者または居住者Ｒが、配達場所１６を予め指定する。例えば、居住者Ｒは、自身の住居１０に近い配達場所１６や、通勤経路に近い配達場所１６や、商品の受け取りに便利な配達場所１６を指定する。配達場所２４１ｄにより、居住者Ｒに対応づけて、特定の配達場所１６が配達場所として指定される。

決済情報２４１ｅは、居住者Ｒが注文した商品の代金を居住者Ｒから回収するための手段を特定する情報である。例えば、注文管理サーバ２０を使用する事業者が住居１０の管理業務を受託している場合、決済情報２４１ｅは、商品の代金を住居１０の管理費用と合わせて請求することを示す情報である。商品購入システム１００で利用可能な決済方法は、クレジットカード決済、銀行口座からの引き落とし、請求書を居住者Ｒ宛てに発送する請求方法など、各種の決済手段が挙げられ、これらを指定する情報が決済情報２４１ｅに含まれる。

図３には、１人の居住者Ｒに対し１つの居住者情報２４１が生成され、居住者情報ＤＢ２３２に格納される例を示したが、例えば、１つの住居１０に居住する複数の居住者Ｒに対し、１つの居住者情報２４１が生成され、居住者情報ＤＢ２３２に格納されてもよい。この場合、居住者情報２４１は、１世帯を構成する１人または複数の居住者Ｒに関する情報となり、氏名２４１ｂは世帯を代表する居住者Ｒの氏名とすればよい。

図２に戻り、購入要求保持部２３３は、注文管理サーバ２０が居住者端末１２から受信した購入要求１１９を蓄積し、記憶する。購入要求保持部２３３には、購入要求１１９が、例えば、検索可能な状態で記憶される。

図４は、購入要求１１９の構成例を示す図である。
購入要求１１９は、例えば、居住者ＩＤ１１９ａ、商品名１１９ｂ、商品コード１１９ｃ、購入数１１９ｄ、配達場所１１９ｅ、および、配達フラグ１１９ｆを含む。
居住者ＩＤ１１９ａは、居住者端末１２を操作して商品を注文した居住者Ｒの居住者ＩＤ１１９ａであり、居住者情報２４１に含まれる居住者ＩＤ２４１ａに相当する。
商品名１１９ｂは、居住者Ｒが注文した商品の名前であり、商品コード１１９ｃは、居住者Ｒが注文した商品を特定可能な情報である。購入要求１１９は、商品名１１９ｂおよび商品コード１１９ｃのうちいずれか一方のみを含む構成であってもよい。

購入数１１９ｄは、居住者Ｒが注文した商品の数を示す情報である。購入数１１９ｄは、商品の販売単位の数であり、個数に限定されない。例えば、商品が、１リットルを単位として販売される液体や、長さを単位として販売されるシート形状の商品である場合には、購入数１１９ｄは商品の数量を示す。配達場所１１９ｅは、居住者Ｒが注文した商品の配達場所１６を指定する情報である。

配達フラグ１１９ｆは、居住者Ｒが、配達場所１６から住居１０までの商品の配達を希望するか否かを示すフラグである。配達場所１６は、住居１０とは異なる場所であるから、商品が配達場所１６に配達された後、配達場所１６から住居１０へ商品を移動する必要がある。商品を移動する手法としては、居住者Ｒが配達場所１６に出向いて商品を受け取る態様が挙げられるが、配達場所１６から住居１０へ、宅配事業者等により商品を配達してもよい。この宅配事業者は注文管理サーバ２０を使用する事業者と同一であってもよい。配達フラグ１１９ｆは、購入要求１１９により注文された商品を、配達場所１６から住居１０まで、事業者により配達することを居住者Ｒが希望するか否かを示す。

購入要求１１９は、複数の商品の注文に関する情報を含んでもよい。例えば、１つの購入要求１１９が、商品名１１９ｂ、商品コード１１９ｃとして複数の商品の商品名や商品コードを含んでもよい。この場合、購入数１１９ｄは、１組の商品名１１９ｂ及び商品コード１１９ｃに対応する１つの購入数の値を含む。好ましくは、商品名１１９ｂまたは商品コード１１９ｃ毎に１つの購入要求１１９が生成される。

購入要求保持部２３３に記憶された購入要求１１９は、各種の情報をキーとして集約が可能である。具体的には、商品名１１９ｂの値、及び／または商品コード１１９ｃの値が共通する購入要求１１９を購入要求保持部２３３から抽出することができる。また、配達場所１１９ｅが特定の値である購入要求１１９を購入要求保持部２３３から抽出できる。従って、１つの配達場所１６に一括して配達可能な同一の商品を注文する購入要求１１９を集約し、まとめて１つの注文として処理することが可能となる。

処理部２１０は、機能要素又は機能ユニットとして、居住者認識部２１１、購入要求受付部２１２、注文実行部２１３、配分処理部２１４、配送発注部２１５、および、決済処理部２１６を備える。処理部２１０が備えるこれらの機能要素は、コンピュータである処理部２１０が制御用プログラム２３１を実行することにより実現される。なお、制御用プログラム２３１は、コンピュータ読み取り可能な任意の記憶媒体に記憶させておくことができる。これに代えて、処理部２１０が備える上記機能要素の全部又は一部を、それぞれ一つ以上の電子回路部品を含むハードウェアにより構成することもできる。

処理部２１０は、通信部２０１により、居住者端末１２との間、および、事業者サーバ４０との間で情報を送受信する。
居住者認識部２１１は、居住者端末１２から受信する情報に基づき、居住者端末１２を操作する居住者Ｒを認識する。例えば、居住者Ｒが居住者端末１２を操作して注文管理サーバ２０にアクセスした場合、居住者認識部２１１は、アクセスした居住者Ｒを特定する。
購入要求受付部２１２は、居住者端末１２から購入要求１１９を受信した場合に、購入要求保持部２３３に記憶させる。

注文実行部２１３は、購入要求保持部２３３に記憶された購入要求１１９を集約して、注文情報１３１を生成し、事業者サーバ４０に送信する。例えば、注文実行部２１３は、購入要求保持部２３３に記憶された購入要求１１９を、商品名１１９ｂ及び／または商品コード１１９ｃをキーとして集約することにより、同一の商品に関する購入要求１１９を抽出する。さらに、注文実行部２１３は、抽出した購入要求１１９のうち、配達場所１１９ｅが共通する購入要求１１９を抽出し、このようにして抽出された購入要求１１９を集約して注文情報１３１を生成する。生成される注文情報１３１は、抽出された購入要求１１９の商品名１１９ｂまたは商品コード１１９ｃと、抽出された購入要求１１９の購入数１１９ｄを合計した数とを含み、配達先として配達場所１１９ｅを含む。また、注文情報１３１の注文を実行する主体、すなわち注文者は、注文管理サーバ２０を使用する事業者である。注文実行部２１３は、生成した注文情報１３１を、該当する商品を販売する事業者サーバ４０ａまたは事業者サーバ４０ｂに送信し、商品の注文を実行する。このため、事業者サーバ４０に伝達される注文者は居住者Ｒとは異なっており、居住者Ｒの個人情報は事業者サーバ４０には伝達されない。

ここで、事業者サーバ４０は、注文情報１３１を受信すると、１つの注文情報１３１を１回の注文として処理し、注文情報１３１により指定された数の商品を、配達場所１６に発送する。また、注文情報１３１に係る商品の代金を、注文者である事業者に請求する。請求を受けた事業者は商品の代金を決済する。代金の請求および決済を、事業者サーバ４０と、注文管理サーバ２０と、クレジットカード会社や銀行等の金融事業者が運営するサーバ装置との間のデータ処理により、実行してもよい。

注文実行部２１３は、購入要求保持部２３３に記憶された購入要求１１９から注文情報１３１を生成する処理を、所定のトリガーに基づき実行する。例えば、注文実行部２１３は、購入要求保持部２３３に記憶された購入要求１１９のうち、商品名１１９ｂまたは商品コード１１９ｃ、および、配達場所１１９ｅが共通する購入要求１１９を抽出する。注文実行部２１３は、抽出した購入要求１１９に含まれる購入数１１９ｄの合計が、所定の数に達した場合に、注文情報１３１を生成する。或いは、注文実行部２１３は、抽出した購入要求１１９に含まれる購入数１１９ｄの合計が、所定の数の倍数である場合に、注文情報１３１を生成してもよい。或いは、注文実行部２１３は、抽出した購入要求１１９のうち最も古い購入要求１１９が購入要求保持部２３３に記憶された日時から起算して、予め設定された所定期間が経過した後、抽出した購入要求１１９に基づき注文情報１３１を生成してもよい。

配分処理部２１４は、注文実行部２１３が生成した注文情報１３１に対応する商品の数および商品代金を、居住者Ｒごとに配分する。配分処理部２１４は、注文情報１３１で注文された商品の合計代金を、購入数１１９ｄの数に基づいて按分することにより、各々の居住者Ｒに請求する商品代金を算出する。また、注文情報１３１により注文された商品の数を、各々の居住者Ｒに按分して割り当てる。

配送発注部２１５は、注文情報１３１に集約された購入要求１１９の配達フラグ１１９ｆを参照し、配達場所１６から住居１０への配達を希望する居住者Ｒに対し、配分処理部２１４が割り当てた数の商品を配達するための処理を行う。すなわち、配送発注部２１５は、配達を希望する居住者Ｒを特定し、特定した居住者Ｒに割り当てられた数の商品を、特定した居住者Ｒの住居１０に配達するように、宅配事業者に対し要求する。特定した居住者Ｒに対しては、配分処理部２１４が割り当てた商品代金に加え、配達場所１６から住居１０への配達の費用が加算して割り当てられる。

決済処理部２１６は、配分処理部２１４により居住者Ｒに割り当てられた商品代金を、決済情報２４１ｅに基づいて請求または決済する。決済処理部２１６は、クレジットカード会社や銀行等の金融事業者が運営するサーバ装置との間でデータ処理を実行し、決済を行ってもよい。

［３．商品購入システムの動作］
図５は、商品購入システムの動作を示すフローチャートであり、購入要求１１９が生成され蓄積される過程の動作を示す。
図５において、符号Ａは居住者端末１２の動作を示し、符号Ｂは注文管理サーバ２０の動作を示し、符号Ｃは事業者サーバ４０の動作を示す。注文管理サーバ２０は処理部２１０によって図５の動作を実行する。ステップＳ１１１は居住者認識部２１１の動作に相当し、ステップＳ１１２−Ｓ１１８は購入要求受付部２１２の動作に相当する。

居住者Ｒは、居住者端末１２を操作し、居住者Ｒを特定するための情報を入力する（ステップＳ１０１）。ステップＳ１０１で入力された情報は居住者端末１２から注文管理サーバ２０に送信され、注文管理サーバ２０は、居住者端末１２を操作して注文を行う居住者Ｒを特定する（ステップＳ１１１）。ステップＳ１１１で、居住者端末１２から情報を受信して居住者情報ＤＢ２３２と照合し、特定した居住者Ｒに対応する居住者情報２４１を取得する。

居住者Ｒは、注文する商品を選び、注文を確定させるため、商品選択の要求を入力し、これに応じて居住者端末１２が注文管理サーバ２０に対し、商品選択要求を送信する（ステップＳ１０２）。ステップＳ１０２で送信される商品選択要求は、例えば、商品のカテゴリー、商品名、商品を販売している事業者サーバ４０等を指定する情報を含む。注文管理サーバ２０は、商品選択要求を受信し（ステップＳ１１２）、事業者サーバ４０に対して商品選択ＵＩ（ユーザインターフェイス）を要求する（ステップＳ１１３）。ステップＳ１１３で、注文管理サーバ２０は、例えば、商品選択要求で指定された商品を注文可能な事業者サーバ４０を選択し、商品の価格等の情報を含むデータをステップＳ１１４で要求する。事業者サーバ４０は、注文管理サーバ２０が送信する商品選択ＵＩの要求を受信し（ステップＳ１２１）、要求された商品選択ＵＩのデータを注文管理サーバ２０に送信する（ステップＳ１２２）。

商品選択ＵＩは、例えば、事業者サーバ４０がインターネットで通信販売サイトを公開している場合、この通信販売サイトで商品購入を受け付けるインターフェイスであり、インターネットブラウザで表示される商品購入用の画面等である。
ステップＳ１１３で、例えば、注文管理サーバ２０は、通信販売サイトを利用する顧客として商品購入用の画面のデータを要求する。注文管理サーバ２０は、ステップＳ１２２で、商品購入用の画面のデータを送信する。

注文管理サーバ２０は、事業者サーバ４０が送信した商品選択ＵＩのデータをもとに、居住者端末１２が購入要求を行うための購入要求ＵＩを生成し（ステップＳ１１５）、注文管理サーバ２０に送信する（ステップＳ１１６）。

居住者端末１２は、注文管理サーバ２０から送信される購入要求ＵＩを受信して、ディスプレイに表示する（ステップＳ１０３）。

図６は、購入要求ＵＩの例を示す図である。
図６には、居住者端末１２が搭載するインターネットブラウザの機能により表示される購入要求ＵＩ３００を例示する。購入要求ＵＩ３００は、商品選択画面３１０を有する。商品選択画面３１０には、商品を販売する事業者を示す事業者名表示部３１１が配置される。購入要求ＵＩ３００は、事業者サーバ４０が送信する商品選択ＵＩに基づき生成されており、例えば、事業者サーバ４０がステップＳ１２２で送信する商品選択ＵＩをほぼそのまま利用する。事業者名表示部３１１には、商品選択ＵＩを送信した事業者サーバ４０に係る事業者の名称が表示される。

購入要求ＵＩ３００は、商品名や商品コードが表示される商品名表示部３１２、および、商品の画像が表示される商品画像表示部３１３が配置される。また、商品の販売価格が表示される価格表示部３１４が配置される。図６の例では、価格表示部３１４に、商品を１個購入する場合の価格と、指定された数の商品をまとめて購入する場合の価格とが表示されている。購入要求ＵＩ３００には、居住者Ｒが居住者端末１２によって商品の購入数を入力するための数入力部３１５、および、注文を確定するボタン３１６が配置されている。

このように、実際に商品を販売する事業者サーバ４０が提供する商品選択ＵＩをもとに、購入用の画面である購入要求ＵＩ３００を居住者端末１２が表示することにより、居住者Ｒは、商品の画像等を参照しながら注文を行うことができる。注文管理サーバ２０は、商品に関する詳細な情報を自ら保持していなくても、居住者Ｒが望む商品について情報を居住者Ｒに提示することができ、購入要求を受け付けることができる。

図６の価格表示部３１４には、単価である１ケースの価格に加え、６ケースをまとめて購入する場合の価格が表示される。この価格は、まとめ買いによりディスカウントされた価格であり、単価を６ケース分乗じた価格よりも安価である。商品価格が安価であることは居住者Ｒにとって好ましいことであるが、まとめ買いの単位は、１人の居住者Ｒが消費できる量を超えることがある。商品購入システム１００では、複数の住居１０の居住者Ｒが行った注文を、注文管理サーバ２０が１つの注文情報１３１にとりまとめるので、まとめ買いによるディスカウントが適用される可能性が高まるという利点がある。

図５に戻り、居住者端末１２では、購入要求ＵＩに基づき居住者Ｒが商品の購入数等を入力する（ステップＳ１０４）。居住者端末１２は、居住者Ｒが入力した情報と、購入要求ＵＩに含まれる情報とに基づき、購入要求１１９を生成して、注文管理サーバ２０に送信する（ステップＳ１０５）。

注文管理サーバ２０は、購入要求１１９を受信し（ステップＳ１１７）、購入要求保持部２３３に購入要求１１９を蓄積する（ステップＳ１１８）。

図７は、注文管理サーバ２０の動作を示すフローチャートである。
注文管理サーバ２０は処理部２１０によって図７に示す動作を実行する。ステップＳ１４１−Ｓ１４５は注文実行部２１３の動作に相当し、ステップＳ１４６は配分処理部２１４の動作に相当し、ステップＳ１４７−Ｓ１４８は配送発注部２１５の動作に相当する。ステップＳ１４９の動作は決済処理部２１６の動作に相当する。

注文管理サーバ２０は、購入要求保持部２３３に蓄積された購入要求１１９を、商品名１１９ｂおよび商品コード１１９ｃに基づき検索して、注文された商品毎の購入要求１１９を抽出し、購入数１１９ｄの値を集約する（ステップＳ１４１）。注文管理サーバ２０は、集約した購入数１１９ｄの合計値が、予め設定された購入数に達したか否かを判定する（ステップＳ１４２）。購入数は、商品毎、および、商品を販売する事業者サーバ４０毎に設定され、例えば、商品選択ＵＩのデータに含まれる。図６の例では、価格表示部３１４に、１ケースの価格、すなわち単価とは別に、６ケースまとめて購入する場合の価格が表示される。図６の例では、注文管理サーバ２０は、商品選択ＵＩから購入要求ＵＩを生成する際に、商品の購入数の設定値として、単価とは別の値である「６ケース」の値を取得し、商品名に対応する予め設定された購入数とする。

購入数１１９ｄの合計値が、予め設定された購入数に達していないと判定した場合（ステップＳ１４２；ＮＯ）、注文管理サーバ２０は、集約した商品の購入要求１１９を受け付ける受付期間が終了したか否かを判定する（ステップＳ１４３）。受付期間は、商品毎に設定された期間、または、ステップＳ１４１で抽出された購入要求１１９のうち最も古い購入要求１１９が購入要求保持部２３３に格納されてからの経過時間の基準である。例えば、注文管理サーバ２０は、ステップＳ１４３で、購入要求１１９を受け付ける期間として設定された日時と、現在の日時とを比較する。

受付期間が終了していないと判定した場合（ステップＳ１４３；ＮＯ）、注文管理サーバ２０は、所定の待機期間が経過してからステップＳ１４１に戻る。
購入数１１９ｄの合計値が購入数に達したと判定した場合（ステップＳ１４２；ＹＥＳ）、および、受付期間が終了したと判定した場合（ステップＳ１４３；ＹＥＳ）、注文管理サーバ２０は、注文情報１３１を生成する（ステップＳ１４４）。

注文管理サーバ２０は、生成した注文情報１３１を事業者サーバ４０に送信して注文を実行する（ステップＳ１４５）。注文管理サーバ２０は、ステップＳ１４１で集約した購入要求１１９と注文情報１３１とに基づき、各々の居住者Ｒについて、商品の購入数おおび代金を配分する（ステップＳ１４６）。ステップＳ１４６では、注文情報１３１に対応する商品価格を、商品の購入数によって按分する。例えば、図６に示した例のように、購入要求１１９を集約したことにより購入数が多くなるため、商品価格が単価より割安となることがある。この場合、居住者Ｒには、単価を購入数だけ乗じた金額より低い代金が配分されるので、居住者Ｒは、割安で商品を購入できる。

注文管理サーバ２０は、ステップＳ１４１で集約した購入要求１１９の配達フラグ１１９ｆを参照し、配達場所１６から住居１０までの商品の配達を希望する居住者Ｒがいるか否かを判定する（ステップＳ１４７）。該当する居住者Ｒがいる場合（ステップＳ１４７；ＹＥＳ）、注文管理サーバ２０は、該当する居住者Ｒに配分された数の商品を配達場所１６から住居１０へ配達するための発注を行い（ステップＳ１４８）、ステップＳ１４９に移行する。配達場所１６から住居１０までの商品の配達を希望する居住者Ｒがいない場合（ステップＳ１４７；ＮＯ）、注文管理サーバ２０はステップＳ１４９に移行する。

ステップＳ１４９で、注文管理サーバ２０は、ステップＳ１４６で配分した金額を居住者Ｒに請求する決済処理を実行する。

［４．まとめ］
以上説明したように、本発明を適用した実施形態の商品購入システム１００を構成する注文管理サーバ２０は、複数の住居１０から商品の購入要求１１９を受け付け可能な購入要求受付部２１２と、購入要求受付部２１２が受け付けた購入要求１１９を蓄積する購入要求保持部２３３と、購入要求保持部２３３に蓄積された購入要求１１９を商品毎に集約し、複数の住居１０のいずれとも異なる配達場所１６を配達先として指定し、集約された購入要求１１９に基づき商品を注文する注文実行部２１３と、注文実行部２１３が注文した商品の数および商品の代金を、各々の住居１０に配分する配分処理部２１４と、を備える。

本発明によれば、商品を販売する事業者に対し、商品の購入要求を集約して注文を行い、商品の配達先として住居１０とは異なる配達場所１６を利用するので、商品の注文および配達を集約化できる。このため、商品の配送を効率化できる。また、商品を販売する事業者に対して、配達先として居住者Ｒの個人情報を提供する必要がないため、個人情報の開示に関する居住者Ｒの心理的な抵抗を軽減できる。

また、配達場所１６は配達場所として機能することが必要とされる場所であることから、個人の住居１０に商品を配達する場合のように不在による未達や再配達の負担が発生せず、商品の配送を大幅に効率化できる。

また、複数の居住者Ｒの注文を集約した場合、居住者Ｒが必要とする量の商品だけを個人的に注文する場合に比べ、注文する量が多くなる。このため、商品の販売条件によっては、まとめ買いによって購入価格を安価にすることが可能となる。

注文管理サーバ２０において、各々の住居１０は配達場所１６に対応付けられ、注文実行部２１３は、購入要求保持部２３３に蓄積された購入要求１１９のうち、１つの配達場所１６に対応する複数の住居１０から受け付けた購入要求１１９を集約する。このため、購入要求１１９をまとめた注文情報１３１を利用して商品の注文を行うことにより、商品の配達を確実に集約化できる。

購入要求保持部２３３は、住居１０の居住者Ｒの個人情報を含む購入要求１１９を蓄積し、注文実行部２１３は、住居１０の居住者Ｒの個人情報とは異なる注文者の情報を用いて、商品の注文を実行する。このため、商品を販売する事業者に対して、注文者として居住者Ｒの個人情報を提供する必要がないため、個人情報の開示に関する居住者Ｒの心理的な抵抗を、より一層軽減できる。

注文実行部２１３は、購入要求保持部２３３に蓄積された購入要求１１９を集約し、いずれかの商品の購入数が商品について設定された条件を満たすか否かを判定し、商品の購入数が条件を満たす場合に、商品の購入数に基づき商品を注文する。例えば、商品の数に関する条件を設定することにより、例えば、商品を販売する事業者が注文の処理および配達を効率化しやすい数で商品を注文したり、まとめ買いにより商品価格を抑制したりすることが可能となる。従って、商品の販売および配達に関して、より一層の効率化を図ることができる。

注文管理サーバ２０は、配分処理部２１４により配分された商品の数に基づき、配達場所１６から住居１０への商品の輸送を発注する配送発注部２１５を備える。このため、居住者Ｒの希望に応じて、商品を住居１０に配達することが可能となる。

［５．他の実施態様］
本発明は上記実施形態の構成に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能である。

例えば、本実施形態では、注文管理サーバ２０が居住者端末１２および事業者サーバ４０との間でデータ通信を実行する構成を例に挙げて説明したが、本発明はこれに限定されない。例えば、購入要求受付部２１２、購入要求保持部２３３、注文実行部２１３、配分処理部２１４、および配送発注部２１５を、複数の装置に分散して配置してもよい。また、物理的構成が制限されないクラウド型サーバによって注文管理サーバ２０を実現してもよい。

また、注文情報１３１に、商品を小分け包装する数量を指定する情報を含んでもよい。この態様は、例えば、注文実行部２１３が、複数の購入要求１１９を集約する際に、購入数１１９ｄの値を小分け単位として注文情報１３１に含ませれば実現可能である。この場合、事業者サーバ４０を使用する事業者は、注文情報１３１により注文された商品を、注文情報１３１により指定された量に小分けして梱包し、一括して配達場所１６に配達する。この場合も、配達を集約することによる物流の効率化を図ることができる。また、配達場所１６に到着した後に、商品を居住者Ｒに分配する作業の手間を省くことができる。

図２に示した各機能ブロックのうち少なくとも一部は、ハードウェアで実現してもよいし、ハードウェアとソフトウェアの協働により実現される構成としてもよく、図に示した通りに独立したハードウェア資源を配置する構成に限定されない。

また、図５及び図７の各々に示すフローチャートの処理単位は、商品購入システム１００の動作を理解容易にするために、主な処理内容に応じて分割したものであり、各フローチャートに示す処理単位の分割の仕方や名称によって実施形態が制限されることはない。また、商品購入システム１００における各処理は、処理内容に応じて、さらに多くの処理単位に分割することもできるし、１つの処理単位がさらに多くの処理を含むように分割することもできる。また、上記のフローチャートの処理順序も、図示した例に限られるものではない。

１０、１０ａ、１０ｂ住居
１２、１２ａ、１２ｂ居住者端末
１６配達場所
２０注文管理サーバ
４０、４０ａ、４０ｂ事業者サーバ
１００商品購入システム
１０２通信ネットワーク
１１９購入要求
１３１注文情報
２０１通信部
２１０処理部
２１１居住者認識部
２１２購入要求受付部
２１３注文実行部
２１４配分処理部
２１５配送発注部
２１６決済処理部
２３０記憶部
２３１制御用プログラム
２３２居住者情報ＤＢ
２３３購入要求保持部
２３４購入条件
２３５注文履歴ＤＢ
２４１居住者情報

Claims

住居に居住する居住者の居住者端末、及び、商品の通信販売を行う事業者が使用する事業者装置と通信する管理サーバを備え、
前記管理サーバは、
複数の前記居住者端末から、商品、商品の数量、および、配達場所を指定する情報を含む購入要求を受け付け可能な購入要求受付部と、
前記購入要求受付部が受け付けた前記購入要求を蓄積する購入要求保持部と、
前記購入要求保持部に蓄積された前記購入要求を前記商品毎、及び、前記配達場所毎に集約して注文情報を生成し、前記注文情報を前記事業者装置に送信することにより前記居住者とは異なる注文者として前記商品を注文する注文実行部と、
前記注文実行部が注文した前記商品の数および前記商品の代金を、各々の前記住居に配分する配分処理部と、を備え、
前記注文情報は、前記商品の情報と、前記注文実行部により集約された前記商品の購入数を示す情報と、複数の前記住居のいずれとも異なる前記配達場所を配達先として指定する情報と、を含み、前記住居の場所を示す情報を含まない、
ことを特徴とする商品購入システム。
各々の前記住居は前記配達場所に対応付けられ、
前記購入要求受付部は、前記住居に対応付けられた前記配達場所を含む前記購入要求を受け付けること、を特徴とする請求項１記載の商品購入システム。
前記購入要求受付部は、前記住居を特定可能な情報に対応付けられた識別情報を含む前記購入要求を受け付け、
前記注文実行部は、前記住居の住所と所在地を含まない前記注文情報を生成すること、を特徴とする請求項１または２記載の商品購入システム。
前記注文実行部は、前記購入要求保持部に蓄積された前記購入要求を集約し、いずれかの商品の購入数が前記商品について設定された条件を満たすか否かを判定し、前記商品の購入数が前記条件を満たす場合に、前記商品の購入数に基づき前記商品を注文すること、を特徴とする請求項１から３のいずれか１項に記載の商品購入システム。
前記管理サーバは、前記注文実行部により集約された前記購入要求の中に、前記住居への前記商品の輸送の希望を示す情報を含む前記購入要求がある場合、この前記購入要求に対応して配分される数の前記商品の前記配達場所から前記住居への輸送を発注する配送発注部を備えること、を特徴とする請求項１から４のいずれか１項に記載の商品購入システム。