JP6855578B2 - 商品発注システム - Google Patents

Description

本発明は、商品の購入・販売の技術に関し、特に、実店舗における商品やサービスの購入・販売を仲介する商品発注システムに適用して有効な技術に関するものである。

近年ではＥＣ（Electronic Commerce）サイトを利用したオンラインショッピングが広く普及している。一方で、例えば、薬局での処方薬の購入や、レストランでの食事等、顧客が購入を希望する商品・物品やサービス（以下では「商品等」と総称する場合がある）について注文し、注文に対応する商品等の提供を実店舗において実際に受ける、という購入形態も多い。

顧客による注文は、店員等に対して直接口頭で行われる場合が多いが、顧客の利便性や店舗側の省力化等を実現する仕組みとして、例えば、券売機により購入したチケット等を店員に受け渡しての注文や、タブレット端末を用いたセルフオーダーシステムを用いた注文も行われている。また、注文を行った顧客による待ち時間を短縮する仕組みとして、例えば、ドライブスルーの仕組みが利用されている。ここでは、単に顧客が車から降りることなく商品を購入できるだけではなく、顧客が先に注文を行い、その後、受取場所まで移動する間に、注文に係る商品を店舗側が準備しておくことで、顧客の待ち時間を短縮している。

これに関連する技術として、例えば、特開２０１３−１７１３９７号公報（特許文献１）には、ドライブスルーの混雑時にユーザが車両の中から商品のオーダーを行えるようにすることで、ユーザが商品をオーダーする時間と、ユーザがオーダーした商品を店舗側で準備するための時間を短縮する旨が記載されている。また、ドライブスルーの待ち時間を利用してオーダーした商品の精算金額を電子マネーにより決済できるようにすることで、決済にかかる時間を短縮する旨が記載されている。

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

従来技術のような仕組みを利用することで、注文に係る顧客の待ち時間や、注文を受けた店舗側の準備時間をある程度短縮することができる。しかし、注文を行うにはドライブスルーのような設備が併設された対象の店舗まで実際に行く必要がある。したがって、例えば、「近くに行くことがあったら寄ってみたい」というような「緩い」購入意図（すなわち、「予約」に適さない購入意図）を有する顧客にとっては、実際に近くに来たにも関わらず忘れていたために当該店舗に寄ることができず、商品等を購入するためには再度訪問する必要がある等、時間と労力が無駄になる場合が生じ得る。また、多数の顧客が同時期に集中して来店すると、注文を行うまでの待ち時間が長くなり、時間の無駄につながり得る。

また、店舗側にとっても、ドライブスルーやセルフオーダーシステムのような設備を設置する必要があり、設備投資の負担が大きくなる。また、多数の顧客が同時期に来店した場合の注文集中による対応負担の増大やクレームの増加等の影響を、予測したり標準化したりすることも困難である。また、商品や原材料の適正在庫の見積もり精度が低下し、余剰に伴うロスや不足に伴う機会損失のリスクが高くなってしまう。

そこで本発明の目的は、顧客が実際に店舗に来店する前に、「緩い」購入意図に基づいて適切なタイミングで注文を行う仕組みを店舗側の負担が小さい形で実現する商品発注システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による商品発注システムは、顧客の商品等の購入希望に基づいて、前記商品等を販売する店舗に対して注文を行う商品発注システムであって、前記顧客により入力された前記購入希望に係る前記商品等と購入条件からなるウィッシュリストの情報を保持し、前記購入条件が所定の程度以上充足したか否かを判定するウィッシュリスト管理部を有する。

さらに、前記ウィッシュリスト管理部において前記購入条件が所定の程度以上充足したと判定された場合に、前記購入条件に係る前記ウィッシュリストに基づいて仮注文の情報を作成して保持し、前記顧客が保持する顧客端末から取得した前記顧客の行動予定情報および／または前記顧客の位置情報に基づいて前記仮注文の確度を算出し、前記確度が所定の閾値を超えたか否かを判定する仮注文管理部と、前記仮注文管理部において前記確度が所定の閾値を超えたと判定された場合に、前記仮注文の情報に基づいて注文の情報を作成して保持し、前記注文に係る前記商品等を販売する前記店舗に対して前記注文の情報を送信する注文管理部と、を有する。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、顧客が実際に店舗に来店する前に、「緩い」購入意図に基づいて適切なタイミングで注文を行う仕組みを店舗側の負担が小さい形で実現することが可能となる。

本発明の一実施の形態である商品発注システムの構成例について概要を示した図である。 本発明の一実施の形態における商品の購入・販売の処理の流れの例について概要を示したフロー図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。

本発明の一実施の形態である商品発注システムは、顧客が有する商品等の「緩い」購入意図（以下では「ウィッシュリスト」と記載する場合がある）と、当該顧客の行動予定や位置情報とを連携させて解析し、当該顧客が店舗に来店する前に、対象の商品等に係る仮注文情報を自動的に生成する。そして、当該顧客の行動内容や位置情報等を常時トラッキングし、その内容に基づいて仮注文情報の確度を算出・推測するとともに、確度が一定の値を超えた場合に、確定した注文情報として対象の店舗に対して登録し、来店前に決済まで行っておく。これにより、店舗における顧客の待ち時間をゼロに近づけるとともに、店舗での顧客による決済処理も不要とすることができる。

＜システム構成＞
図１は、本発明の一実施の形態である商品発注システムの構成例について概要を示した図である。本実施の形態の商品発注システム１は、例えば、顧客３（顧客端末３０）および店舗４（店舗システム４０）に対して、インターネット等のネットワーク２を介して商品等の売買の仲介サービスを提供するサーバシステムであり、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ等により構成される。そして、図示しないＣＰＵ（Central Processing Unit）により、ＨＤＤ（Hard Disk Drive）等の記録装置からメモリ上に展開したＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラム等のミドルウェアや、その上で稼働するソフトウェアを実行することで、上記サービスの提供に係る後述する各種機能を実現する。

なお、顧客端末３０は、例えば、顧客３が常時携行するタブレット端末やスマートフォン等の汎用の情報処理端末であり、図示しないＣＰＵにより、メモリ上に展開したＯＳ等のミドルウェアや、その上で稼働するアプリケーションプログラムを実行することで、顧客３に対して商品購入に係るユーザインタフェースを含む各種サービスを提供する。また、店舗システム４０は、例えば、各店舗４に設置されたＰＣ（Personal Computer）やサーバ機器等からなる情報処理システムであり、図示しないＣＰＵにより、ＨＤＤ等の記録装置からメモリ上に展開したＯＳ等のミドルウェアや、その上で稼働するソフトウェアを実行することで、利用者からの注文情報を受け付けて処理もしくは店員への指示等を行う。

商品発注システム１は、例えば、ソフトウェアとして実装されたウィッシュリスト管理部１１、仮注文管理部１２、注文管理部１３、決済処理部１４、店舗管理部１５、および顧客管理部１６等の各部を有する。また、データベース等により実装されたウィッシュリストデータベース（ＤＢ）１１０、仮注文ＤＢ１２０、注文ＤＢ１３０、購入履歴ＤＢ１４０、店舗情報ＤＢ１５０、および顧客情報ＤＢ１６０等の各データを有する。

ウィッシュリスト管理部１１は、各顧客３の購入希望商品等からなるウィッシュリストの情報をウィッシュリストＤＢ１１０に記録して管理する機能を有する。例えば、顧客端末３０に導入された商品購入アプリケーション３１を介して顧客３から入力された、購入意図を有する商品等の情報を、購入条件と関連付けてウィッシュリストとしてウィッシュリストＤＢ１１０に登録する。なお、本実施の形態では、ウィッシュリストを商品発注システム１上のウィッシュリストＤＢ１１０に保持するものとしているが、各顧客３の顧客端末３０上の商品購入アプリケーション３１において個別に保持し、後述する仮注文となるまで商品発注システム１上には保持しない構成としてもよい。

顧客３の「購入意図」には、「○月○日○○時に△△店で□□□を買う」というように希望する購入条件（購入日時や店舗）が確定しているもの（すなわち、「予約」し得るもの）を含んでいてもよいが、本実施の形態では、購入条件が確定しておらず、購入条件が充足すれば購入するというもの（「予約」に適さないもの）を含むものとする。

このような購入条件には、例えば、上述したように、「△△店の近くに行くことがあったら寄ってみたい」というように漠然としたもの（確度の低いもの）や、「○月○日から１週間の間に△△店で□□□を受け取る」というようにある程度はっきりしたもの（確度の高いもの）等、様々な確度のものが含まれ得る。なお、上記の例では、購入条件として日付もしくは日時、および場所（店舗４およびこれに対する位置）を含むものとしているが、その他にも、例えば、そのときの天候や所持金（口座残高）等、店舗４への来店や商品の購入に影響を及ぼし得る各種条件を含んでいてもよい。

また、ウィッシュリスト管理部１１は、ウィッシュリストに登録された購入希望商品に係る購入条件について、条件充足に一定程度以上近付いたと判定した場合に、対応する仮注文を作成して、後述する仮注文管理部１２を介して仮注文ＤＢ１２０に登録する。例えば、購入希望日時が近付いた場合（例えば、３日前等）や、購入希望店舗から一定の距離範囲（例えば、５ｋｍ圏内）に近付いた場合、購入希望店舗の付近に移動することになる行動予定（スケジュール）の日時が近付いた場合等において、条件充足に一定程度以上近付いたと判定する。なお、ウィッシュリストを顧客端末３０上の商品購入アプリケーション３１において管理する構成の場合は、これらの判定を商品購入アプリケーション３１において行ってもよい。

仮注文管理部１２は、ウィッシュリスト管理部１１（もしくは商品購入アプリケーション３１）により作成された仮注文の情報を仮注文ＤＢ１２０に記録して管理する機能を有する。また、各仮注文について、対象の顧客３の顧客端末３０から送信された行動予定情報３２や、ＧＰＳセンサ３３により検知された位置情報に基づいて、仮注文の確度を算出し、確度が所定の閾値を超えた場合に、購入条件が充足したと判断して、対応する注文を作成して、後述する注文管理部１３を介して注文ＤＢ１３０に登録する。このとき、注文が登録される旨を顧客端末３０に対して通知し、顧客３による承諾・拒否の入力を受け付けるようにしてもよい。

仮注文の確度は、例えば、購入条件における日時（購入希望日時や行動予定の日時）が近付くほど高くなり、また、顧客３の位置情報が対象の店舗４に近付くほど高くなる。本実施の形態では、顧客端末３０から取得したこれらの情報を常時トラッキングし、値の変化や遷移を所定の基準や条件に基づいてスコアリングして、購入条件の確度とする。スコアリングの際の基準や条件は特に限定されず、例えば、パラメータ毎に予め定めた数式やテーブル等を適宜用いることができる。具体的には、例えば、日時が、購入希望日時の１日前→当日→１時間前→購入希望日時等の条件に達する毎に所定のスコアを加算し、同様に、位置情報が、対象の店舗４の近隣５ｋｍ圏内→近隣５００ｍ圏内→来店等の条件に達する毎に所定のスコアを加算する等の方法をとることができる。

なお、上記では、確度が所定の閾値を超えた場合に注文が確定したものとして登録するようにしているが、店舗４のポリシーによっては、注文が確定する前段階の「注文が来るかもしれない」という可能性の段階で、例えば、その数が一定数以上に達した場合には材料の発注等の準備を行う等の運用を行う場合も想定される。したがって、例えば、店舗情報ＤＢ１５０に、店舗４毎に、購入条件の確度の閾値と、対応する処理内容（「注文確定」やその前段階の「準備処理開始」等）を個別に複数設定できるようにしてもよい。また、店舗４側での準備に要する時間や工数等の制約条件と、各顧客３の過去の行動や購入履歴等の情報に基づいて、店舗４毎および顧客３毎に、最適な閾値を自動もしくは手動で設定するようにしてもよい。

注文管理部１３は、仮注文管理部１２により作成された注文情報を注文ＤＢ１３０に記録して管理する機能を有する。各注文について、後述する決済処理部１４による決済が完了したか否かのステータスを管理するようにしてもよい。また、各注文に係る商品等が店舗４において顧客３に実際に受け渡された旨の情報を店舗システム４０から取得して、注文に係る商品購入・販売が完了したか否かのステータスを管理するようにしてもよい。これにより、例えば、購入条件が充足して注文が登録されたにも関わらず、顧客３が対象の店舗４において対象の商品等を購入していないという状況を把握することができる。

決済処理部１４は、注文ＤＢ１３０に登録された注文について、顧客３が顧客情報ＤＢ１６０に予め登録しているクレジットカードや銀行口座、ポイントサービス等の決済手段により、図示しない金融機関等の決済機関との間で自動的に決済処理を行う機能を有する。購入条件が充足して注文ＤＢ１３０に新たな注文が登録された時点で、対象の顧客３が店舗４に入店する前に事前に決済を行っておいてもよいし、顧客３が店舗４で実際に商品等を受け取った旨の情報を店舗システム４０等から取得した時点で自動的に決済を行うようにしてもよい。決済まで完了した注文については、履歴の情報を購入履歴ＤＢ１４０に記録する。

店舗管理部１５は、各店舗４に係るマスタ情報を店舗情報ＤＢ１５０に記録して管理する機能を有する。各店舗４の担当者等は、例えば、店舗システム４０や他の情報処理端末を使用してネットワーク２を介して店舗管理部１５にアクセスし、店舗情報の登録や更新等を行うことができる。当該店舗４において受けることができる注文の種類（商品等の種類）や、購入条件の確度の閾値と処理内容との対応関係の情報等、商品発注システム１を介して注文を受け付ける際の固有の条件の情報を設定・登録できるようにしてもよい。

顧客管理部１６は、各顧客３に係るマスタ情報を顧客情報ＤＢ１６０に記録して管理する機能を有する。各顧客３は、例えば、顧客端末３０の商品購入アプリケーション３１や他の情報処理端末を使用してネットワーク２を介して顧客管理部１６にアクセスし、顧客情報の登録や更新等を行うことができる。顧客情報には、例えば、顧客３のアカウント情報や属性情報に加えて、決済手段に係る情報や、各種の個人設定の内容等が含まれ得る。

なお、図１の例では、ウィッシュリストＤＢ１１０、仮注文ＤＢ１２０、および注文ＤＢ１３０の各データベースに、それぞれ、ウィッシュリスト、仮注文、および注文の情報を分けて記録するものとしているが、これらの情報は、いずれも特定の店舗４での特定の商品等の購入希望や購入予定に係るものであり、その購入条件の確度が異なるだけであるとも言い得る。よって、これらの一連の情報を、例えば、１つの購入希望・購入予定に基づく１つの情報として１つのデータベースに記録し、購入条件の確度に基づいてステータスが異なるものとして管理するようにしてもよい。

＜処理の流れ＞
図２は、本実施の形態における商品の購入・販売の処理の流れの例について概要を示したフロー図である。ここでは、商品の購入・販売の具体例（以下では単に「具体例」と記載する場合がある）として、患者（顧客３）が医師の処方箋に基づいて調剤薬局（店舗４）にて処方薬を購入する場合を挙げて説明する。調剤薬局では、通常、患者が処方箋を提示してから、これに基づく調剤作業が行われるため、その間の待ち時間が生じてしまう。これに対し、本実施の形態では、例えば、処方箋の電子データを予めウィッシュリストもしくは仮注文として登録しておくことで、患者が偶然近くに来たために調剤薬局に立ち寄ったような場合でも、事前に調剤されている処方薬を待ち時間なく受け取ることを可能とするものである。

図２のフローにおいて、まず、顧客３は、顧客端末３０上の商品購入アプリケーション３１を利用して、購入希望の商品と購入条件に係る情報をウィッシュリストに登録する（Ｓ０１）。上述したように、商品購入アプリケーション３１が商品発注システム１のウィッシュリスト管理部１１にアクセスし、購入希望の商品や購入条件をウィッシュリストＤＢ１１０に登録するようにしてもよい（Ｓ０２）。

具体例の場合では、例えば、患者（顧客３）が病院にて受け取った処方箋の情報を、商品購入アプリケーション３１に画像もしくはデータ入力等により取り込み、処方薬（商品）の受取希望条件（例えば、調剤薬局の場所や受け取りを希望する日時等）と、これに関連付ける患者の行動予定情報３２（当該調剤薬局の近隣への移動予定）や位置情報、天候情報（「『晴れ』であれば受け取りに行く」等）等の条件（購入条件）を登録する。なお、行動予定情報３２は、例えば、顧客端末３０に導入されている図示しないスケジュール管理アプリケーション等と連携することで取得することができる。また、処方箋のデータを電子データとして授受可能な場合には、病院により作成された処方箋データを直接もしくは間接にネットワーク２を介して商品発注システム１のウィッシュリストＤＢ１１０に登録できるようにしてもよい。

その後、顧客端末３０の商品購入アプリケーション３１では、ウィッシュリストに登録された各購入希望について、定期的に購入条件の情報を取得し（Ｓ０３）、購入条件の充足が一定程度以上近付いているか否かを判定する（Ｓ０４）。上述したように、例えば、購入希望日時が近付いているか（例えば、３日前等）や、購入希望店舗（具体例の場合では調剤薬局）から一定の距離範囲（例えば、５ｋｍ圏内）に近付いているか否か、購入希望店舗の付近に移動することになる行動予定日時が近付いているか否か等により判定する。

購入条件の充足が一定程度以上近付いていない場合は（Ｓ０４：Ｎ）、ステップＳ０３に戻り、購入条件の情報の取得と充足の程度の判定の処理を繰り返す。一方、購入条件の充足が一定程度以上近付いている場合は（Ｓ０４：Ｙ）、商品購入アプリケーション３１は、購入希望商品（具体例の場合では処方薬）の仮注文情報を作成して商品発注システム１の仮注文管理部１２により仮注文ＤＢ１２０に登録する（Ｓ０５、Ｓ０６）。仮注文の登録後は、顧客端末３０の商品購入アプリケーション３１は、対象の顧客３の行動予定情報３２や、ＧＰＳセンサ３３により検知した位置情報を定期的に取得し（Ｓ０７）、商品発注システム１に送信する（Ｓ０８）。

顧客３の行動予定情報３２や位置情報を取得した商品発注システム１では、仮注文管理部１２により、取得した行動予定情報３２や位置情報に基づいて仮注文の確度を算出する（Ｓ０９）。上述したように、確度は、例えば、購入条件における日時（購入希望日時や行動予定の日時）が近付くほど高くなり、また、顧客３の位置情報が対象の店舗４に近付くほど高くなる。具体例の場合では、例えば、処方薬の調剤と購入の希望日の１日前に確度が高くなり、さらに、購入希望日当日→購入希望日当日に調剤薬局付近への移動を開始→調剤薬局の近隣５ｋｍ圏内に移動→購入希望時刻１時間前→調剤薬局の近隣５００ｍ圏内に移動→調剤薬局に来店、というような、日時と場所・位置により特定される段階毎に順次確度が高くなっていく。なお、購入条件に天候等の他の条件が設定されている場合は、これらの条件についても考慮して確度を算出する。

そして、算出された確度が所定の閾値を超えたか否かを判定し（Ｓ１０）、閾値を超えていない（確度が十分ではない）場合は（Ｓ１０：Ｎ）、顧客端末３０からの行動予定情報３２および位置情報の取得（待ち受け）に戻って処理を繰り返す。確度が十分で閾値を超えた場合は（Ｓ１０：Ｙ）、対象の顧客３（顧客端末３０）に対して購入意向を最終確認する旨の通知を出力する（Ｓ１１）。通知は、例えば、顧客端末３０上の商品購入アプリケーション３１の画面等を介して出力される。

この通知に対して、顧客３が顧客端末３０の商品購入アプリケーション３１等を介して購入を承認する旨の入力をすると（Ｓ１２）、商品発注システム１では、注文が確定したものとして、注文管理部１３により対応する注文情報を作成して注文ＤＢ１３０に登録するとともに、注文情報を対象の店舗４の店舗システム４０に送信する（Ｓ１３）。このとき、例えば、「受取ＩＤ」のような注文識別情報を発行し、これを顧客端末３０の商品購入アプリケーション３１に通知する（Ｓ１４）とともに、これと注文情報（具体例の場合では処方箋の内容）とを関連付けて注文ＤＢ１３０への登録や店舗システム４０へ送信する。また、この時点で、顧客情報ＤＢ１６０に予め登録されている顧客３の決済手段により自動的に決済処理を行うようにしてもよい（Ｓ１５）。

店舗４では、店舗システム４０により注文情報を取得すると（Ｓ１６）、注文内容に対応した商品提供の準備作業（具体例の場合では、処方箋に基づく調剤作業）を開始する（Ｓ１７）。そして、対象の顧客３が店舗４に入店して「受取ＩＤ」を提示すると（Ｓ１８）、店舗４では直ちに商品（具体例の場合では、処方薬）の提供を行い（Ｓ１９）、顧客３は待ち時間なしで商品を受け取ることができる（Ｓ２０）。

以上に説明したように、本発明の一実施の形態である商品発注システム１によれば、顧客３が有する商品等の「緩い」購入意図と、当該顧客３の行動予定や位置情報とを連携させて解析し、当該顧客３が店舗４に来店する前に、対象の商品等に係る仮注文情報を自動的に生成する。そして、当該顧客３の行動内容や位置情報等を常時トラッキングし、その内容に基づいて仮注文情報の確度を算出・推測するとともに、確度が所定の閾値を超えた場合に、確定した注文情報として対象の店舗４に対して登録し、来店前に決済まで行っておく。これにより、店舗４における顧客３の待ち時間をゼロに近づけるとともに、店舗４での顧客３による決済処理も不要とすることができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

例えば、上記の実施の形態では、調剤薬局での処方薬の購入のような、店舗４における商品の購入・販売を例として説明したが、このような構成に限られない。例えば、ファストフード店でのドライブスルーでの注文や、自宅に帰宅する前の暖房や風呂等の稼働制御等にも適用することができる。すなわち、利用者が予め商品やサービス等の利用希望日時等を登録しておくことで、その日時や位置等の条件が一定以上近付いた段階で提供側が事前に準備を開始できるようにし、利用者が希望する日時や場所で待ち時間なく利用することを可能とする仕組みに広く適用することができる。

上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

本発明は、実店舗における商品やサービスの購入・販売を仲介する商品発注システムに利用可能である。

１…商品発注システム、２…ネットワーク、３…顧客、４…店舗、
１１…ウィッシュリスト管理部、１２…仮注文管理部、１３…注文管理部、１４…決済処理部、１５…店舗管理部、１６…顧客管理部、
３０…顧客端末、３１…商品購入アプリケーション、３２…行動予定情報、３３…ＧＰＳセンサ、
４０…店舗システム、
１１０…ウィッシュリストＤＢ、１２０…仮注文ＤＢ、１３０…注文ＤＢ、１４０…購入履歴ＤＢ、１５０…店舗情報ＤＢ、１６０…顧客情報ＤＢ

Claims (6)

1. 顧客の商品等の購入希望に基づいて、前記商品等を販売する店舗に対して注文を行う商品発注システムであって、
   前記顧客により入力された前記購入希望に係る前記商品等と購入条件からなるウィッシュリストの情報を保持し、前記購入条件が所定の程度以上充足したか否かを判定するウィッシュリスト管理部と、
   前記ウィッシュリスト管理部において前記購入条件が所定の程度以上充足したと判定された場合に、前記購入条件に係る前記ウィッシュリストに基づいて仮注文の情報を作成して保持し、前記顧客が保持する顧客端末から取得した前記顧客の行動予定情報および／または前記顧客の位置情報に基づいて前記仮注文の確度を算出し、前記確度が所定の閾値を超えたか否かを判定する仮注文管理部と、
   前記仮注文管理部において前記確度が所定の閾値を超えたと判定された場合に、前記仮注文の情報に基づいて注文の情報を作成して保持し、前記注文に係る前記商品等を販売する前記店舗に対して前記注文の情報を送信する注文管理部と、
   を有する、商品発注システム。
2. 請求項１に記載の商品発注システムにおいて、
   前記購入条件は、前記顧客が前記購入希望に係る前記商品等の購入を希望もしくは予定する日付もしくは日時、および前記顧客の位置の情報を含み、
   前記仮注文管理部は、前記購入条件に係る前記日付もしくは日時が近付くのに応じて、および前記顧客の位置が前記購入希望に係る前記店舗に近付くのに応じて、前記仮注文に係る前記確度が高くなるよう算出する、商品発注システム。
3. 請求項１に記載の商品発注システムにおいて、
   前記所定の閾値は、前記店舗毎に、前記店舗における前記注文に係る処理内容に応じて複数設けられる、商品発注システム。
4. 請求項１に記載の商品発注システムにおいて、
   前記所定の閾値は、前記店舗毎もしくは前記店舗が販売する前記商品毎、および／または、前記顧客毎に設けられる、商品発注システム。
5. 請求項１に記載の商品発注システムにおいて、
   さらに、前記注文管理部において前記注文の情報が前記店舗に送信された場合に、前記顧客により予め登録されている決済手段により前記注文に係る決済処理を行う決済処理部を有する、商品発注システム。
6. 請求項１に記載の商品発注システムにおいて、
   前記注文管理部は、前記注文の情報を前記店舗に送信する前に、前記顧客に対して承諾を得るための通知を出力する、商品発注システム。

Images