Some content of this application is unavailable at the moment.
If this situation persist, please contact us atFeedback&Contact
1. (WO2019008619) PRODUCT ORDERING SYSTEM
Document

明 細 書

発明の名称 商品発注システム

技術分野

0001  

背景技術

0002   0003   0004  

先行技術文献

特許文献

0005  

発明の概要

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

0006   0007   0008   0009  

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

0010   0011   0012  

発明の効果

0013   0014  

図面の簡単な説明

0015  

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

0016   0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046  

産業上の利用可能性

0047  

符号の説明

0048  

請求の範囲

1   2   3   4   5   6  

図面

1   2  

明 細 書

発明の名称 : 商品発注システム

技術分野

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

背景技術

[0002]
 近年ではEC(Electronic Commerce)サイトを利用したオンラインショッピングが広く普及している。一方で、例えば、薬局での処方薬の購入や、レストランでの食事等、顧客が購入を希望する商品・物品やサービス(以下では「商品等」と総称する場合がある)について注文し、注文に対応する商品等の提供を実店舗において実際に受ける、という購入形態も多い。
[0003]
 顧客による注文は、店員等に対して直接口頭で行われる場合が多いが、顧客の利便性や店舗側の省力化等を実現する仕組みとして、例えば、券売機により購入したチケット等を店員に受け渡しての注文や、タブレット端末を用いたセルフオーダーシステムを用いた注文も行われている。また、注文を行った顧客による待ち時間を短縮する仕組みとして、例えば、ドライブスルーの仕組みが利用されている。ここでは、単に顧客が車から降りることなく商品を購入できるだけではなく、顧客が先に注文を行い、その後、受取場所まで移動する間に、注文に係る商品を店舗側が準備しておくことで、顧客の待ち時間を短縮している。
[0004]
 これに関連する技術として、例えば、特開2013-171397号公報(特許文献1)には、ドライブスルーの混雑時にユーザが車両の中から商品のオーダーを行えるようにすることで、ユーザが商品をオーダーする時間と、ユーザがオーダーした商品を店舗側で準備するための時間を短縮する旨が記載されている。また、ドライブスルーの待ち時間を利用してオーダーした商品の精算金額を電子マネーにより決済できるようにすることで、決済にかかる時間を短縮する旨が記載されている。

先行技術文献

特許文献

[0005]
特許文献1 : 特開2013-171397号公報

発明の概要

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

[0006]
 従来技術のような仕組みを利用することで、注文に係る顧客の待ち時間や、注文を受けた店舗側の準備時間をある程度短縮することができる。しかし、注文を行うにはドライブスルーのような設備が併設された対象の店舗まで実際に行く必要がある。したがって、例えば、「近くに行くことがあったら寄ってみたい」というような「緩い」購入意図(すなわち、「予約」に適さない購入意図)を有する顧客にとっては、実際に近くに来たにも関わらず忘れていたために当該店舗に寄ることができず、商品等を購入するためには再度訪問する必要がある等、時間と労力が無駄になる場合が生じ得る。また、多数の顧客が同時期に集中して来店すると、注文を行うまでの待ち時間が長くなり、時間の無駄につながり得る。
[0007]
 また、店舗側にとっても、ドライブスルーやセルフオーダーシステムのような設備を設置する必要があり、設備投資の負担が大きくなる。また、多数の顧客が同時期に来店した場合の注文集中による対応負担の増大やクレームの増加等の影響を、予測したり標準化したりすることも困難である。また、商品や原材料の適正在庫の見積もり精度が低下し、余剰に伴うロスや不足に伴う機会損失のリスクが高くなってしまう。
[0008]
 そこで本発明の目的は、顧客が実際に店舗に来店する前に、「緩い」購入意図に基づいて適切なタイミングで注文を行う仕組みを店舗側の負担が小さい形で実現する商品発注システムを提供することにある。
[0009]
 本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

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

[0010]
 本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
[0011]
 本発明の代表的な実施の形態による商品発注システムは、顧客の商品等の購入希望に基づいて、前記商品等を販売する店舗に対して注文を行う商品発注システムであって、前記顧客により入力された前記購入希望に係る前記商品等と購入条件からなるウィッシュリストの情報を保持し、前記購入条件が所定の程度以上充足したか否かを判定するウィッシュリスト管理部を有する。
[0012]
 さらに、前記ウィッシュリスト管理部において前記購入条件が所定の程度以上充足したと判定された場合に、前記購入条件に係る前記ウィッシュリストに基づいて仮注文の情報を作成して保持し、前記顧客が保持する顧客端末から取得した前記顧客の行動予定情報および/または前記顧客の位置情報に基づいて前記仮注文の確度を算出し、前記確度が所定の閾値を超えたか否かを判定する仮注文管理部と、前記仮注文管理部において前記確度が所定の閾値を超えたと判定された場合に、前記仮注文の情報に基づいて注文の情報を作成して保持し、前記注文に係る前記商品等を販売する前記店舗に対して前記注文の情報を送信する注文管理部と、を有する。

発明の効果

[0013]
 本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
[0014]
 すなわち、本発明の代表的な実施の形態によれば、顧客が実際に店舗に来店する前に、「緩い」購入意図に基づいて適切なタイミングで注文を行う仕組みを店舗側の負担が小さい形で実現することが可能となる。

図面の簡単な説明

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

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

[0016]
 以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。
[0017]
 本発明の一実施の形態である商品発注システムは、顧客が有する商品等の「緩い」購入意図(以下では「ウィッシュリスト」と記載する場合がある)と、当該顧客の行動予定や位置情報とを連携させて解析し、当該顧客が店舗に来店する前に、対象の商品等に係る仮注文情報を自動的に生成する。そして、当該顧客の行動内容や位置情報等を常時トラッキングし、その内容に基づいて仮注文情報の確度を算出・推測するとともに、確度が一定の値を超えた場合に、確定した注文情報として対象の店舗に対して登録し、来店前に決済まで行っておく。これにより、店舗における顧客の待ち時間をゼロに近づけるとともに、店舗での顧客による決済処理も不要とすることができる。
[0018]
 <システム構成>
 図1は、本発明の一実施の形態である商品発注システムの構成例について概要を示した図である。本実施の形態の商品発注システム1は、例えば、顧客3(顧客端末30)および店舗4(店舗システム40)に対して、インターネット等のネットワーク2を介して商品等の売買の仲介サービスを提供するサーバシステムであり、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ等により構成される。そして、図示しないCPU(Central Processing Unit)により、HDD(Hard Disk Drive)等の記録装置からメモリ上に展開したOS(Operating System)やDBMS(DataBase Management System)、Webサーバプログラム等のミドルウェアや、その上で稼働するソフトウェアを実行することで、上記サービスの提供に係る後述する各種機能を実現する。
[0019]
 なお、顧客端末30は、例えば、顧客3が常時携行するタブレット端末やスマートフォン等の汎用の情報処理端末であり、図示しないCPUにより、メモリ上に展開したOS等のミドルウェアや、その上で稼働するアプリケーションプログラムを実行することで、顧客3に対して商品購入に係るユーザインタフェースを含む各種サービスを提供する。また、店舗システム40は、例えば、各店舗4に設置されたPC(Personal Computer)やサーバ機器等からなる情報処理システムであり、図示しないCPUにより、HDD等の記録装置からメモリ上に展開したOS等のミドルウェアや、その上で稼働するソフトウェアを実行することで、利用者からの注文情報を受け付けて処理もしくは店員への指示等を行う。
[0020]
 商品発注システム1は、例えば、ソフトウェアとして実装されたウィッシュリスト管理部11、仮注文管理部12、注文管理部13、決済処理部14、店舗管理部15、および顧客管理部16等の各部を有する。また、データベース等により実装されたウィッシュリストデータベース(DB)110、仮注文DB120、注文DB130、購入履歴DB140、店舗情報DB150、および顧客情報DB160等の各データを有する。
[0021]
 ウィッシュリスト管理部11は、各顧客3の購入希望商品等からなるウィッシュリストの情報をウィッシュリストDB110に記録して管理する機能を有する。例えば、顧客端末30に導入された商品購入アプリケーション31を介して顧客3から入力された、購入意図を有する商品等の情報を、購入条件と関連付けてウィッシュリストとしてウィッシュリストDB110に登録する。なお、本実施の形態では、ウィッシュリストを商品発注システム1上のウィッシュリストDB110に保持するものとしているが、各顧客3の顧客端末30上の商品購入アプリケーション31において個別に保持し、後述する仮注文となるまで商品発注システム1上には保持しない構成としてもよい。
[0022]
 顧客3の「購入意図」には、「○月○日○○時に△△店で□□□を買う」というように希望する購入条件(購入日時や店舗)が確定しているもの(すなわち、「予約」し得るもの)を含んでいてもよいが、本実施の形態では、購入条件が確定しておらず、購入条件が充足すれば購入するというもの(「予約」に適さないもの)を含むものとする。
[0023]
 このような購入条件には、例えば、上述したように、「△△店の近くに行くことがあったら寄ってみたい」というように漠然としたもの(確度の低いもの)や、「○月○日から1週間の間に△△店で□□□を受け取る」というようにある程度はっきりしたもの(確度の高いもの)等、様々な確度のものが含まれ得る。なお、上記の例では、購入条件として日付もしくは日時、および場所(店舗4およびこれに対する位置)を含むものとしているが、その他にも、例えば、そのときの天候や所持金(口座残高)等、店舗4への来店や商品の購入に影響を及ぼし得る各種条件を含んでいてもよい。
[0024]
 また、ウィッシュリスト管理部11は、ウィッシュリストに登録された購入希望商品に係る購入条件について、条件充足に一定程度以上近付いたと判定した場合に、対応する仮注文を作成して、後述する仮注文管理部12を介して仮注文DB120に登録する。例えば、購入希望日時が近付いた場合(例えば、3日前等)や、購入希望店舗から一定の距離範囲(例えば、5km圏内)に近付いた場合、購入希望店舗の付近に移動することになる行動予定(スケジュール)の日時が近付いた場合等において、条件充足に一定程度以上近付いたと判定する。なお、ウィッシュリストを顧客端末30上の商品購入アプリケーション31において管理する構成の場合は、これらの判定を商品購入アプリケーション31において行ってもよい。
[0025]
 仮注文管理部12は、ウィッシュリスト管理部11(もしくは商品購入アプリケーション31)により作成された仮注文の情報を仮注文DB120に記録して管理する機能を有する。また、各仮注文について、対象の顧客3の顧客端末30から送信された行動予定情報32や、GPSセンサ33により検知された位置情報に基づいて、仮注文の確度を算出し、確度が所定の閾値を超えた場合に、購入条件が充足したと判断して、対応する注文を作成して、後述する注文管理部13を介して注文DB130に登録する。このとき、注文が登録される旨を顧客端末30に対して通知し、顧客3による承諾・拒否の入力を受け付けるようにしてもよい。
[0026]
 仮注文の確度は、例えば、購入条件における日時(購入希望日時や行動予定の日時)が近付くほど高くなり、また、顧客3の位置情報が対象の店舗4に近付くほど高くなる。本実施の形態では、顧客端末30から取得したこれらの情報を常時トラッキングし、値の変化や遷移を所定の基準や条件に基づいてスコアリングして、購入条件の確度とする。スコアリングの際の基準や条件は特に限定されず、例えば、パラメータ毎に予め定めた数式やテーブル等を適宜用いることができる。具体的には、例えば、日時が、購入希望日時の1日前→当日→1時間前→購入希望日時等の条件に達する毎に所定のスコアを加算し、同様に、位置情報が、対象の店舗4の近隣5km圏内→近隣500m圏内→来店等の条件に達する毎に所定のスコアを加算する等の方法をとることができる。
[0027]
 なお、上記では、確度が所定の閾値を超えた場合に注文が確定したものとして登録するようにしているが、店舗4のポリシーによっては、注文が確定する前段階の「注文が来るかもしれない」という可能性の段階で、例えば、その数が一定数以上に達した場合には材料の発注等の準備を行う等の運用を行う場合も想定される。したがって、例えば、店舗情報DB150に、店舗4毎に、購入条件の確度の閾値と、対応する処理内容(「注文確定」やその前段階の「準備処理開始」等)を個別に複数設定できるようにしてもよい。また、店舗4側での準備に要する時間や工数等の制約条件と、各顧客3の過去の行動や購入履歴等の情報に基づいて、店舗4毎および顧客3毎に、最適な閾値を自動もしくは手動で設定するようにしてもよい。
[0028]
 注文管理部13は、仮注文管理部12により作成された注文情報を注文DB130に記録して管理する機能を有する。各注文について、後述する決済処理部14による決済が完了したか否かのステータスを管理するようにしてもよい。また、各注文に係る商品等が店舗4において顧客3に実際に受け渡された旨の情報を店舗システム40から取得して、注文に係る商品購入・販売が完了したか否かのステータスを管理するようにしてもよい。これにより、例えば、購入条件が充足して注文が登録されたにも関わらず、顧客3が対象の店舗4において対象の商品等を購入していないという状況を把握することができる。
[0029]
 決済処理部14は、注文DB130に登録された注文について、顧客3が顧客情報DB160に予め登録しているクレジットカードや銀行口座、ポイントサービス等の決済手段により、図示しない金融機関等の決済機関との間で自動的に決済処理を行う機能を有する。購入条件が充足して注文DB130に新たな注文が登録された時点で、対象の顧客3が店舗4に入店する前に事前に決済を行っておいてもよいし、顧客3が店舗4で実際に商品等を受け取った旨の情報を店舗システム40等から取得した時点で自動的に決済を行うようにしてもよい。決済まで完了した注文については、履歴の情報を購入履歴DB140に記録する。
[0030]
 店舗管理部15は、各店舗4に係るマスタ情報を店舗情報DB150に記録して管理する機能を有する。各店舗4の担当者等は、例えば、店舗システム40や他の情報処理端末を使用してネットワーク2を介して店舗管理部15にアクセスし、店舗情報の登録や更新等を行うことができる。当該店舗4において受けることができる注文の種類(商品等の種類)や、購入条件の確度の閾値と処理内容との対応関係の情報等、商品発注システム1を介して注文を受け付ける際の固有の条件の情報を設定・登録できるようにしてもよい。
[0031]
 顧客管理部16は、各顧客3に係るマスタ情報を顧客情報DB160に記録して管理する機能を有する。各顧客3は、例えば、顧客端末30の商品購入アプリケーション31や他の情報処理端末を使用してネットワーク2を介して顧客管理部16にアクセスし、顧客情報の登録や更新等を行うことができる。顧客情報には、例えば、顧客3のアカウント情報や属性情報に加えて、決済手段に係る情報や、各種の個人設定の内容等が含まれ得る。
[0032]
 なお、図1の例では、ウィッシュリストDB110、仮注文DB120、および注文DB130の各データベースに、それぞれ、ウィッシュリスト、仮注文、および注文の情報を分けて記録するものとしているが、これらの情報は、いずれも特定の店舗4での特定の商品等の購入希望や購入予定に係るものであり、その購入条件の確度が異なるだけであるとも言い得る。よって、これらの一連の情報を、例えば、1つの購入希望・購入予定に基づく1つの情報として1つのデータベースに記録し、購入条件の確度に基づいてステータスが異なるものとして管理するようにしてもよい。
[0033]
 <処理の流れ>
 図2は、本実施の形態における商品の購入・販売の処理の流れの例について概要を示したフロー図である。ここでは、商品の購入・販売の具体例(以下では単に「具体例」と記載する場合がある)として、患者(顧客3)が医師の処方箋に基づいて調剤薬局(店舗4)にて処方薬を購入する場合を挙げて説明する。調剤薬局では、通常、患者が処方箋を提示してから、これに基づく調剤作業が行われるため、その間の待ち時間が生じてしまう。これに対し、本実施の形態では、例えば、処方箋の電子データを予めウィッシュリストもしくは仮注文として登録しておくことで、患者が偶然近くに来たために調剤薬局に立ち寄ったような場合でも、事前に調剤されている処方薬を待ち時間なく受け取ることを可能とするものである。
[0034]
 図2のフローにおいて、まず、顧客3は、顧客端末30上の商品購入アプリケーション31を利用して、購入希望の商品と購入条件に係る情報をウィッシュリストに登録する(S01)。上述したように、商品購入アプリケーション31が商品発注システム1のウィッシュリスト管理部11にアクセスし、購入希望の商品や購入条件をウィッシュリストDB110に登録するようにしてもよい(S02)。
[0035]
 具体例の場合では、例えば、患者(顧客3)が病院にて受け取った処方箋の情報を、商品購入アプリケーション31に画像もしくはデータ入力等により取り込み、処方薬(商品)の受取希望条件(例えば、調剤薬局の場所や受け取りを希望する日時等)と、これに関連付ける患者の行動予定情報32(当該調剤薬局の近隣への移動予定)や位置情報、天候情報(「『晴れ』であれば受け取りに行く」等)等の条件(購入条件)を登録する。なお、行動予定情報32は、例えば、顧客端末30に導入されている図示しないスケジュール管理アプリケーション等と連携することで取得することができる。また、処方箋のデータを電子データとして授受可能な場合には、病院により作成された処方箋データを直接もしくは間接にネットワーク2を介して商品発注システム1のウィッシュリストDB110に登録できるようにしてもよい。
[0036]
 その後、顧客端末30の商品購入アプリケーション31では、ウィッシュリストに登録された各購入希望について、定期的に購入条件の情報を取得し(S03)、購入条件の充足が一定程度以上近付いているか否かを判定する(S04)。上述したように、例えば、購入希望日時が近付いているか(例えば、3日前等)や、購入希望店舗(具体例の場合では調剤薬局)から一定の距離範囲(例えば、5km圏内)に近付いているか否か、購入希望店舗の付近に移動することになる行動予定日時が近付いているか否か等により判定する。
[0037]
 購入条件の充足が一定程度以上近付いていない場合は(S04:N)、ステップS03に戻り、購入条件の情報の取得と充足の程度の判定の処理を繰り返す。一方、購入条件の充足が一定程度以上近付いている場合は(S04:Y)、商品購入アプリケーション31は、購入希望商品(具体例の場合では処方薬)の仮注文情報を作成して商品発注システム1の仮注文管理部12により仮注文DB120に登録する(S05、S06)。仮注文の登録後は、顧客端末30の商品購入アプリケーション31は、対象の顧客3の行動予定情報32や、GPSセンサ33により検知した位置情報を定期的に取得し(S07)、商品発注システム1に送信する(S08)。
[0038]
 顧客3の行動予定情報32や位置情報を取得した商品発注システム1では、仮注文管理部12により、取得した行動予定情報32や位置情報に基づいて仮注文の確度を算出する(S09)。上述したように、確度は、例えば、購入条件における日時(購入希望日時や行動予定の日時)が近付くほど高くなり、また、顧客3の位置情報が対象の店舗4に近付くほど高くなる。具体例の場合では、例えば、処方薬の調剤と購入の希望日の1日前に確度が高くなり、さらに、購入希望日当日→購入希望日当日に調剤薬局付近への移動を開始→調剤薬局の近隣5km圏内に移動→購入希望時刻1時間前→調剤薬局の近隣500m圏内に移動→調剤薬局に来店、というような、日時と場所・位置により特定される段階毎に順次確度が高くなっていく。なお、購入条件に天候等の他の条件が設定されている場合は、これらの条件についても考慮して確度を算出する。
[0039]
 そして、算出された確度が所定の閾値を超えたか否かを判定し(S10)、閾値を超えていない(確度が十分ではない)場合は(S10:N)、顧客端末30からの行動予定情報32および位置情報の取得(待ち受け)に戻って処理を繰り返す。確度が十分で閾値を超えた場合は(S10:Y)、対象の顧客3(顧客端末30)に対して購入意向を最終確認する旨の通知を出力する(S11)。通知は、例えば、顧客端末30上の商品購入アプリケーション31の画面等を介して出力される。
[0040]
 この通知に対して、顧客3が顧客端末30の商品購入アプリケーション31等を介して購入を承認する旨の入力をすると(S12)、商品発注システム1では、注文が確定したものとして、注文管理部13により対応する注文情報を作成して注文DB130に登録するとともに、注文情報を対象の店舗4の店舗システム40に送信する(S13)。このとき、例えば、「受取ID」のような注文識別情報を発行し、これを顧客端末30の商品購入アプリケーション31に通知する(S14)とともに、これと注文情報(具体例の場合では処方箋の内容)とを関連付けて注文DB130への登録や店舗システム40へ送信する。また、この時点で、顧客情報DB160に予め登録されている顧客3の決済手段により自動的に決済処理を行うようにしてもよい(S15)。
[0041]
 店舗4では、店舗システム40により注文情報を取得すると(S16)、注文内容に対応した商品提供の準備作業(具体例の場合では、処方箋に基づく調剤作業)を開始する(S17)。そして、対象の顧客3が店舗4に入店して「受取ID」を提示すると(S18)、店舗4では直ちに商品(具体例の場合では、処方薬)の提供を行い(S19)、顧客3は待ち時間なしで商品を受け取ることができる(S20)。
[0042]
 以上に説明したように、本発明の一実施の形態である商品発注システム1によれば、顧客3が有する商品等の「緩い」購入意図と、当該顧客3の行動予定や位置情報とを連携させて解析し、当該顧客3が店舗4に来店する前に、対象の商品等に係る仮注文情報を自動的に生成する。そして、当該顧客3の行動内容や位置情報等を常時トラッキングし、その内容に基づいて仮注文情報の確度を算出・推測するとともに、確度が所定の閾値を超えた場合に、確定した注文情報として対象の店舗4に対して登録し、来店前に決済まで行っておく。これにより、店舗4における顧客3の待ち時間をゼロに近づけるとともに、店舗4での顧客3による決済処理も不要とすることができる。
[0043]
 以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
[0044]
 例えば、上記の実施の形態では、調剤薬局での処方薬の購入のような、店舗4における商品の購入・販売を例として説明したが、このような構成に限られない。例えば、ファストフード店でのドライブスルーでの注文や、自宅に帰宅する前の暖房や風呂等の稼働制御等にも適用することができる。すなわち、利用者が予め商品やサービス等の利用希望日時等を登録しておくことで、その日時や位置等の条件が一定以上近付いた段階で提供側が事前に準備を開始できるようにし、利用者が希望する日時や場所で待ち時間なく利用することを可能とする仕組みに広く適用することができる。
[0045]
 上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、SSD(Solid State Drive)等の記録装置、またはICカード、SDカード、DVD等の記録媒体に置くことができる。
[0046]
 また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

産業上の利用可能性

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

符号の説明

[0048]
1…商品発注システム、2…ネットワーク、3…顧客、4…店舗、
11…ウィッシュリスト管理部、12…仮注文管理部、13…注文管理部、14…決済処理部、15…店舗管理部、16…顧客管理部、
30…顧客端末、31…商品購入アプリケーション、32…行動予定情報、33…GPSセンサ、
40…店舗システム、
110…ウィッシュリストDB、120…仮注文DB、130…注文DB、140…購入履歴DB、150…店舗情報DB、160…顧客情報DB

請求の範囲

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

図面

[ 図 1]

[ 図 2]