JP2016071450A - 来店時リクエスト受付システム及び来店時リクエスト受付方法 - Google Patents

Abstract

【課題】利用者が店舗に対して、置いてほしい商品のリクエストを手軽に上げられ、店舗が品揃えを効率化できること。【解決手段】店舗サーバは、利用者の端末から、利用者が店舗に置いて欲しい商品のリクエストを受信し、利用者のカードＩＤに関連付けてリクエスト情報として登録する。リクエスト情報は、店舗サーバ、利用者端末、カード内部の少なくともいずれかに記憶させる。そして、利用者がその店舗又はその店舗のグループ店に来店した際に、利用者端末又はカードから利用者のカードＩＤを読み出し、読み出したカードＩＤが登録されたカードＩＤと一致したときに、リクエスト情報を受け付ける（有効化する）。リクエスト情報には、希望店舗、希望時間帯、希望曜日の情報が含まれるので、店舗ごとに別々の商品を時間帯や曜日と共に指定できる。また、受付けられたリクエスト情報は、利用者の来店頻度や利用金額等に応じて優先付がされる。【選択図】図２

Description

本発明は、利用者の店舗に対する商品のリクエストを受付けるシステム及びその方法に関する。

近年、インターネット上で買い物をする機会が多くなるにつれて、オンラインショッピングでの買い物を支援する方法を実店舗にも応用したり、あるいは融合させたりするシステムが幾つか知られている。

例えば、特許文献１には、現実のショッピングでもオンラインでのようなウィッシュリスト機能を実現する買い物支援システム等が記載されている。上記システムによれば、ＲＦＩＤ（Radio Frequency IDentifier）チップに商品情報を記憶させておき、これを携帯電話機に備えられるリーダ部にて読み取ると共に、読み取られた商品情報をリスト情報として記憶する。これによってリアルショップ（実店舗）にて販売される商品についてもウィッシュリストを簡易に作成することができる。

また、特許文献２には、ユーザが実店舗に来店するのに要する時間又は距離を表す来店必要情報に基づいて、複数の実店舗からユーザに情報提供する購入可能店舗を検索し、希望商品が配送されるまでの配送所要日数情報に基づいて、複数のネット店舗からユーザに情報提供する購入可能店舗を検索する店舗情報提供装置が記載されている。

また、特許文献３には、ユーザがインターネットで予めどのような商品情報を見た上で訪問してきたのかを実店舗が把握できるようにした購入支援方法等が記載されている。

特開２００５−３２７０７７号公報 特開２０１３−６１７０１号公報 特開２０１３−０３００００号公報

上記の特許文献に記載の技術は、ネット上で得られる各種の情報や経験を生かして、利用者の実店舗での買い物を支援するものであるが、本発明では、実店舗での以下に示すようなケースを課題として捉える。

図１は、本発明の課題のイメージを示したものである。コンビニエンス・ストア（以下、コンビニ）のある利用客が、朝は通勤途中のコンビニでドリンク、お昼は会社近くのコンビニで弁当、夕方は帰宅途中のコンビニでお菓子、夜は自宅近くのコンビニで翌朝の朝食を買うことを習慣にしているとする。それぞれの商品やお店には、時と場合に応じた「お気に入り」があるが、お気に入りの店に行ける時間帯は限られているので、その時間帯に行った店に必ずしも目的の商品があるとは限らない。あるいは、もともとその店舗では目的の商品を取り扱っていないこともある。このような場合、利用者は、仕方なく他社の類似商品を買ったり、少し離れた他の店に行ったり、ときには諦めたりもする。

利用者は、希望の商品がないからといって、ドリンクやお菓子といった少額の商品を、置いてもらうようにいちいち店側に要求することは気が引けるものである。しかし、欲しい物が欲しい時に購入できないと、その店への満足度はどんどん低下する。一方、店側にとっては、販売機会の喪失になる。通勤客のような固定客の満足度を高めることは重要であるが、かといって、限られた店舗スペースで需要がはっきりしない商品を置くことは難しい。

今日のコンビニエンスストアでは、売れ筋商品の分析や、配送計画などについて、詳細なマーケッティングデータに基づき、高度な分析システムによって、毎日の品揃えが行われている。しかしながら、極めて高度で精緻な情報を駆使する一方で、古来、商業の基本である、「消費者の声を聴く」ということがないままに営業が続けられている。そのような時代背景の中で改めて、どのように消費者の声を汲み上げるかというのが新たな課題である。このような課題を解決するために、利用者の希望する商品を、希望する場所で、希望する時間に買えるようにするリクエストを気軽に店側に伝えることができ、店側も需要のある商品をタイムリーに見極め、商品の品揃えを効率よくできるシステムが望まれている。

したがって、本発明では、上記のような課題に鑑み、顧客が実店舗への来店時等に商品のリクエストを店舗に対して気軽に上げることができ、店側の商品の品揃えを効率化することができるシステムを提供することを目的とする。

上記課題を解決するため、本発明の来店時リクエスト受付システムは、以下のような解決手段を提供する。

利用者の端末とネットワークを介して接続可能な店舗サーバが、前記利用者が店舗に置いて欲しい商品のリクエストを受信し、前記利用者の電子カードのＩＤに関連付けてリクエスト情報として登録する登録手段と、前記利用者が前記店舗又は前記店舗のグループ店に来店した際に、前記利用者の端末又は電子カードから前記利用者の電子カードのＩＤを読み出し、前記読み出した電子カードのＩＤが前記登録された電子カードのＩＤと一致したときに、前記リクエスト情報を受け付ける受付手段と、を備えることを特徴とする。

また、上記システムにおいて、前記リクエスト情報は、希望店舗、希望時間帯、及び希望曜日の情報を含むことを特徴とする。

また、上記システムにおいて、前記リクエスト情報は、前記利用者の電子カード、前記利用者の端末、前記店舗サーバの少なくともいずれかに記憶され、前記利用者が来店し、前記受付手段が前記リクエスト情報を受付けた際に有効化されることを特徴とする。

また、上記システムにおいて、前記登録手段は、リクエスト可能な商品の一覧を提示し、前記利用者は前記一覧から希望する商品を指定するか、又は前記一覧に希望する商品がない場合は、希望する商品の名称又はＩＤを入力させる手段を備えることを特徴とする。

また、上記システムにおいて、前記店舗サーバは、前記受付手段が受付けたリクエスト情報を解析し、前記利用者の前記店舗における利用頻度及び／又は平均利用金額に応じて、前記リクエスト情報の優先付の処理を行う処理手段を更に備えることを特徴とする。

本発明の別の態様では、利用者の端末とネットワークを介して接続可能な店舗のコンピュータが、前記利用者が店舗に置いて欲しい商品のリクエストを受信するステップと、前記リクエストを前記利用者の電子カードのＩＤに関連付けてリクエスト情報として登録するステップと、前記利用者が前記店舗又は前記店舗のグループ店に来店した際に、前記利用者の端末又は電子カードから前記利用者の電子カードのＩＤを読み出すステップと、前記読み出した電子カードのＩＤが前記登録された電子カードのＩＤと一致したときに、前記リクエスト情報を受け付けるステップと、を実行することを特徴とする。

本発明によれば、顧客が実店舗への来店時に商品のリクエストを店舗に対して気軽に上げ、店側の商品の品揃えを効率化するシステムを提供することができる。

本発明の課題のイメージを示す図である。 本発明の実施形態に係る来店時リクエスト受付システムの基本概念を示す図である。 本発明の実施形態に係る来店時リクエスト受付システムの機能構成を示す図である。 本発明の実施形態に係るリクエスト情報及び顧客利用履歴ＤＢ１０６に格納されるデータの例を示す図である。 本発明の実施形態に係るリクエスト受付フローを示す図である。 本発明の実施形態に係るリクエスト処理フローを示す図である。 本発明の実施形態に係るリクエスト画面２００及びリクエスト通知画面２１０の入り例を示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号または符号を付している。また、機能構成の図においては、機能ブロック間の矢印は、データの流れ方向、又は処理の流れ方向を表す。

（基本概念）
図２は、本発明の実施形態に係る来店時リクエスト受付システムの基本概念を示す図である。利用者は、ＰＣ(Personal Computer)やスマートフォンを使って、よく利用する店舗又は利用したい店舗のホームページやサーバ等に、ブラウザや専用アプリからアクセスし、店舗から提供されるリクエスト可能商品一覧から、自分の欲しい商品を選択し、欲しい時間帯、曜日を指定する。時間帯や曜日の指定が必要なければその欄はブランクでよい。また、欲しい商品がリクエスト可能商品一覧になければ、その商品名又は商品ＩＤを入力してもよい。

このとき、電子マネーカード、ポイントカード、クレジットカード等の電子決済が可能な利用者の電子カード（以下、単にカードと呼ぶ）の識別子（ＩＤ）と、リクエスト商品とを紐付けて（関連付けて）登録する。また、カードＩＤとリクエスト可能一覧そのものとを紐付けてもよい。したがって、リクエスト可能一覧は、店舗で取り扱う全商品でなく、利用者ごと店舗ごとに適したものを作成（カスタマイズ）することができる。

利用者が実際にその店舗に来店したときに、登録したカードをレジで読み込ませた際に、店舗側では、そのカードに紐付けられたリクエスト商品を受け付ける。決済機能を有するカードであれば、その場で購入した商品の代金の支払いと同時にリクエスト商品を店側にシステムに送信することができる。受付けられたリクエスト商品は、カードＩＤと共にデータベースに格納される。実際にリクエストされた商品を店に置くかどうかは、リクエストの数、リクエストを上げた利用者の情報（その店の利用頻度、平均利用金額等）等によって店側で判断される。例えば、毎日利用している利用者のリクエストは、たまにしか来ない利用者のリクエストより優先度を上げる等の処理を行なう。店側がリクエストに応え、実際にその商品が入荷した時は、利用者にメールやＳＮＳ（Social Networking Service）等の方法で通知するようにしてもよい。

このようにすることで、利用者は、欲しい商品を店員に直接伝えたり、「店長への手紙」等を書いたりすることなしに、手軽に店側に要望を伝えることができる。また、店側にとっては、実際に来店している利用者からのリクエストなので確実性があり、よりきめ細かな対応等をすることができる。また、商品の需要をタイムリーに見極め、品揃えに反映することにも役立つ。

（機能構成）
図３は、本発明の実施形態に係る来店時リクエスト受付システムの機能構成を示す図である。店舗の利用者は、利用者端末２０を所持しており、上記のサービスを提供する店舗サーバ１０にインターネットを介して接続が可能であるとする。また、利用者端末２０は、カードリーダ／ライタが接続可能であれば、カード媒体からそのカードＩＤを読み取り、店舗サーバ１０に登録することができる。利用者端末２０に「おサイフケータイ」（登録商標）等のカード決済機能を内蔵していてもよいが、その場合、カード２２は不要である。利用者端末２０は、利用者ごとに複数であってもよいが、少なくとも一台は、店舗にも持ち歩けように、スマートフォンやタブレット端末等の携帯型端末であることが望ましい。

利用者は、店舗サーバ１０にアクセスし、リクエスト情報（店舗に対して置いてほしい商品のリクエストを含んだ情報）を登録する。この登録時に作成したリクエスト情報は、図３の符号１００で示すように、店舗サーバ１０のリクエストＤＢ１０４、又は利用者端末２０の内部、又はカード２２の内部の少なくともいずれかに記憶させる。

ただし、店舗サーバ１０にのみに記憶させた場合は、その店舗のチェーン店や系列店等のグループ店でのみ有効となる。一方、利用者端末２０又はカード２２に記憶させた場合は、グループ店以外の店舗でも同様なサービスを提供する店舗であれば作成したリクエスト情報を利用できる可能性がある。すなわち、「リクエストを持ち運ぶ」ことができるイメージである。

また、リクエスト情報は、同じグループ店舗内であれば、希望店舗ごとにリクエスト商品と共に、希望時間帯や希望曜日を登録することができる。例えば、通勤時に立ち寄る店舗、昼休みに立ち寄る店舗、自宅近くの店舗、得意先に行く場合に立ち寄る店舗などに対して、それぞれのリクエストを希望店舗ごとに登録することができる。

利用者は、実際にその店舗又は同じグループの店舗に来店し、レジで購入した別の商品の代金を支払うとき等に登録したカードを提示し、登録したリクエスト情報を店舗サーバ１０に送信する。必ずしも別の商品を購入しなくてもよくカードを提示するだけでもよい。具体的には、店舗内で、店舗端末３０と接続されたカードリーダ／ライタ３１が、利用者端末２０又はカード２２からカード情報を読み取り、店舗端末３０から店舗サーバ１０に決済情報が送信されるとき等に、利用者端末２０又はカード２２に記録されたリクエスト情報を共に送信し、店舗サーバ１０では、受信したリクエスト情報を、リクエストがあった日時の情報と共にデータベースに記憶する。

なお、店舗サーバ１０に登録されたリクエスト情報が記録されている場合は、カードが店舗で提示された時点で、店舗サーバ１０のリクエスト情報を有効化するだけでよい。有効化の手順について詳しくは後述する。

店舗サーバ１０は、単一の店舗又はグループ店舗（以下、チェーン店舗とする）に設置されるサーバである。ここでいう店舗には、コンビニの他、デパ地下、駅の売店、１００円ショップ、ホームセンタ、ディスカウントストア等が含まれる。店舗サーバ１０は、典型的には、図示するように、リクエスト登録手段１０１（登録手段）、取扱商品ＤＢ１０２、リクエスト受付手段１０３（受付手段）、リクエストＤＢ１０４、リクエスト処理手段１０５（処理手段）、顧客利用履歴ＤＢ１０６、他店舗送信手段１０７、チェーン店舗ＤＢ１０８等で構成される。店舗サーバ１０は、単一のサーバで構成してもよいし、複数のサーバで構成してもよい。また、各店舗に設置してもよいし、各店舗を総括する本部に設置してもよい。以下、店舗サーバ１０の各機能ブロックについて順に説明する。

リクエスト登録手段１０１は、利用者端末２０から、リクエスト情報を作成させ、カードＩＤと紐付けて登録し、利用者端末２０又はカード２２又は店舗サーバ１０に記憶させる。このとき、店舗サーバ１０は、取扱商品ＤＢ１０２を読出し、その店舗でリクエスト可能商品一覧を提示する。利用者は、リクエスト可能商品一覧から希望商品を選択するか、一覧に希望商品がない場合は、商品の名称又はＩＤを入力してリクエスト情報を作成する。

なお、リクエスト情報をカード２２等に記憶させる代わりに、リクエストＤＢ１０４に直接格納してもよいが、実際にＤＢに格納されたリクエスト情報が有効になるのは顧客が店舗に来店したときとすることが望ましい。リクエストされる商品は多くの場合少額であるため、実際に店舗に来た利用者を優先するため、また、冷やかしを防止するため、また、利用者に変更する機会を与えるためである。もっとも、実際に店舗を所定期間内に所定回数以上利用したことがある利用者の場合は、リクエスト登録と同時にそのリクエスト情報を有効としてもよい。

リクエスト情報は、予め店舗外で登録しておいてもよいし、携帯型の利用者端末２０の場合は、店舗内で登録してもよい。また、店舗内で、商品のパッケージ又は欠品した商品の商品棚から、商品タグ４０（バーコードやＲＦＩＤ等）を利用者端末２０が備えた読取手段で読み取り、リクエストする商品名（商品ＩＤ）を登録することもできる。店舗内でたまたま見つけた商品を、その店舗ではなく、自宅や会社近くの店舗で購入したい場合に有効である。

リクエスト情報は、図４（ａ）に示すように、ヘッダ部として、リクエストＩＤ、顧客ＩＤ、ステータスを含み、リクエスト内容として、リクエスト対象店舗、リクエスト商品名（ＩＤ）、リクエスト発信日時、リクエスト発信場所、在庫希望曜日、在庫希望時間帯、在庫希望数量、通知希望の有無等が含まれる。ヘッダ部と、リクエスト対象店舗、リクエスト商品名（ＩＤ）以外は必須ではない。ステータスは、リクエスト情報の処理状況を表す値であり、具体的には、「受付未」、「受付済」、「採用」、「不採用」等に分かれる。

「受付未」とは、リクエスト情報が登録はされているが、まだ店舗側にそのリクエストが受付けられていない状態を表し、すなわち、リクエストが「有効化」されていないことを示す。「受付未」の状態では、リクエスト発信日時（リクエストが有効になった日時）、リクエスト発信場所（リクエストを受付けた店舗）は、ブランクである。リクエスト情報が対象店舗に受付けられた場合は、ステータスが「受付済」に変り、そのリクエスト情報が有効となる。

なお、利用者端末２０又はカード２２記憶されたリクエスト情報も、店舗端末３０を介して、店舗側に受け付けられた時点で「受付済」にされ、その時点でリクエストＤＢ１０４に格納される。登録したリクエスト情報を店舗サーバ１０に記憶させている場合は、対象店舗が受け付けた時点で、リクエストＤＢ１０４中でのステータスが「受付未」から「受付済」に変わるだけである。

リクエスト情報が有効化されても実際のそのリクエストがどのように処理されるかは店舗側に委ねられる。店側がリクエストに応じて希望商品を置いた場合には、ステータスが「採用」、リクエストに応じられなかった場合は、ステータスが「不採用」となる。ただし、このようなステータスは必ずしも利用者側には開示されなくともよい。

図３に戻り、リクエスト受付手段１０３は、利用者が店舗に来店したときに、別途購入する商品があるときは、その購入した商品の代金を決済する情報を店舗端末３０から受信し、必要な決済処理を実行後、利用者の利用履歴情報を顧客利用履歴ＤＢ１０６に格納する。利用履歴情報は、図４（ｂ）に示すように、顧客ＩＤ（カードＩＤ）、利用日時、利用店舗、購入商品、購入金額を含み、さらに顧客の利用頻度、平均利用金額等が算出されて含まれることが望ましい。

また、リクエスト受付手段１０３は、上記のカード決済を行う際に、利用者端末２０又はカード２２からカードＩＤを読み出し、読み出したカードのＩＤが登録されたカードのＩＤと一致したときに、未処理のリクエスト情報（有効化されていないリクエスト情報）があれば、そのリクエスト情報を有効化し、リクエストＤＢ１０４に記録する。すなわち、この時点でリクエスト情報が店舗側に受付けられたことなる。なお、リクエスト情報が希望店舗、希望時間帯、希望曜日の項目から構成される場合、リクエスト受付手段１０３がリクエストを受け付けたとき、店舗、時間帯、曜日がマッチしたリクエスト情報のみを有効化してもよい。そのお店に、その曜日に、その時間帯に来店した上で、店にリクエストしているので、確度の高い（あるいは優先度の高い）リクエストであると考えられるからである。

リクエスト受付手段１０３は、さらに利用者の今回の利用履歴情報を顧客利用履歴ＤＢ１０６に記録する。また、利用者がカードを提示した後でも、残高不足などがあった場合は現金で支払うこともでき、その場合でもリクエスト情報の有効化は実行され、利用履歴情報が記録される。なお、ここでは、リクエスト受付手段１０３は、カード決済を処理する決済手段を兼ねているとしているが、決済手段とは別に構成してもよい。

リクエスト処理手段１０５は、リクエストＤＢ１０４に記録され、有効化されたリクエストを解析して処理する機能を備える。店舗では、基本的には、リクエスト件数の多い商品を優先して処理するが、このとき、リクエスト処理手段１０５は、リクエストを上げた利用者の利用履歴を顧客利用履歴ＤＢ１０６から取得し、リクエストの優先順位を決定する。例えば、所定期間内の利用頻度の高い顧客や平均利用金額の大きい顧客のリクエストを他の顧客のリクエストより優先度を上げたり、その他の販売促進情報を顧客に送信したりすることができる。また、顧客がリクエストに対する結果の通知を希望している場合は、その顧客に対して、メールやＳＮＳ等で通知する手段も有していてもよい。

他店舗送信手段１０７は、リクエスト情報に、チェーン店である他の店舗へのリクエストが含まれている場合、そのチェーン店に対して、利用者端末２０又はカード２２に記憶されているリクエスト情報を他店舗サーバ５０に送信したり（店舗サーバ１０を店舗ごとに構築している場合）、リクエスト情報が既にリクエストＤＢ１０４に登録されている場合は、そのリクエスト情報を有効にしたりすることができる。このようにすることで、同じチェーン店であれば、他の店舗に対するリクエストを別の店舗からも有効化することができる。

他店舗がチェーン店でない場合は、現店舗からリクエストを送信することはできないが、利用者端末２０又はカード２２に記憶されたリクエスト情報は、単なるテキストデータなので、利用者端末２０を使って、利用者自身が他のチェーン店舗に送信することが可能である。もちろん、他のチェーン店舗でも利用者からのリクエスト情報を受信可能であるとする。また、他のチェーン店舗のリクエスト情報のフォーマットが異なる場合は、リクエスト情報を利用者が編集してもよいし、また、異なるチェーン店間のリクエスト情報をフォーマット変換し、送信するような専用アプリをスマートフォン上に提供してもよい。このようにすることで、リクエスト情報のポータビリティが高まる。

他のチェーン店舗におけるリクエストの処理方法は、店舗によって異なることがある。例えば、他のチェーン店舗のリクエスト処理手段１０５は、他店舗グループから移ってきた利用者に対しては、そのリクエストの優先順位を上げる、割引クーポンを提供する等、以降客に対して他のチェーン店と差別化する処理を行うことができる。利用者からすれば、リクエストを上げても応えてくれないチェーン店があれば、他のチェーン店に乗り換えることも選択肢となる。このようにすることで、本システムの仕組みをチェーン店や系列店等の店舗グループの垣根を越えて活用することができる。

上記の本システムの機能構成は、あくまで一例であり、一つの機能ブロック（データベース及び機能処理部）を分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＳＳＤ(Solid State Drive)、ハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。

（処理フロー）
図５は、本発明の実施形態に係るリクエスト受付フローを示す図である。また、図６は、本発明の実施形態に係るリクエスト処理フローを示す図である。以下、各処理の詳細について説明する。なお、図５、図６の処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。

図５のリクエスト受付フローは、店舗端末３０（以下、ここでは単に端末と呼ぶ）と店舗サーバ１０（以下、単にサーバと呼ぶ）のリクエスト受付手段１０３が協業して行う処理である。以下では、利用者が他の商品を購入時に店舗側にリクエストを上げる場合について説明する。

端末側では、まずステップＳ１０において、顧客から決済用に提示されたカードのカード情報をカードリーダ／ライタ２１（以下、単にリーダと呼ぶ）によって使って読み出す。端末又は非接触型ＩＣカードの場合は、リーダにタッチするだけでよい。そして、読み取ったカード情報が正常に認証されれば（ステップＳ１１：Ｙ）、ステップＳ１２に移るが、認証がＮＧの場合、エラーを表示して処理を終了する。この場合は、顧客は現金で支払うか他のカードを提示することになる。

ステップＳ１２では、サーバ側に購入情報を送信する。購入情報には、カードＩＤ、購入日時、購入金額、店舗ＩＤが含まれるが、購入した個々の商品名、商品単価、数量等の情報を含むことが望ましい。端末側では、さらにステップＳ１３において、顧客から店舗へのリクエストがあるかどうかをチェックする。具体的には、端末又はカード内に未処理（有効化されていない）のリクエスト情報が記憶されているかどうかをチェックする。そして有効化されていないリクエストが記憶されていれば、ステップＳ１４において、サーバ側にそのリクエスト情報を送信する。

サーバ側では、ステップＳ２０で決済処理を行った後、ステップＳ２１において、リクエスト情報を受信しているかどうかをチェックする。リクエスト情報を受信していなければ、そのまま処理を終了するが、リクエスト情報を受信していれば、ステップＳ２２に移り、受信したリクエスト情報が自店舗へのリクエストかどうかを判断する。自店舗へのリクエストであれば、ステップＳ２３において、そのリクエスト情報を自店舗分として、リクエストＤＢ１０４に記録する。ただし、同じリクエストＩＤが既にリクエストＤＢ１０４に記録されていて、有効化されていない場合は、そのリクエスト情報を有効化する。

ステップＳ２２において、自店舗へのリクエストでないと判断した場合は、ステップＳ２４に移り、さらにリクエスト先が自店舗のチェーン店であるかどうかをチェックする。このとき、リクエスト情報に含まれたリクエスト対象店舗のＩＤがチェーン店舗ＤＢ１０８に格納されている店舗ＩＤと一致するかどうかで判断する。チェーン店であれば、ステップＳ２５において、チェーン店へのリクエストとして、リクエストＤＢ１０４に記録して有効化する。したがって、リクエスト先（リクエスト対象店舗）では何もする必要はない。

ステップＳ２４において、リクエスト対象店舗がチェーン店でもないと判断した場合は、そのまま何もせずに処理を終了してもよいが、その他店舗と競合関係になく、何らかの提携がある場合は、ステップＳ２６において、受信したリクエスト情報をその他店舗のサーバ等に送信（転送）するようにしてもよい。また、その他店舗と競合し、転送ができない場合は、そのことを店舗端末等に表示し、利用者にその旨を通知するようにしてもよい。この通知を受けた利用者は、店を出た後、自らの端末の専用アプリを使って、その他店舗にリクエスト情報を送信するようにしてもよい。送信ができない場合は、その他店舗に後日出向いたときに、記憶したリクエスト情報をカードリーダ等から読み取らせるようにしてもよい。

このようにすることで、ある系列の店舗で発見した商品を、別の系列の店舗に対するリクエスト情報に含ませることが可能となる。例えば、既に述べたように、たまたま立ち寄ったコンビニで見つけた商品を自宅近くで購入したいが、自宅近くには同じ系列のコンビニがないような場合等に有効である。

図６のリクエスト処理フローは、店舗サーバ１０のリクエスト処理手段１０５が行う処理である。リクエスト処理手段１０５は、まずステップＳ３０において、定期的に又は指示があるごとにリクエストＤＢ１０４のリクエスト情報を読み出す。そしてステップＳ３１において、未処理のリクエスト情報があるかどうかをチェックする。未処理のリクエスト情報がなければ、ステップＳ３０に戻り、リクエストＤＢ１０４が更新されるのを待つ。

リクエスト処理手段１０５は、次にステップＳ３２において、未処理のリクエストが自店舗に対するものがどうかをチェックする。自店舗に対するリクエストであると判断した場合は、ステップＳ３３において、顧客利用履歴ＤＢ１０６を読出し、その利用者の利用履歴を抽出する。そして、ステップＳ３４において、その顧客のリクエスト情報の優先付を行う。

ステップＳ３４の優先付は、例えば、利用頻度の高い利用者のリクエストの優先度を高く設定する。つまり、より多くの買物をする利用者のリクエストの優先度を高くし、たまにしか来ない利用者のリクエストの優先度は低くする。また、利用頻度と平均購入額を所定の比率で掛け合わせて、優先度のパラメータとしてもよい。あるいは、新規顧客や他店から転送を受けてきた利用者の優先度を高く設定するようにしてもよい。また、口コミが広がりやすい女性客からのリクエストの優先度を男性客よりも高くしてもよい。

リクエスト処理手段１０５は、優先付の処理が終わると、ステップＳ３４において、リクエスト情報を優先度の順に並べたリストを店側に任意の方法で提示するようにする（ステップＳ３５）。店の商品仕入担当者は、このリストを参考に商品の品揃えを決定することができる。また、店側がリクエストに応え、その商品を店頭に置いたときは、リクエストを上げた利用者に対してそのことを通知する手段を備えるようにしてもよい。

一方、ステップＳ３２において、自店舗へのリクエストではないと判断された場合は、ステップＳ３６に移り、リクエスト情報に含まれたリクエスト対象店舗のＩＤから、チェーン店へのリクエストであるかどうかをチェックする。チェーン店でなければ、図６では、なにもせずに処理を終了することにしているが、チェーン店以外へのリクエストが含まれている旨を利用者に通知するようにしてもよい。

ステップＳ３６で対象店舗がチェーン店であると判断した場合は、ステップＳ３７において、チェーン店舗ＤＢ１０８を読出し、チェーン店の連絡先を抽出し、ステップＳ３８で、該当チェーン店に処理すべきリクエストを送信する。このようにすることで、チェーン店内でのリクエストを共有することもできる。

（画面例）
図７は、本発明の実施形態に係るリクエスト登録画面及びリクエスト通知画面を示す図である。リクエスト登録画面２００は、リクエスト登録手段１０１によって生成される画面であり、リクエスト通知画面２１０は、顧客が通知を希望している場合は、リクエスト処理手段１０５によって生成される画面である。

図示するように、図７のリクエスト登録画面２００は、個々の店舗ではなく、チェーン店の本部から提供されたものであり、図２で示した場合と異なり、希望店舗（リクエスト対象店舗）を指定する欄が追加されている。したがって、複数のチェーン店の店舗に対して、一つの登録画面からリクエスト情報を作成することが可能となる。複数の店舗に対するリクエストを作成した場合は、対象となる店舗ごとにリクエスト情報が作成される。

来店した店舗においても、リクエスト登録画面２００を利用者端末２０から呼び出すことができ、そのリクエスト情報が有効化される前であれば、既に登録したリクエスト情報をいつでも変更、編集することができる手段を設けることが望ましい。また、いったん有効化されたリクエスト情報を取り消すような手段を設けてもよい。

リクエスト通知画面２１０は、リクエストに店側が応じた場合の通知画面を示している。この画面は、店舗からのメールやＳＮＳでの通知する場合を想定しているが、前述のリクエスト登録画面２００に、リクエストのステータスとして、利用者からのコメントや店舗からの返答等を含ませるようにしてもよい。

また、リクエストの「採用率」等を別途表示するようにしてもよい。採用率が高い店舗は他店より利用者に対してアピールができる、なお、採用されたリクエスト情報、採用されなかったリクエスト情報は、所定の期間が経過後、リクエストＤＢ１０４からは消去されるものとする。

（実施形態の効果）
本発明の実施形態によれば、利用者の端末とネットワークを介して接続可能な店舗サーバ１０が、利用者が店舗に置いて欲しい商品のリクエストを、利用者のカードＩＤに関連付けてリクエスト情報として登録する。そして、利用者がその店舗又はその店舗のグループ店に来店し別の商品を購入する際等に、利用者のカードＩＤを読み出し、読み出したカードＩＤが登録されたカードＩＤと一致したときに、リクエスト情報を受け付ける。このため、利用者が店舗に置いて欲しい商品のリクエスト情報を予め登録しておき、実際に店舗に来店したときに、登録したリクエストを店側に伝えることができる。リクエスト情報には、希望店舗、希望時間帯、希望曜日の情報が含まれるので、店舗ごとに別々の商品を時間帯や曜日と共に指定できる。すなわち、電子マネーカード等で、商品の購入と店舗に対するリクエストとを同時に行うことができる。

また、来店する店舗はグループ店であればどこでもよく、例えば、会社の近くの店舗で、自宅近くの店舗へのリクエストを上げることが可能である。また、店舗サーバ１０以外にも利用者端末２０やカード２２内部にリクエスト情報を記憶させておけば、「リクエストを持ち歩く」ことができ、グループ店以外の店舗でもそのリクエストが利用できる可能性が広がる。

また、リクエスト情報を登録する際には、リクエスト可能な商品の一覧が提示されるので、希望の商品が一覧にあればそれを選択するだけでよい。もちろん、希望の商品が一覧になければ、商品名やＩＤを手入力することができる。また、登録時に表示される一覧を利用者ごとにカスタマイズすることも可能である。また、受付けられたリクエスト情報は、利用者の来店頻度や利用金額等に応じて優先付がなされるので、店舗ごとにリクエストの処理方法を決定することができる。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。なお、上記の実施形態では、本発明を物の発明として来店時リクエスト受付システムで説明したが、本発明は、方法の発明（来店時リクエスト受付方法）としても捉えることもできる。

１０ 店舗サーバ
２０ 利用者端末
２１ 利用者端末のカードリーダ／ライタ
２２ 電子カード
３０ 店舗端末
３１ 店舗端末のカードリーダ／ライタ
４０ 商品タグ
５０ 他店舗サーバ
１００ リクエスト情報
１０１ リクエスト登録手段
１０２ 取扱商品ＤＢ
１０３ リクエスト受付手段
１０４ リクエストＤＢ
１０５ リクエスト処理手段
１０６ 顧客利用履歴ＤＢ
１０７ 他店舗送信手段
１０８ チェーン店舗ＤＢ
２００ リクエスト登録画面
２１０ リクエスト通知画面

Claims (6)

1. 利用者の端末とネットワークを介して接続可能な店舗サーバが、
   前記利用者が店舗に置いて欲しい商品のリクエストを受信し、前記利用者の電子カードのＩＤに関連付けてリクエスト情報として登録する登録手段と、
   前記利用者が前記店舗又は前記店舗のグループ店に来店した際に、前記利用者の端末又は電子カードから前記利用者の電子カードのＩＤを読み出し、前記読み出した電子カードのＩＤが前記登録された電子カードのＩＤと一致したときに、前記リクエスト情報を受け付ける受付手段と、
   を備えることを特徴とする来店時リクエスト受付システム。
2. 前記リクエスト情報は、希望店舗、希望時間帯、及び希望曜日の情報を含むことを特徴とする請求項１に記載の来店時リクエスト受付システム。
3. 前記リクエスト情報は、前記利用者の電子カード、前記利用者の端末、前記店舗サーバの少なくともいずれかに記憶され、前記利用者が来店し、前記受付手段が前記リクエスト情報を受付けた際に有効化されることを特徴とする請求項２に記載の来店時リクエスト受付システム。
4. 前記登録手段は、リクエスト可能な商品の一覧を提示し、前記利用者は前記一覧から希望する商品を指定するか、又は前記一覧に希望する商品がない場合は、希望する商品の名称又はＩＤを入力させる手段を備えることを特徴とする請求項１乃至３のいずれか一項に記載の来店時リクエスト受付システム。
5. 前記店舗サーバは、前記受付手段が受付けたリクエスト情報を解析し、前記利用者の前記店舗における利用頻度及び／又は平均利用金額に応じて、前記リクエスト情報の優先付の処理を行う処理手段を更に備えることを特徴とする請求項１乃至４のいずれか一項に記載の来店時リクエスト受付システム。
6. 利用者の端末とネットワークを介して接続可能な店舗のコンピュータが、
   前記利用者が店舗に置いて欲しい商品のリクエストを受信するステップと、
   前記リクエストを前記利用者の電子カードのＩＤに関連付けてリクエスト情報として登録するステップと、
   前記利用者が前記店舗又は前記店舗のグループ店に来店した際に、前記利用者の端末又は電子カードから前記利用者の電子カードのＩＤを読み出すステップと、
   前記読み出した電子カードのＩＤが前記登録された電子カードのＩＤと一致したときに、前記リクエスト情報を受け付けるステップと、
   を実行することを特徴とする来店時リクエスト受付方法。