JP2022108352A - ユーザ行動促進支援方法、システム及びサーバ - Google Patents

Abstract

【課題】 スタンプラリーに対するユーザの満足度を高めることができるユーザ行動促進支援システム等を提供する。【解決手段】 ユーザ行動促進支援システムのサーバは、スタンプシートに含まれる対象候補となる１以上のスポット等の組み合わせを、ユーザ情報及びユーザの行動記録に基づいて抽出してユーザ端末のユーザごとに提示させる。ユーザ端末は、サーバから１以上のスポット等の組み合わせが提示されたときに当該組み合わせの中から１以上のスポット等の選択を受け付けてサーバに送信する。サーバは、選択された１以上のスポット等を含むスタンプシートのスタンプシート情報をデータベースに記憶させる。ユーザ端末は、選択されたスポット等における行動をユーザが行ったときに行動記録をサーバへ送信する。サーバは、行動記録及びスタンプシート情報に基づいてユーザ端末のユーザに特典付与を行う。【選択図】 図５Ａ

Description

本開示は、広くユーザ行動促進を支援するシステムにおける方法等に関し、より具体的には、ユーザ（利用者）自身の選択に応じたスタンプラリー対象（ラリー対象（店舗、エリア等））での行動を促進するユーザ行動促進支援システムにおける方法等に関する。

従来、ユーザ（利用者）の利便性あるいは満足度等を向上させる目的で、ユーザ（利用者）の行動を促進するためのシステムが提供されてきた。その代表的なものにスタンプラリーシステムがある。

たとえば、スタンプラリーユーザの属性、および、電子タグの読取り履歴に基づき、ユーザの趣味・嗜好に沿ったスタンプラリーのルートを動的に設定することによって、ユーザの満足度を向上させるスタンプラリーシステムが提案されている（特許文献１）。

すわなち、特許文献１には、複数の電子タグ、携帯電話機およびサーバ装置から構成され、電子的なスタンプを用いてスタンプラリーを実施するスタンプラリーシステムであって、前記サーバ装置は、前記携帯電話機のユーザ情報を登録するユーザ登録部と、前記ユーザ情報に基づいて、前記各電子タグが設置された複数の場所を特定の順序で連結する少なくとも一つのスタンプラリールートを計算するルート計算部と、前記計算されたスタンプラリールートを前記携帯電話機に出力するサーバ側通信部と、を備え、前記携帯電話機は、ユーザからの入力を受け付ける入力部と、前記サーバ装置から入力されたスタンプラリールートを表示する表示部と、前記電子タグに記録されているタグ情報を読み取る読み取り部と、ユーザ情報および前記タグ情報を前記サーバ装置へ出力する端末側通信部と、を備え、前記ルート計算部は、前記携帯電話機から入力されたタグ情報が、前記スタンプラリールートから外れた場合、前記ユーザ情報および前記スタンプラリールートから外れた場所のタグ情報に基づいて、再度スタンプラリールートを計算し、前記サーバ側通信部は、再度計算したスタンプラリールートを前記携帯電話機に出力することを特徴とするスタンプラリーシステムが開示されている。

また、２つ以上の目的地を要する利用者に対して連続的かつ効率的にそれらの目的地に関する情報を提供する技術も提案されている（特許文献２）。

すなわち、特許文献２には、ネットワークを介して利用者が用いる移動体通信端末である利用者端末との送受信を可能とする通信手段と、前記利用者端末の表示画面に前記利用者の移動の目的地となり得る目的地情報に関する情報を表示させる表示情報出力手段と、前記通信手段で得られた情報より前記利用者の現在地を特定して利用者位置情報を抽出する利用者位置抽出手段と、少なくとも目的地に対する前記利用者の要望に基づいて複数のカテゴリに選別された前記目的地情報及び前記利用者位置抽出手段によって特定された前記利用者の経時的な所在地を示す利用者履歴情報が蓄積されたデータベースと、前記通信手段によって前記利用者端末から送信された目的地に関する要望情報に基づき前記データベースに蓄積された目的地情報を参照して前記利用者の基点及び複数の目的地を設定し、前記利用者端末へ伝えるための目的地設定手段と、前記利用者が基点及び／又は目的地に位置しているか否かを判定し、前記利用者が基点及び／又は目的地に位置している場合には前記目的地設定手段に新たな目的地の設定を指示する判定手段と、係る判定手段及び前記目的地設定手段によって得られた情報に基づき、前記利用者履歴情報を更新する更新手段とを有してなることを特徴とする目的地情報提供サーバが開示されている。

特開２０１１－０５３９５６号公報 特開２００４－１８５２３４号公報

上記のように、特許文献１に記載された技術によれば、携帯電話機から入力されたタグ情報が、スタンプラリールートから外れた場合に、ユーザ情報およびスタンプラリールートから外れた場所のタグ情報に基づいて、再度スタンプラリールートを計算し、携帯電話機に出力する。しかしながら、特許文献１に記載された技術は、スタンプラリールート（またはスタンプシート）の生成自体をユーザ自身が選択することはできない。

また、特許文献２に記載された技術によれば、スタンプシートの生成に際してユーザ自身が目的地を選択可能である。しかしながら、ユーザが選択可能な目的地の候補は、利用者の現在地に基づいて列挙される。そのため、目的地（対象スポット／対象イベント）の候補の提示に改良の余地がある。

そこで、本開示の一実施形態にかかるユーザ行動促進支援システムの実行方法は、１以上のサーバと、前記１以上のサーバの少なくともいずれかのサーバに接続可能に構成された複数のユーザ端末とを有するユーザ行動促進支援システム上で実行される方法であって、前記サーバに、前記複数のユーザ端末のユーザに関するユーザ情報と、１以上のスポット及び／又はイベントに関するスタンプラリー対象情報と、前記スポット及び／又はイベントにおける前記ユーザの行動記録とをデータベースに記憶させ、スタンプシートに含まれる対象候補となる前記１以上のスポット及び／又はイベントを、前記ユーザ情報及び／又は前記行動記録に基づいて前記ユーザ端末のユーザごとに提示させ、前記ユーザ端末に、前記サーバから前記１以上のスポット及び／又はイベントが提示された場合に、前記１以上のスポット及び／又はイベントの中から１以上のスポット及び／又はイベントの選択を受け付けさせて前記サーバに送信させ、前記サーバに、前記選択された１以上のスポット及び／又はイベントを含むスタンプシートのスタンプシート情報を前記データベースに記憶させ、前記ユーザ端末に、前記選択されたスポット及び／又はイベントにおける行動を前記ユーザが行った場合にその行動記録を前記サーバへ送信させ、前記サーバに、前記行動記録及び前記スタンプシート情報に基づいて前記ユーザ端末のユーザに特典付与を行わせる、ことを特徴とする。

本開示によれば、ユーザ端末の利用者が選択したスポット及び／またはイベントを対象（対象スポット／対象イベント）として含むスタンプシートを作成する。これにより、ユーザは自身が選択したスポット及び／またはイベントを含むスタンプラリーに参加することができるため、スタンプラリーに対するユーザの参加及び完遂のモチベーションを高めることが可能となる。また、ユーザが選択可能なスポット及び／またはイベントは、ユーザ情報に基づいてユーザ毎に提示されてよい。従って、ユーザの属性及び行動記録に合わせた対象を、ユーザ自身の選択に応じて含むスタンプシートを用いたスタンプラリーが可能となる。よって、スタンプラリーに対するユーザの満足度を高めることができる。

また、前記スポットが店舗を含む場合、前記ユーザの行動は、前記ユーザによる前記店舗への訪問が含まれてもよい。これにより、ユーザの選択（好み）に合致した店舗への訪問を促すことで販売促進等を図ることが可能となる。

また、前記スポットが店舗を含む場合、前記ユーザの行動は、前記ユーザによる前記店舗における商品またはサービスの決済行動が含まれてもよい。これにより、ユーザの選択（好み）に合致した店舗での消費行動等を促すことが可能となる。

また、前記店舗は、ウェブ上の仮想店舗が含まれてもよい。これにより、ユーザの選択（好み）に合致した仮想店舗への訪問等を促すことが可能となる。

また、前記スポットが地域あるいはエリア（無償／有償の観光地等）を含む場合、前記ユーザの行動は、前記ユーザによる前記地域あるいはエリアへの訪問が含まれてもよい。これにより、ユーザの選択（好み）に合致する地域またはエリアへの訪問を促すことで販売促進等を図ることが可能となる。

また、前記スポットが地域あるいはエリアを含む場合、前記ユーザの行動は、前記ユーザによる前記地域あるいはエリアにおける所定の動作が含まれてもよい。これにより、ユーザの選択（好み）に合致する地域またはエリアでの動作を促すことで販売促進等を図ることが可能となる。

また、前記ユーザの前記行動の有無は、前記ユーザ端末の位置情報に基づいて判断されてもよい。これにより、位置情報を利用したスタンプラリーが可能となり、ユーザ者の移動を促すことが可能となる。

本開示の一実施形態にかかる方法等によれば、ユーザの属性及び行動履歴に基づいて提示されるラリー対象（対象スポット／対象イベント）をユーザ自身が選択することができることにより、自身が選択したラリー対象を含むスタンプラリーを作成することができるためユーザがスタンプラリーに参加する／スタンプラリーを完遂するモチベーションが高められ、利用者の行動が促進されるという効果を奏する。

本開示の一実施形態にかかるユーザ行動促進支援システムの全体構成例を説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおける支援サーバの機能ブロック構成を説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおける店舗端末の機能ブロック構成を説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおける情報処理装置（ユーザ端末）の外観構成例を説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおける情報処理装置（ユーザ端末）を構成するハードウェアの機能ブロック構成を説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおける処理動作フローを説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおける処理動作フローを説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおける店舗情報等のエントリー処理例について説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるスタンプラリーを実施するスタンプラリー処理例について説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるユーザ端末の表示例を説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるユーザ端末の表示例を説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるユーザ端末の表示例を説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるユーザ端末の表示例を示す説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるユーザ端末の表示例を説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるユーザ端末の表示例を説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるスタンプ付与条件を一般化した場合の処理動作フローについて説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるスタンプ付与条件として店舗またはエリアに設置されているオブジェの撮影を用いる場合の処理動作フローについて説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるスタンプ付与条件として位置情報を用いる場合の処理動作フローについて説明する説明図である。 本開示の一実施形態にかかるユーザ行動促進支援システムにおけるスタンプを付与するスタンプ付与処理フローについて説明する説明図である。

以下、本開示の一実施形態にかかるユーザ行動促進支援システム等について、図面を参照しながら詳細に説明する。なお、以下の説明では、ユーザ行動促進支援システムの具体例として、スタンプシートを用いるスタンプラリー支援システムを取り上げるが、個々の説明は例示であり、本開示が出願時において一般に知られるスタンプラリーの用途や運用方法等に制限されるものではない。

図１に、本開示の一実施形態にかかるユーザ行動促進支援システムの全体構成例を示す。

図１に示されるように、ユーザ行動促進支援システム１０は、その一実施形態における構成として、支援サーバ（群）１１と、店舗端末（群）１２と、ユーザ（利用者）が使用する各種情報処理装置（図において、例示的に、スマートフォンあるいはタブレット等の携帯情報端末あるいは情報処理端末１３ａ～１３ｃ、携帯電話１４、ＰＣ１５が示されている。以下、総称して「ユーザ端末」とも言うこともある）とで構成されている。店舗端末（群）１２は、店舗側が使用する情報処理装置（図において、例示的に、ＰＣ１２１が示されている。以下、総称して「店舗端末」とも言うこともある）と、複数の店舗に関する各種情報を管理する店舗サーバ１２２とを有する。店舗端末１２１は、図示しない複数の端末が採用されてもよく、店舗サーバ１２２は、１台のサーバであっても、複数のサーバ（群）であってもよい。また、店舗サーバ（群）１２２は、省略することもできる。ユーザ行動促進支援システム１０における支援サーバ１１、各種端末間は、図１に示されるように専用回線やインターネット等の公衆回線（有線の回線として、１６ａ～１６ｃ）で相互に通信可能に接続されている。また、回線は有線であっても無線であってもよく、無線の場合、情報処理端末１３ａ～１３ｃならびに携帯電話１４は、無線で図示しない基地局やアクセスポイント等を介してインターネット１８に乗り入れ、更に回線１７を介して支援サーバ１１と相互に通信可能に接続される。なお、本開示はユーザ行動促進支援システム１０の例示に限定されるものでなく、実現可能な範囲で任意の情報処理装置が追加されたり省略されたりしてもよく、後述の各情報処理装置の機能や処理の少なくとも一部を他の情報処理装置が実現してもよい。

ここで、アクセスポイントとは、ＰＣやスマートフォンなどの無線端末を相互に接続したり、他のネットワークに接続させたりするための無線機である。典型的には、ＯＳＩ参照モデルにおける第１層（物理層）及び第２層（データリンク層）の通信プロトコルで作動するデバイスである。

なお、本願の出願時点での携帯電話やスマートフォン、タブレット等の携帯情報端末あるいは情報処理端末は、パーソナルコンピュータ（ＰＣ）と同等の処理能力（通信処理速度や画像処理能力等）を備えているものも多く、小型のコンピュータとも言うべきものである。

また、本開示の実施に必要なプログラムあるいはソフトウェアは、通常、ＰＣや携帯情報端末の記憶部におけるＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等にインストールあるいは記憶され、プログラムあるいはソフトウェアの実行時には、必要に応じて記憶部内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵにおいて演算実行される。

あるいは、ブラウザベースのコンピュータあるいは携帯情報端末を採用することもできる。この場合は、必要に応じて他のサーバやコンピュータから端末にプログラムが配信され、端末上のブラウザでこれを実行するという構成になる。

また、支援サーバ１１のハードウェア構成も、基本的にはＰＣを採用することができる（念のため、図２Ａを参照して後述する）。なお、本開示はこれに限定されるものではないが、支援サーバ１１は、必要に応じてそのハードウェアスペックを上げるにあたり、複数のＰＣ（一例として、数十台～数万台）を並列的に作動させることによって大規模データの処理に適した構成をとることもできる。

図２Ａに、本開示の一実施形態にかかるユーザ行動促進支援システムにおける支援サーバの機能ブロック図を示す。例示的に、支援サーバの動作は、以下に説明するハードウェアの個々の動作、及びソフトウェアとこれらハードウェアとの連携動作によって実現されている。

図２Ａにおいて、ハードウェアブロック全体としての支援サーバ２００は、大別すると、各種比較・演算処理を行うためのＣＰＵ２０１と、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の記憶部２０２と、キーボードやポインティングデバイス等の入力部２０３と、ディスプレイやスピーカ等の出力部２０４と、各種信号制御のための制御部２０５と、通信（インタフェース）部２０６（無線、有線を問わない）と、時刻等を計時するための計時部２０７と、電源部２０８とからなる。

これらのモジュールは必要に応じて適宜通信バスや給電線によって接続されている。図２Ａにおいては、説明の便宜上、通信バスや給電線が適宜区分されたひとまとめの結線２４９として表す。

また、本開示の実施に必要な支援サーバ２００上で実行されるプログラムあるいはソフトウェアは、通常、記憶部２０２を構成するＨＤＤ、ＳＳＤ、フラッシュメモリ等にインストールまたは記憶され、プログラムあるいはソフトウェアの実行時には、必要に応じて記憶部２０２内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵ２０１において演算実行される。

なお、演算実行は必ずしもＣＰＵ２０１等の中央処理部で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。

一実施形態において、記憶部２０２に含まれるデータベース（以下「スタンプラリーデータベース」ともいう）は、各ユーザ端末のユーザに関するユーザ情報と、ラリー対象としてのスポット及び／またはイベントに関するラリー対象情報と、ラリー対象としてのスポット及び／またはイベントにおけるユーザの行動記録とを記憶している。

ここで、一実施形態として、ユーザ情報には、次のようなデータ項目を採用することができる。なお、表１に記載の情報は例示であり、ユーザ情報はユーザに対応付けられた情報であればどのようなものであってもよい。一例として、過去のラリーの参加履歴や進捗であってもよい。

また、一実施形態として、ラリー対象情報には、次のようなデータ項目を採用することができる。なお、表２に記載の情報は例示であり、ラリー対象情報はラリー対象に対応付けられた情報であればどのようなものを含んでもよい。

また、一実施形態として、ユーザの行動記録には、次のようなデータ項目を採用することができる。なお、表３に記載の情報は例示であり、ユーザの行動記録はユーザの行動に関する情報であればどのようなものを含んでもよい。

上記行動記録は、ユーザごとに、商品やサービスの購入（あるいは、訪問場所での行動）ごとに管理されてよい。購入商品や受けたサービス、あるいは訪問場所での具体的な行動は、別途管理される図示しない種別ＩＤ等によって管理することができる。

なお、ラリー対象としてのスポットは、実際の店舗エリアのみならず、ウェブ上の仮想店舗や仮想エリアとすることもできる。また、店舗は、商業施設内の個別店舗または商業施設そのもののいずれを示すものであってもよい。或いは、当該スポットは、地域またはエリアとしてもよい。

図２Ｂに、本開示の一実施形態にかかるユーザ行動促進支援システムにおける店舗端末の機能ブロック図を示す。例示的に、店舗端末の動作は、以下に説明するハードウェアの個々の動作、及びソフトウェアとこれらハードウェアとの連携動作によって実現されている。

図２Ｂにおいて、ハードウェアブロック全体としての店舗端末２５０は、大別すると、ＣＰＵ２５１と、記憶部２５２と、入力部２５３と、出力部２５４と、制御部２５５と、通信（インタフェース）部２５６と、計時部２５７と、電源部２５８とからなる。これらの各モジュールは、基本的に図２Ａの支援サーバ２００の各モジュールと同様である。但し、店舗端末２５０は、ユーザ端末との間での決済機能を有してもよい。決済機能は決済を進行するための機能であればどのようなものであってもよい。例えば、ユーザ端末に表示させた画像情報（二次元コードまたはバーコード）を店舗端末２５０の読取り装置（入力部２５３の一部）により読取り（いわゆるユーザ提示型：ＣＰＭ（Customer Presented Mode））等を行うことができる。その場合、店舗端末２５０は、決済情報を店舗サーバに送信する。そして、本開示の一実施形態においては、この決済情報をユーザへの特典付与の契機とすることができる（後述）。なお、当然に決済機能はＣＰＭに限られず、ＭＰＭ（Merchant Presented Mode）や他の決済方法であってもよく、決済処理を他の情報処理装置に依頼する機能であってもよい。決済機能が、決済処理を他の情報処理装置に依頼する機能である場合、当該決済機能は決済依頼の結果（決済完了の可否）を取得する機能であってもよい。

これらのモジュールは必要に応じて適宜通信バスや給電線によって接続されている。図２Ｂにおいては、説明の便宜上、通信バスや給電線が適宜区分されたひとまとめの結線２９９として表す。

店舗サーバ（例えば図１の１２２）の基本的な構成は、支援サーバ（図２Ａ）と同様であるため、図示を省略する。なお、店舗サーバの記憶部（図２Ａの２０２に相当）には、各店舗での決済情報等を記憶するデータベース（店舗データベース）が設けられてもよい。

ここで、一実施形態として、決済情報には、次のようなデータ項目を採用することができる。当然に、表４は例示であり、決済情報にはユーザに対応づけられた決済に関する情報であればどのようなものであってもよく、決済に基づいて付与されるポイントなどが含まれてもよい。

図３に、本開示の一実施形態にかかるユーザ行動促進支援システムにおけるユーザ端末の一例としてのスマートフォンまたはタブレット端末３２（１３ａ～１３ｃ）の外観構成を示す。図３において、ユーザ端末（スマートフォンまたはタブレット端末）３２は、筐体部３２１とディスプレイ３２２と筐体３２１の下部中央部に設けられたハードウェアボタン３２３とからなる。ディスプレイ３２２は典型的には液晶ディスプレイ（ＬＣＤ）等で構成され、文字や静止画像や動画など様々な情報を表示することができる。また、ディスプレイ３２２にメニューボタンやソフトウェアキーボードを表示させ、これを指あるいはタッチペン（不図示）等で触れることによりタブレット端末３２への指示（コマンド）とすることができる。この点で上記ハードウェアボタン３２３は必須の構成要素ではないが、本開示の説明の便宜上、一定の機能を担うボタンとして実装されている。もちろん、これらハードウェアボタン３２３を、ディスプレイ３２２の一部に表示させたメニューボタンで代替させることも可能である。

また、ディスプレイ３２２には、マルチタッチ入力パネルが含まれており、タッチ入力パネル上でのタッチ入力位置座標が入力デバイスインタフェース（不図示）を介してタブレット端末３２の処理系（ＣＰＵ）へ送信され処理される。そして、このマルチタッチ入力パネルは、パネルに対する複数の接触点を同時に感知することができるよう構成されている。この検出（センサ）については様々な方法で実現することができ、必ずしも接触センサに限られず、例えば、光学式のセンサを利用してパネルに対する指示点を抽出することも可能である。さらに、センサには、接触式のセンサや光学式のセンサのほか、人の肌の接触を感知する静電容量方式のセンサを用いることも可能である。

また、図３には図示しないが、ユーザ端末３２は、マイクやスピーカを備えることもできる。この場合にはマイクより拾ったユーザの声などを判別して入力コマンドとすることも可能である。さらに、図３には現れていないが、ユーザ端末３２の背面等にＣＭＯＳ等のカメラデバイスを実装させることもできる。

図４に、本開示の一実施形態にかかるユーザ端末３２（１３ａ～１３ｃ）を構成するハードウェアの機能ブロック図を例示する。ユーザ端末３２の動作は、以下に説明するハードウェアの個々の動作、及びソフトウェアとこれらハードウェアとの連携動作によって実現されている。

図４において、ハードウェアブロック全体としてのユーザ端末４００は、大別すると、図３におけるハードウェアボタン３２３、ディスプレイ３２２に設けられたマルチタッチ入力パネル、マイク等で構成される入力部４０１と、プログラムやデータ等を記憶するためのハードディスク、ＲＡＭ及び／又はＲＯＭ等で構成される記憶部４０２と、プログラムによって様々な数値計算や論理演算を行うＣＰＵによって構成される中央処理部４０３と、ディスプレイ３２２等で構成される表示部４０４と、チップや電気系統等の制御を行うための制御部４０５と、インターネットにアクセスするためのスロットや光通信を行うためのポート、及び通信インタフェースから構成される通信インタフェース部４０６と、スピーカやバイブレーション、赤外線プロジェクター等の出力部４０７と、時刻等を計時するための計時部４０８と、ＣＭＯＳ等のイメージセンサや赤外線センサ、慣性センサ等からなるセンサ部４０９と、装置内の各モジュールに電源を供給するための電源部４１０とからなり、これらのモジュールは必要に応じて適宜通信バスや給電線によって接続されている。図４においては、説明の便宜上、通信バスや給電線が適宜区分されたひとまとめの結線４９９として表す。

なお、センサ部４０９には、ユーザ端末４００（１３ａ～１３ｃ）の位置を特定するためのＧＰＳセンサモジュールを含めてもよい。また、センサ部４０９を構成するＣＭＯＳ等のイメージセンサや赤外線センサ等によって検知された信号は、入力部４０１において入力情報として処理することができる。

また、本開示の実施に必要なタブレット端末４００上で実行されるプログラムあるいはソフトウェアは、通常、記憶部４０２を構成するＨＤＤ、ＳＳＤ、フラッシュメモリ等にインストールまたは記憶される。そして、プログラムあるいはソフトウェアの実行時には、必要に応じて記憶部４０２内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵ４０３において演算実行される。

なお、演算実行は必ずしもＣＰＵ等の中央処理部４０３で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。

図５Ａに、本開示の一実施形態にかかるユーザ行動促進支援システムにおける第１処理動作フローを示す。本開示はこれに限定されるものではないが、図５Ａに示された動作フローは、例示的に、スタンプラリーの事前準備からスタンプラリーの実施までを含む。

まず、支援サーバの管理者は、ユーザ行動促進支援システムを用いたサービスを開始する前に、支援サーバのスタンプラリーデータベース（図２Ａの記憶部２０２）に店舗情報を登録しておく（図５Ａ、ステップＳ５００）。ここでの店舗情報は、店舗ＩＤ、店舗名、住所（所在地や位置情報を含む）、取扱商品／提供サービス情報、責任者情報等が含まれてよい。店舗情報の登録後に、ユーザ行動促進支援システムを用いたサービスが開始される。店舗情報は、支援サーバの管理者側で随時更新可能である。

また、スタンプラリーの対象として、店舗に加えてまたは店舗に代えて、別のスポット（例えば地域またはエリア）を用いる場合、当該スポットの情報を登録しておく。ここでのスポット情報は、スポット（エリア）ＩＤ、スポット（エリア）名、住所（所在地や位置情報を含む）、取扱商品／提供サービス／イベント情報、運営者／管理者情報等が含まれてよい。さらに、店舗等のスポットに加えてまたはこれに代えて、イベント（行動）をスタンプラリーの対象として用いる場合、当該イベント（行動）の情報を登録しておく。イベントとしては、特定商品の購入または特定サービスの利用などユーザによる行動を含めてもよい。イベントとしては、友達の紹介（その場合、友達の参加を条件としてもよい）、アンケート回答、所定手続の申込み（ＷＥＢ明細登録、メルマガ申込み、案内通知許可など）が含まれてもよい。

ユーザ端末（図１の１３ａ～１３ｃ等）において、ユーザが所定の操作（アイコンのタップ等）を行うと（ステップＳ５０１）、スタンプラリー用のユーザアプリが起動する（時点ｔ１１～ｔ１２）。なお、サービスやスタンプラリーはアプリに限定されず、ウェブブラウザを介して起動されてもよい。ユーザ端末は、ユーザアプリの起動又はサービスへのアクセス要求を支援サーバに通知する（ステップＳ５０２）。当該通知にはユーザを特定可能な識別情報が含まれてもよい。本開示の一実施形態において、アプリ起動の通知を受信した支援サーバは、自身が管理している店舗サーバ情報の検索処理を実行する（時点ｔ１２～ｔ１３、ステップＳ５０３）。併せて、この検索処理では、ユーザを識別可能な情報からアプリ起動通知を送信したユーザを特定し、当該ユーザのユーザ情報をスタンプラリーデータベース（図２Ａの記憶部２０２）から読み出す。
また、支援サーバは、店舗サーバに対して当該ユーザの取引履歴を要求する（ステップＳ５０４）。ここでの取引履歴は、スタンプラリーの対象期間内のものであり且つ支援サーバがまだ受信していないもの（更新情報）である。取引履歴の要求を受信した店舗サーバは、当該ユーザの取引履歴を店舗データベースから抽出し（ステップＳ５０５）、抽出した取引履歴を支援サーバに送信する（ステップＳ５０６）。なお、スタンプラリーの対象として、上記のように、イベント（行動）の情報を用いる場合、店舗サーバに対してイベントに対する行動履歴を問い合わせる形式も可能である。

取引履歴を受信した支援サーバは、スタンプラリーの特典付与を判断する解析処理を行う（ステップＳ５０７）。本開示の一実施形態において、この特典付与については、スタンプラリーの進捗（達成度）に応じた特典付与を行うことができる。例えば、スタンプラリー対象となっている店舗での購買／訪問、スタンプラリーの対象になっているエリア／地域への訪問等をどの程度達成したかなどの指標が採用される。

あるいは、本開示の他の実施形態において、この特典付与については、所定の決済履歴を満たしているかどうかに基づいて判断されてもよい。特定の店舗で買い物をしたかどうか、特定の対象商品を購入したかどうか（特定のサービスの提供を受けたかどうか）、所定の期間内に商品を購入したか（サービス提供を受けたか）、所定の金額以上の購入をしたかどうかなどである。なお、この場合の買物には、オンラインショップでの購入も対象にすることができる。なお、決済の有無に基づいて店舗に訪問したか否かを判断できるのは言うまでもない。
ユーザにスタンプラリーのラリー対象店舗を選択させ、特典付与と決済行動とを対応付けることにより、ユーザに自身で決済を前提としたスタンプシートを作成させることができるため、ユーザにスタンプラリーの参加／完遂の動機づけをしやすくなる。また、ユーザ自身が決済行動を前提にスタンプシートを作成するため、スタンプラリーに参加／を完遂するために決済をする必要があることへの嫌悪感を軽減することができる。

また、支援サーバは、新たな取引履歴がある場合、スタンプラリーデータベースに記憶する。さらに、本開示はこれに限定されるものではないが、一実施形態として、付与すべき特典が存在する場合、支援サーバは、任意のタイミングでユーザに対して特典を付与することができる（時点ｔ１４、ステップＳ５０８）。すなわち、支援サーバは、付与された特典の内容を示す情報（特典付与情報）をユーザ端末に送信する。特典付与情報を受信したユーザ端末は、その内容を表示する。これにより、ユーザは、アプリ起動時に特典の付与の有無及びその内容を知ることができる。

また、ここにいう特典としては、例えば、スタンプラリー事業者が指定する種別のポイント、物理的商品、ユーザアプリ上の商品（アバター、名誉／ランク／肩書き、バッジ、ランキング）、または商品券／金券（物理的なもの、電子的なもの）とすることができる。また、特典は、体験をする権利（工場見学、製品開発、就業体験、プレオープンへの参加）であってもよい。さらに、特典は、複数の選択肢の中から選択可能な選択型特典であってもよい（選択肢の中にプレミアがついたものが含まれていたり、単に複数の同等のアイテムの中から選択させるものであったりしてもよい。）。また、ユーザに特定の称号を付与するものであってもよい。
加えて、特典付与の条件として、例えば、スタンプラリー達成者全員に付与されるもののほか、特典付与の条件を達成したユーザのうち抽選によって付与されるもの、特典付与の条件を達成したユーザのうち先着順に所定人数まで付与されるもの、付与された特典を仲間と分配し合うもの、所定人数以上のユーザが特典付与の条件を達成した場合にそのユーザの少なくとも一部のユーザに付与されるもの、ユーザの顧客ランクに応じた重み付けによって付与されるものがあってもよい。

また、特典付与の他の条件として、同一のスタンプラリーを行う回数に応じた重み付けを行ってもよい。その場合、同一の店舗についての訪問回数／決済回数についても特典付与の重み付けに用いてもよい。このことは、同一のキャンペーンにおいて、ユーザが複数のシートを作成可能であることを意味する。具体的には、次のようなバリエーションがある。

（１）同一のキャンペーンにおいて作成された複数のシートを達成するごとに、２周目の達成、３周目の達成・・・とカウントしていき、達成する回数が多くなるにつれて、特典を大きくする。

（２）同一のキャンペーンにおいて作成された複数のシートを達成するごとに、２周目の達成、３周目の達成・・・とカウントしていき、達成する回数が多くなるにつれて、特典を暫時小さくしていく。

（３）また、上記複数のシートに選択された同一店舗の達成の回数によって、特典付与の度合いを増やしていく。一例として、特典付与として称号を与えるものとして、１回目には「ブロンズ」、２回目には「シルバー」、３回目には「ゴールド」のタイトルを付与するなど。換言すれば、同一キャンペーンにおいて、同一店舗を複数回ラリー対象として達成することで特典が変化していく。

なお、ユーザが初めてアプリを起動した場合またはサービスを利用する場合、ユーザ端末は、ユーザ情報の登録を求めるメッセージを表示させることができる。当該メッセージに沿ってユーザは、ユーザ情報（名前、生年月日、性別等）の入力を行う。そして、入力が完了すると（例えばユーザが入力完了ボタンを押すと）、ユーザ端末は、支援サーバに対してユーザ情報を送信する。支援サーバは、受信したユーザ情報をスタンプラリーデータベースに登録する。

また、本開示の一実施形態において、支援サーバが管理している情報と、店舗サーバが管理している情報とのユーザの紐付けは、例えばユーザ端末が、ユーザ情報の登録を行う際、登録情報を支援サーバ及び店舗サーバの間で登録情報を共有し、共通のＩＤを管理することで行うことができる。或いは、支援サーバが受信したユーザ情報（名前、生年月日等）を、店舗サーバが保持しているユーザ情報と照合して一致した場合、共通のＩＤを用いて紐付けすることもできる。

次に、ユーザが新たにスタンプラリーを開始する場合（換言すると、新たなスタンプシートを生成する場合）について説明する。ユーザが、新たなスタンプシートを生成するための所定操作をユーザ端末に対して行うと、ユーザ端末は、支援サーバに対して、スタンプラリーの選択肢を要求する（時点ｔ１５、ステップＳ５０９）。ここにいうスタンプラリーの選択肢とは、選択可能な複数のラリー対象のスポット（対象スポット）またはイベント（対象イベント）の候補を意味してよい。なお、選択肢は個々のラリー対象が属するジャンルが含まれてもよい。つまり、選択肢は複数のラリー対象により構成されるジャンルと、複数ラリー対象とで構成されてもよい。

選択肢の要求を受けた支援サーバは、選択肢を抽出するための抽出処理を行う（時点ｔ１５～ｔ１６、ステップＳ５１０）。一実施形態において、支援サーバは、ユーザ情報、行動履歴、ユーザ端末の現在位置等を用いて選択肢を抽出する。本開示はこれらに限定されるものではないが、選択肢の抽出は、例えば、以下の要素の少なくとも１つに基づいて行われてもよい。
（１）ユーザの属性情報：年齢、性別など。
（２）ユーザの行動履歴：ユーザの過去の決済履歴、サービス利用履歴など。
（３）ユーザ端末の現在位置等：その位置がユーザにとって初めてのエリアか否か。複数訪れているエリアである場合にはどの頻度。その日そのエリアに継続して滞在している延べ時間。そのエリアに到達する前にユーザがいたエリアなど。
なお、抽出処理は公知のＡＩ処理により実行されてもよく、抽出される選択肢は、選択肢のジャンル／個別の選択肢がユーザに関する情報に基づいて最適化されて抽出されてもよい。

また、本開示の一実施形態においては、スタンプシートに含めるラリー対象の数や選択肢の数をユーザに関する情報に基づいて設定してもよい。例えば、購買件数や購買金額が大きいユーザにはより多くの選択肢を表示させてもよく、または選択可能枠を少なく表示してもよい。

抽出処理により選択肢を抽出すると、支援サーバは、ユーザ端末に対して選択肢候補を提示する（ステップＳ５１１）。具体的には、支援サーバは、対象店舗の候補に関する情報（対象店舗情報）をユーザ端末に送信する。なお、スタンプラリーのラリー対象として、店舗に加えてまたは店舗に代えて、別のスポット（例えば地域またはエリア）を用いる場合、当該スポットの候補に関する情報（対象スポット情報）をユーザ端末に送信してもよい。また、店舗等のスポットに加えてまたはこれに代えて、イベント（行動）をスタンプラリーのラリー対象として用いる場合、当該イベント（行動）の情報（対象イベント情報）をユーザ端末に送信してもよい。

対象店舗情報を受信したユーザ端末は、ユーザの操作に応答して選択処理を実行する（時点１６～ｔ１７、ステップＳ５１２）。具体的には、ユーザ端末は、ラリー対象を選択するためのスタンプラリー候補提示画面を表示する。当該画面では、ラリー対象として選択可能な複数の選択肢候補が表示され、ユーザ端末への操作により選択可能となっている。ユーザによるユーザ端末への操作により複数の選択肢候補からラリー対象が選択され、決定ボタン等により選択が確定すると、ラリー対象が確定され、スタンプシートの内容が確定して選択処理が完了する。

なお、本開示の他の実施形態においては、スタンプシートに含まれるラリー対象の少なくとも一部は、スタンプラリー事業者、店舗側担当者等のユーザ以外の者が設定してもよい。本発明はこれに限定されるものではないが、店舗が選択肢となるための条件（選択肢属性条件）を定めてもよい。この選択肢属性条件には、店舗での決済手段やポイントカードシステム・会員情報システムが所定のシステムに対応していることなどが挙げられる。

また、本開示の一実施形態において、例えば、スタンプシートにラリー対象として掲載する所定の個数（枠）の少なくとも一部を広告（広告枠）として扱うこともできるため、ラリー対象の運営者が広告を発行するための広告入札システムを採用することもできる。当然に広告枠にはユーザの属性、行動履歴に基づいてユーザごとに最適化されたラリー対象の一部の店舗・エリアが設定されてもよい。換言すれば、ユーザが作成するスタンプシートには、自身が選択したラリー対象以外にも、広告により設定されたラリー対象が含まれてもよい。なお、ユーザが選択していないラリー対象（広告によるラリー対象）はユーザが自身で選択したラリー対象の数より少なくなるように制限してもよい。また、広告によるラリー対象を表示するか否か、あるいは表示する場合の表示件数／表示割合は、ユーザの属性や行動履歴に基づいて調整されてもよい。例えば、購買件数や購買金額が大きいユーザにはより少ない広告によるラリー対象が表示されるなどである。

そして、広告入札システムを採用した場合の店舗（又はエリア）への課金の形態ついては、事後課金（送客実績に応じた費用請求。客人数のみならず、決済された金額に応じた請求額が決定されてもよい。本開示の一実施形態においては、スタンプラリーの選択肢として店舗やエリアが管理されているので、訪問人数、訪問回数、決済人数、決済回数、決済金額等は容易に取得できる。）や固定課金（広告を出す際の固定の課金）など、種々の形態を採用することができる。

また、本開示の他の実施形態においては、スタンプシートに含まれるラリー対象は、全てのラリー対象をユーザが選択するほか、少なくとも対象の一部をラリー事業者が指定したり、公知のＡＩ処理によって指定させたりすることもできる。この場合、ラリー事業者による指定は、そのラリー事業者によるリコメンドであり、ＡＩ処理による指定は、ＡＩによる自動レコメンドという位置付けとなる。
こうしたスタンプの選択候補は、ユーザ（顧客）のタイプごとに提示／選択を実施することができる。

選択処理が完了すると、ユーザ端末は、選択結果（選択された対象店舗／対象イベントの情報（選択情報））を支援サーバに送信する（ステップＳ５１３）。選択情報を受信した支援サーバは、選択情報に基づいて新たなスタンプシートを生成してスタンプラリーデータベースに登録する（時点ｔ１７～ｔ１８、ステップＳ５１４）。次いで、支援サーバは、生成した新たなスタンプシートの情報をユーザ端末に送信する（ステップＳ５１５）。新たなスタンプシートの情報を受信したユーザ端末は、当該情報を表示する（ステップＳ５１６）。これにより、ユーザは、自らの選択結果に基づく新たなスタンプシートを確認することができる。なお、本開示の他の実施形態においては、作成されたスタンプラリー（シート）をラリー運営者／ユーザに選択された店舗が承認するステップを設けてもよい。

次に、生成した新たなスタンプシートを用いてスタンプラリーを行う場合について説明する。ユーザが対象店舗で商品を購入すると（若しくはサービスを受けると）、または特定の対象商品を購入すると（若しくは特定の対象サービスを受けると）、ユーザ端末は、その情報（決済情報）を店舗サーバに送信する（ステップＳ５１７）。決済情報を受信した店舗サーバは、決済処理を進行する（時点ｔ１９～ｔ２０、ステップＳ５１８）。例えば、店舗側で用意された決済用画像情報（二次元コードまたはバーコード）をユーザ端末の読取り装置により読み取る場合（いわゆる店舗提示型：ＭＰＭの場合）、ユーザ端末は、決済完了及び決済内容を店舗サーバに通知する。当該通知を受けた店舗サーバは、決済内容を店舗データベースに登録する。また、ユーザ端末に表示させた決済用画像情報を店舗端末の読取り装置により読み取る場合（いわゆるユーザ提示型：ＣＰＭの場合）、店舗端末が、決済完了及び決済内容を店舗サーバに通知する。或いは、現金で決済を完了した段階で、店舗側で用意された画像情報をユーザ端末が読み取り、ユーザ端末から店舗サーバに通知してもよい。また、決済が終了した時点でユーザ端末を操作し、支援サーバに対して店舗サーバから決済情報を取得するように要求してもよい。なお、決済処理は他の情報処理装置に決済処理を依頼したり、決済処理の結果を取得したりする処理であってもよい。
本開示の一実施形態においては、この決済情報の取得を契機としてユーザへの特典付与の契機とすることができる。図５Ａには図示されていないが、ステップＳ５１８のあと、店舗サーバでは、ユーザごとの特典付与のためのフラグを立てたり、ポイント等の加算値を記録したりして、ユーザへの特典付与のための準備を行うことができる。

なお、決済処理の後にユーザがスタンプラリー用アプリを起動した場合には、上述したステップＳ５０１～Ｓ５０８の処理が行われて、ユーザは、付与された特典を知ることができるようにも構成可能である。また、上記のように、ラリーの対象としてイベント（行動）を用いる場合には、決済情報の代わりに、イベントに対する行動に関する行動情報を用いることも可能である。
本開示の一実施形態においては、この行動情報の取得を契機としてユーザへの特典付与の契機とすることができる。図５Ａには図示されていないが、ステップＳ５１８のあと、店舗サーバでは、ユーザごとの特典付与のためのフラグを立てたり、ポイント等の加算値を記録したりして、ユーザへの特典付与のための準備を行うことができる。

次に、ユーザがスタンプラリーの進捗を確認する場合について説明する。スタンプラリー用アプリを起動している状態で、ユーザがユーザ端末に対して所定の操作を行うと、ユーザ端末は、行動履歴等参照要求を支援サーバに送信する（時点ｔ２１、ステップＳ５１９）。行動履歴等参照要求を受信した支援サーバは、行動履歴等を生成する生成処理を実行する（時点ｔ２１～ｔ２２、ステップＳ５２０）。生成処理において、支援サーバは、対象ユーザの行動履歴を店舗サーバに対して適宜問合せを行い、店舗サーバは、当該問合せに対して回答する（ステップＳ５２１）。生成処理の結果、ユーザの行動履歴をまとめると、支援サーバは、当該行動履歴をユーザ端末に送信する（ステップＳ５２２）。ユーザ端末は、受信した行動履歴を表示する（時点ｔ２２～、ステップＳ５２３）。これにより、ユーザは、スタンプラリーに関する自らの進捗を確認することができる。また、本開示の一実施形態においては、行動履歴等の参照を行った際、付与条件を満たした特典を付与する処理（ステップＳ５０３～Ｓ５０８）を行うことができる。

図５Ｂに、本開示の一実施形態にかかるユーザ行動促進支援システムにおける第２処理動作フローを示す。図５Ｂに示された動作フローは、図５Ａの変形例であり、図５Ａと同様のステップについては説明を簡略化又は省略する。本開示はこれに限定されるものではないが、図５Ｂに示された動作フローは、例示的に、スタンプラリーの事前準備からスタンプラリーの実施までを含む。

まず支援サーバの管理者は、ユーザ行動促進支援システムを用いたサービスを開始する前に、支援サーバのデータベース（図２Ａの記憶部２０２）に店舗情報及びユーザ情報を登録しておく（図５Ｂ、ステップＳ５５１）。少なくとも店舗情報の登録後に、ユーザ行動促進支援システムを用いたサービスが開始される。店舗情報は、支援サーバの管理者側で随時更新可能である。

また、図５Ｂの例では、店舗端末側で店舗情報等を新規にエントリーしたり、追加したりできる。すなわち、店舗端末管理者は、一実施形態において、ブラウザソフトを起動してインターネットを介して支援サーバにアクセス（ログイン）し、店舗情報エントリー画面を開く。そして、店舗端末管理者は、スタンプラリーにエントリーするための店舗情報及び特典情報を入力する（時点ｔ３１～ｔ３２、ステップＳ５５２）。店舗情報及び特典情報が入力されると、店舗端末は、支援サーバにエントリー情報を送信する（ステップＳ５５３）。支援サーバは、受信したエントリー情報を登録する登録処理を行う（ステップＳ５５４）。店舗情報等のエントリーの例については、図６を参照して後述する。なお、ここにいう店舗端末管理者は、店舗等のスポットのオーナーまたはイベントの主催者を含んでもよい。

ステップＳ５５５並びにその後のステップＳ５５６～Ｓ５６２は、図５ＡのステップＳ５０９～Ｓ５１６と同様である。すなわち、ユーザ端末（図１の１３ａ～１３ｃ等）において、ユーザが所定の操作（アイコンのダブルクリック等）を行うと、スタンプラリー用のユーザアプリが起動する（図５Ｂでは図示せず）。ユーザアプリが起動している状態で、ユーザは、新たなスタンプシートを生成するための所定操作をユーザ端末に対して行う。当該操作が行われた場合、ユーザ端末は、支援サーバに対して、スタンプラリーの選択肢を要求する（時点ｔ３３、ステップＳ５５５）。

選択肢の要求を受けた支援サーバは、選択肢を抽出するための抽出処理を行う（時点ｔ３３～ｔ３４、ステップＳ５５６）。抽出処理により選択肢を抽出すると、支援サーバは、ユーザ端末に対して候補を提示する（ステップＳ５５７）。候補情報を受信したユーザ端末は、選択処理を実行する（時点３４～ｔ３５、ステップＳ５５８）。選択処理が完了すると、ユーザ端末は、選択結果（選択された対象店舗／対象イベントの情報（選択情報））を支援サーバに送信する（ステップＳ５５９）。選択情報を受信した支援サーバは、選択情報に基づいて新たなスタンプシートを生成してスタンプラリーデータベースに登録する（時点ｔ３５～、ステップＳ５６０）。次いで、支援サーバは、生成した新たなスタンプシートの情報をユーザ端末に送信する（時点ｔ３６、ステップＳ５６１）。新たなスタンプシートの情報を受信したユーザ端末は、当該情報を表示する（ステップＳ５６２）。これにより、ユーザは、自らの選択結果に基づく新たなスタンプシートを見ることができる。

次に、生成した新たなスタンプシートを用いてスタンプラリーを行う場合について説明する。ユーザが対象店舗で商品を購入すると（またはサービスを受けると）、ユーザ端末は、その情報（決済情報）を店舗サーバに送信する（ステップＳ５６３）。決済情報を受信した店舗サーバは、決済処理を行う（時点ｔ３７～ｔ３８、ステップＳ５６４）。決済処理が終わると、店舗サーバは、決済情報を支援サーバに通知する（ステップＳ５６５）。支援サーバは、受信した決済情報をスタンプラリーデータベースに登録する履歴管理を行う（ステップＳ５６６）。ステップＳ５６６の履歴管理は、図５Ａの解析処理（ステップＳ５０７）と同様である。履歴管理の後、付与すべき特典が存在する場合、支援サーバは、ユーザに対して特典を付与する（時点ｔ３９、ステップＳ５６７）。従って、少なくとも図５Ｂの例においては、ユーザは、明示的に決済処理を契機として、特典付与を知ることができる。

このように、本開示の一実施形態における特徴の１つは、決済（あるいは、ユーザの行動）を契機として、ユーザに対し特典を付与できる点にある。

なお、図５Ｂでは、決済処理の完了を店舗サーバから支援サーバに行う形としたが、その他の方法で支援サーバが決済処理の完了を通知してもよい。例えば、ユーザ端末から支援サーバに対して決済処理の完了及び内容を通知してもよい。或いは、ユーザ端末から支援サーバに対して決済処理の完了を通知し、当該通知を受けた支援サーバは、店舗サーバに対して決済処理の内容確認を行った後、履歴管理を行うことも可能である。

次に、ユーザがスタンプラリーの進捗を確認する場合について説明する。図５ＢのステップＳ５６８～Ｓ５７１は、基本的に図５ＡのステップＳ５１９～Ｓ５２３と同様である。すなわち、スタンプラリー用アプリを起動している状態で、ユーザがユーザ端末に対して所定の操作を行うと、ユーザ端末は、行動履歴等参照要求を支援サーバに送信する（時点ｔ４０、ステップＳ５６８）。行動履歴等参照要求を受信した支援サーバは、行動履歴等を抽出する抽出処理を実行する（時点ｔ４０～ｔ４１、ステップＳ５６９）。抽出処理において、支援サーバは、対象ユーザの行動履歴をスタンプラリーデータベースから抽出する。
上記のように、図５Ｂの例では、決済処理（ステップＳ５６４）が行われると、その決済内容は支援サーバに通知されてスタンプラリーデータベースに登録される。そのため、行動履歴等参照要求がされた時点（ステップＳ５６８）では、支援サーバから店舗サーバへの問合せは行われない。抽出処理の結果、ユーザの行動履歴をまとめると、支援サーバは、当該行動履歴をユーザ端末に送信する（ステップＳ５７０）。ユーザ端末は、受信した行動履歴を表示する（時点ｔ４１～、ステップＳ５７１）。これにより、ユーザは、スタンプラリーに関する自らの進捗を確認することができる。

次に、図６を参照して、店舗情報等のエントリー（一例として、図５ＢのステップＳ５５２～Ｓ５５４の詳細例）について説明する。図５Ｂの例では、エントリー情報を支援サーバが登録したが、本開示はこれに限定されることはなく、店舗サーバに登録してもよい。ここで、店舗サーバにエントリー情報を登録する場合、店舗サーバに登録されたエントリー情報は、例えば、所定タイミングで支援サーバにも登録されることができる。ここで、所定タイミングとは、一実施形態において、後述する送信内容のチェック（後述のステップＳ６０８）の結果、送信内容を承認するタイミングとすることができる。

エントリーが開始されると（図６、ステップＳ６０１）、店舗端末の管理者は、ブラウザソフトを用いて店舗端末から支援サーバまたは店舗サーバ（図６において、単に「サーバ」ともいう。）に対してアクセス要求を送信する（ステップＳ６０２）。ここにいう店舗端末の管理者は、店舗等のスポットのオーナーまたはイベントの主催者を含んでもよい。支援サーバまたは店舗サーバは、ワンタイムパスワード等を用いて認証処理を行う（ステップＳ６０３）。認証処理は、公知のものを用いることが可能であり、また、認証処理を省略してもよい。認証処理の結果、認証が成功した場合（ステップＳ６０４において、Ｙｅｓ）、ステップＳ６０５に進み、認証が失敗した場合（ステップＳ６０４において、Ｎｏ）、今回の処理を終了し（ステップＳ６１１）、再度、ステップＳ６０１からやり直す。

認証が成功した場合（ステップＳ６０４において、Ｙｅｓ）、支援サーバまたは店舗サーバは、店舗端末に対して入力フォームを送信する（ステップＳ６０５）。店舗端末は、受信した入力フォームを表示し、店舗端末の管理者等からのエントリー情報の入力を受け付ける（ステップＳ６０６）。ここでの入力内容としては、店舗名、住所、取扱商品／提供バービス、管理者／責任者等の種々の情報が含まれる。エントリー情報の入力が完了すると、店舗端末は、支援サーバまたは店舗サーバに対して入力内容（エントリー情報）を送信する（ステップＳ６０７）。

本開示の一実施形態において、支援サーバまたは店舗サーバは、受信したエントリー情報をチェックする（ステップＳ６０８）。例えば、必須項目が入力されているか、入力内容がスタンプラリーの内容に対して適切なものかが判定される。当該判定は、サーバが自動的に行うことができるが、これに代えて、スタンプラリー運営者が人手で判断してもよい。エントリー情報に問題がない場合（ステップＳ６０９において、Ｙｅｓ）、支援サーバまたは店舗サーバは、受信したエントリー情報をデータベース（例えばスタンプラリーデータベースまたは店舗データベース）に登録する（ステップＳ６１０）。換言すると、店舗端末管理者（スポットのオーナー及び／またはイベントの主催者を含む）による個別の登録は、個々の申請に対する承認によってなされる。支援サーバがスタンプラリーデータベースにエントリー情報を登録した場合、支援サーバは、その後のスタンプシートの生成（図５ＢのＳ５５５～Ｓ５６２）において、当該エントリー情報（店舗）を対象店舗の選択肢として用いる。また、店舗サーバが店舗データベースにエントリー情報を登録した場合、店舗サーバは、所定のタイミングで、当該エントリー情報を支援サーバに提供することができる。なお、エントリーに条件（選択肢属性条件）を定めてもよい。この条件には、ラリー対象が店舗である場合、例として、店舗での決済手段やポイントカードシステム・会員情報システムが所定のシステムに対応していることなどが挙げられる。

次に、図７を参照して、スタンプラリーを実施するスタンプラリー処理（図５Ｂ、ステップＳ５６３～Ｓ５６６の詳細例）について説明する。なお、図５Ｂの例では、決済情報を支援サーバに登録したが、本開示はこれに限定されるものではなく、図５Ａの例のように店舗サーバに登録し、必要に応じて支援サーバから問い合わせるように構成されてもよい。

スタンプラリー処理が開始されると（ステップＳ７０１）、ユーザ端末のユーザ（利用者）は、ユーザ端末に対して所定の操作を行って、スタンプラリー用のユーザアプリを起動させる（ステップＳ７０２）。ユーザアプリが起動すると、初期画面またはその後の所定画面において、現在ユーザが実施中のスタンプラリーの詳細を表示する（ステップＳ７０３）。なお、当該表示は省略してもよい。また、図５Ａの例のように、ユーザアプリ起動時に、ラリーの進捗状況（決済情報の更新）を確認する場合、更新内容をポップアップ表示するようにしてもよい。

ユーザは、ラリー対象の店舗またはイベント（行動）を選択する（ステップＳ７０４）。当該選択は、スタンプラリーのラリー対象候補の表示をユーザが確認し、対象店舗での購入または対象イベントの実施をユーザが選択処理することを意味する。或いは、ステップＳ７０３でスタンプラリーの表示を省略する場合、ユーザの記憶によりラリー対象を行うことをユーザが選択入力する形でもよい。そして、ユーザは、ラリー対象での行動（対象店舗での購入や対象エリアへの訪問等）を行う（ステップＳ７０５）。

ラリー対象での行動が行われると、その履歴（決済履歴または行動履歴）の情報（履歴情報）が店舗サーバまたは支援サーバに送信される（ステップＳ７０６）。店舗サーバまたは支援サーバは、受信した履歴情報の内容をチェックする（ステップＳ７０７）。履歴情報の内容に問題がない場合（Ｓ７０７において、Ｙｅｓ）、店舗サーバまたは支援サーバは、受信した履歴情報を店舗データベースまたはスタンプラリーデータベースに登録し（ステップＳ７０８）、本フローとしは、処理を終了する（ステップＳ７０９。スタンプラリー自体は継続可能である。以下、同様。）。履歴情報の内容に問題がある場合（Ｓ７０７において、Ｎｏ）、店舗サーバまたは支援サーバは、受信した履歴情報をデータベースに登録せずに、本フローとしては、処理を終了する（ステップＳ７０９）。なお、ステップＳ７０７においてＮｏの場合、店舗サーバまたは支援サーバは、エラー等を示すメッセージをユーザ端末に表示させてもよい（不図示）。

次に、図８～図１２Ｂを参照して、本開示の一実施形態にかかるユーザ行動促進支援システムにおけるユーザ端末画面例について説明する。図８に、本開示の一実施形態にかかるスタンプラリー画面（スタンプシート）の第１例を表示するユーザ端末としてのスマートフォンまたはタブレット端末の外観構成を示す。図８において、ユーザ端末８００（スマートフォンまたはタブレット端末）は、筐体部８０１とディスプレイ８０２と筐体８０２の下部中央部に設けられたハードウェアボタン８０３とからなる。ディスプレイ８０２に表示されるスタンプラリー画面は、ユーザが選択（生成）したラリー対象を表示させ、これからどのラリー対象を達成しようとするのかを選択する画面であり、例えば、図５ＡのステップＳ５１６あるいは図５ＢのステップＳ５６２にて採用することができる。

図８のスタンプラリー画面は、スタンプラリー概要説明８１１と、スタンプシート８１２と、特典説明８１３とを含む。スタンプラリー概要説明８１１は、今回実施中のスタンプラリーの概要に関する説明であり、例えば、スタンプラリーの名称、実施期間、特典の概要／内容に関する記載を含む。スタンプシート８１２は、ユーザがクリアすべきラリー対象８１４ａ～８１４ｆを含む。ここでのラリー対象８１４ａ～８１４ｆは、対象スポット（対象店舗、対象エリア等）及び対象イベントを含むことができる。特典説明８１３は、特典の付与条件や特典内容に関する記載を含むことができる。

図９は、本開示の一実施形態にかかるスタンプラリー画面（スタンプシート）の第２例を表示するユーザ端末としてのスマートフォンまたはタブレット端末の外観構成を示す。図９において、ユーザ端末９００は、筐体部９０１とディスプレイ９０２とハードウェアボタン９０３とからなる。ディスプレイ９０２に表示されるスタンプラリー画面は、スタンプラリー概要説明９１１と、スタンプシート９１２と、特典説明９１３とを含む。一実施形態において、スタンプシート９１２内のラリー対象９１４ａ～９１４ｆのうち既にユーザが達成したラリー対象９１４ｂ、９１４ｄについては、済マーク９１５が付される。これにより、ユーザは、ラリーの進捗を確認することが可能となる。

なお、スタンプシートの形態は、図８及び図９に示すようなものに限らず、その他の形態であってもよい。限定でなく例として、すごろくのようにスタンプを押す順番が定められているものを用いてもよい。その場合、マイルストンを設けて段階的に特典を付与することも可能である。あるいは、次のスタンプに進むための決済額や決済回数の下限などの制限を設けてもよい。あるいは、ビンゴ形式のスタンプシートを用いてもよい。ビンゴ形式の場合、縦、横、斜めのいずれかが揃ったら特典が付与されてもよい。

図１０は、本開示の一実施形態にかかるスタンプラリー候補選択画面の第１例を表示するユーザ端末としてのスマートフォンまたはタブレット端末の外観構成を示す。図１０において、ユーザ端末１０００は、筐体部１００１とディスプレイ１００２とハードウェアボタン１００３とからなる。ディスプレイ１００２に表示されるスタンプラリー候補選択画面は、ユーザが選択可能なラリー対象を表示させ、ユーザが希望するラリー対象を選択することでスタンプシートを生成するための画面であり、例えば、図５ＡのステップＳ５１２あるいは図５ＢのステップＳ５５８にて採用することができる。

図１０のスタンプラリー候補選択画面は、選択方法説明１０１１と、カテゴリ表示１０１２ａ～１０１２ｄと、スタンプラリー候補１０１３ａ～１０１３ｐと、スクロールバー１０１４を含む。選択方法説明１０１１は、スタンプラリー候補１０１３ａ～１０１３ｐの選択方法の説明である。カテゴリ表示１０１２ａ～１０１２ｄは、候補１０１３ａ～１０１３ｐのカテゴリを表示する。本開示の一実施形態において、ユーザは、１つのカテゴリから１つの候補１０１３ａ～１０１３ｐを選択可能である。また、候補１０１３ａ～１０１３ｐの選択方法は、例えば、ユーザが指でタッチする、カーソルを合わせて左クリックする等により行うことができる。スクロールバー１０１４は、スタンプラリー候補選択画面を上下動させるのに用いられる。

図１１は、本開示の一実施形態にかかるスタンプラリー候補選択画面の第２例を表示するユーザ端末としてのスマートフォンまたはタブレット端末の外観構成を示す。図１１において、ユーザ端末１１００は、筐体部１１０１とディスプレイ１１０２とハードウェアボタン１１０３とからなる。ディスプレイ１１０２に表示されるスタンプラリー候補選択画面は、図１０においてスクロールバー１０１４を操作してスタンプラリー候補選択画面を下方にスクロールさせた状態に対応する。

図１１のスタンプラリー候補選択画面は、選択方法説明１１１１と、カテゴリ表示１１１２ｃ～１１１２ｅと、スタンプラリー候補１１１３ｅ～１１１３ｒと、スクロールバー１１１４と、決定ボタン１１５とを含む。図１１の各構成要素は、基本的に図１０の各構成要素と同様であるため、詳細な説明を省略する。一実施形態において、図１１のスタンプラリー候補１１１３ｇ、１１１３ｉ、１１１３ｏは、ユーザによって選択中であることを示す選択マーク１１１６が付されている。

また、カテゴリ表示１１１２ｅ「ボーナス」に対応する候補１１１３ｑ、１１１３ｒは、スタンプシート作成前にもかかわらず、済マーク１１１７を付与しておくことができる。これは、優良ユーザ等に対する特典として、日頃よく行く店等（具体的には、過去一定期間内に一定の回数以上来店しているとか、毎月の平均訪問回数が一定以上であるなどによって認定することができる。）について予め済として設定し、表示させているものである。例えば、図８及び図９の例であれば、「済」の数で特典が付与されるため、「ボーナス」に対応する候補１１１３ｑ、１１１３ｒがスタンプシート作成前に「済」となっていることで、ユーザは特典を得易くなる。候補の選択が完了した状態で、ユーザが決定ボタン１１１５を押すと、新たなスタンプシートが生成される。

あるいは、他の実施形態として、日頃よく行く店等（具体的には、過去所定期間内に所定の回数以上来店しているとか、毎月の平均訪問回数が所定回数以上であるなどによって認定することができる。）については、ラリー候補から外しておくという制御も可能である。スタンプラリーの候補として提示しなくとも、そのユーザは自らその店舗等を利用する可能性が高いと考えることもできるからである。

図１２Ａは、本開示の一実施形態にかかるスタンプラリー画面（スタンプシート）の第３例を表示するユーザ端末としてのスマートフォンまたはタブレット端末の外観構成を示す。図１２Ａにおいて、ユーザ端末１２００は、筐体部１２０１とディスプレイ１２０２とハードウェアボタン１２０３とからなる。ディスプレイ１２０２に表示されるスタンプラリー画面は、基本的に図１０のスタンプラリー画面と同様であり、スタンプラリー概要説明１２１１と、スタンプシート１２１２と、特典説明１２１３とを含む。さらに、図１２Ａのスタンプラリー画面は、特定のスポット（ここではスポットＢ）の訪問に対して先着順で特典を付与する旨を通知する訪問動機付け表示１２１５を含む。これにより、ユーザに対して、当該スポットへの訪問を促すことが可能となる。

図１２Ｂは、本開示の一実施形態にかかるスタンプラリー画面（スタンプシート）の第４例を表示するユーザ端末としてのスマートフォンまたはタブレット端末の外観構成を示す。図１２Ｂにおいて、ユーザ端末１２５０は、筐体部１２５１とディスプレイ１２５２とハードウェアボタン１２５３とからなる。ディスプレイ１２５２に表示されるスタンプラリー画面は、基本的に図１０のスタンプラリー画面と同様であり、スタンプラリー概要説明１２６１と、スタンプシート１２６２と、特典説明１２６３とを含む。さらに、図１２Ｂのスタンプラリー画面は、所定の天候（ここでは雨）における特定の店舗（店舗Ａ）の訪問に対して特典を付与する旨を通知する訪問動機付け表示１２６５を含む。これにより、ユーザに対して、当該店舗への訪問を促すことが可能となる。

次に、図１３～図１５を参照して、スタンプ付与条件として、決済以外の条件を用いる場合の処理について説明する。まず、図１３を参照して、スタンプ付与条件を一般化した場合の処理について説明する。スタンプラリー用のユーザアプリを起動している状態で処理を開始する（ステップＳ１３０１）。ユーザは、スタンプシートのラリー対象に含まれる店舗またはエリアに到達する（ステップＳ１３０２）。

そして、ユーザは、ユーザ端末を使った所定行動を実行する（ステップＳ１３０３）。当該所定行動としては、後述するオブジェ撮影（図１４）、位置情報の利用（図１５）に加えて、店舗側で用意された画像情報（二次元コードまたはバーコード）をユーザ端末の読取り装置により読取り、ユーザ端末に表示させた画像情報（二次元コードまたはバーコード）を店舗端末の読取り装置により読取り等を行うことができる。店舗側で用意された画像情報をユーザ端末の読取り装置により読み取る場合（いわゆる店舗提示型：ＭＰＭの場合）、ユーザ端末と店舗サーバとが通信して所定行動が行われたものとする。また、ユーザ端末に表示させた画像情報を店舗端末の読取り装置により読み取る場合（いわゆるユーザ提示型：ＣＰＭの場合）、店舗端末と店舗サーバとが通信して所定行動が行われたものとする。店舗サーバの代わりに支援サーバが上記処理を行ってもよい。

なお、本開示の他の実施形態においては、ユーザ端末を使った行動として、次のようなものを採用することもできる。
（１）所定の季節、天候、時間帯を条件とするユーザの来店やユーザ決済、あるいはユーザの訪問。
（２）ユーザ端末を介して実施される、当該ユーザによる他のユーザ（友達）の紹介。
（３）所定のメールマガジン購読の申込や、Ｗｅｂ明細登録申請、サーバからの通知許可設定など、ユーザ端末を介して行われる所定の設定処理等。
（４）ユーザ端末を介して実施される、所定のアンケートに対する回答処理。
これらのユーザ行動は、それぞれ単独で「ユーザ端末を使った行動」として位置付けることができる。

ユーザ端末を使った所定行動が実行され、所定行動に関する情報が店舗サーバまたは支援サーバに送信されると、店舗サーバまたは支援サーバは、受信情報をチェックする（ステップＳ１３０４）。受信情報に問題がない場合（Ｓ１３０４において、Ｙｅｓ）、店舗サーバまたは支援サーバは、受信情報を履歴情報としてデータベースに登録する（ステップＳ１３０５）。その際、店舗サーバまたは支援サーバは、正常に登録された旨をユーザ端末に送信してもよい。受信情報に問題があった場合（Ｓ１３０４において、Ｎｏ）又は登録（Ｓ１３０５）が完了した場合、本フローとしては、処理を終了する（ステップＳ１３０６）。

次に、図１４を参照して、スタンプ付与条件として、店舗またはエリアに設置されているオブジェの撮影を用いる場合の処理について説明する。スタンプラリー用のユーザアプリを起動している状態で処理を開始する（ステップＳ１４０１）。ユーザは、スタンプシートのラリー対象に含まれる店舗またはエリアに到達する（ステップＳ１４０２）。

そして、ユーザは、ユーザ端末を使って、店舗またはエリアに設置されているオブジェを撮影する（ステップＳ１４０３）。本開示はこれに限定されるものではないが、一実施形態において、撮影は、スタンプラリー用ユーザアプリの指示に従って行われる。また、はじめかから撮影すべきオブジェを明示せず、たとえば、質問形式で当該オブジェを示してもよい。次いで、ユーザは、ユーザ端末を用いて、撮影画像を店舗サーバまたは支援サーバに送信する（ステップＳ１４０４）。店舗サーバまたは支援サーバは、受信した撮影画像の認証処理を行う（ステップＳ１４０５）。具体的には、受信した撮影画像が、店舗またはエリアに設置されているオブジェであるか否かを判定する。受信した撮影画像と対比する画像は、ユーザ行動促進支援システムの管理者または店舗責任者等が店舗サーバまたは支援サーバに登録してもよい。

受信した撮影画像が適切なものであり認証に成功した場合（Ｓ１４０６において、Ｙｅｓ）、店舗サーバまたは支援サーバは、認証の成功（または受信した撮像画像自体）を履歴情報としてデータベースに登録する（ステップＳ１４０７）。その際、店舗サーバまたは支援サーバは、正常に登録された旨をユーザ端末に送信してもよい。また、珍しいオブジェを撮影した場合にポイントまたは特典をアップするなど、撮影されたオブジェの内容によって特典の厚みを変えてもよい。受信した撮影画像が適切なものでなく認証が成功しなかった場合（Ｓ１４０６において、Ｎｏ）又は登録（Ｓ１４０７）が完了した場合、今回の処理を終了する（ステップＳ１４０８）。

次に、図１５を参照して、スタンプ付与条件として、位置情報を用いる場合の処理について説明する。位置情報としては、例えばＧＰＳ情報を用いるがその他の方法による位置情報（近距離無線通信（ＮＦＣ）、ビーコン、またはバーコード等の画像情報若しくは電子スタンプ等）であってもよい。スタンプラリー用のユーザアプリを起動している状態で処理を開始する（ステップＳ１５０１）。ユーザは、スタンプシートのラリー対象に含まれる店舗またはエリアに到達する（ステップＳ１５０２）。

ユーザ端末は、店舗サーバまたは支援サーバに対して自己の位置情報（ＧＰＳ情報）を送信する（ステップＳ１５０３）。店舗サーバまたは支援サーバは、受信した位置情報が示す位置が、ラリー対象の店舗またはエリア等の位置に合致しているか否かを判定する（ステップＳ１５０４）。当該判定は、例えば、受信した位置情報が示す位置が、店舗若しくはエリア等の位置を示す範囲内にあるか否か、または受信した位置情報が示す位置と店舗若しくはエリア等の位置との距離が所定値以下であるか否かにより行うことができる。なお、受信した位置情報と比較するための店舗またはエリアの位置情報は予めデータベースに登録されている。あるいは、店舗またはエリアの位置情報は、事前に入力された住所によって位置の範囲を店舗サーバまたは支援サーバにおいて自動計算してもよい。

受信した位置情報が示す位置が、ラリー対象の店舗またはエリア等の位置に合致しているか、それらの位置から一定範囲内にある場合（Ｓ１５０５において、Ｙｅｓ）、店舗サーバまたは支援サーバは、ユーザが当該店舗またはエリアを訪問したと判定し、そのことを示す履歴情報をデータベースに登録し（ステップＳ１５０６）、本フローの処理としては終了する（ステップＳ１５０７）。なお、ステップＳ１５０６の登録のあとに、店舗サーバまたは支援サーバは、ラリー対象の１つがクリアされた旨をユーザ端末に送信してもよい。受信した位置情報が示す位置が、ラリー対象の店舗またはエリア等の位置に合致していないか、それらの位置から一定範囲外にある場合（Ｓ１５０５において、Ｎｏ）、本フローの処理としては終了する（ステップＳ１５０７）。

なお、本開示の他の実施形態においては、サーバに送信されてきた写真画像から取得できるＥｘｉｆ情報によって位置情報判断を行ってもよい。このときに端末の位置情報をも受信し、両者を比較することで画像の使い回し等の不正を検知することができる。

次に、図１６を参照して、スタンプを付与するスタンプ付与処理の例（図５ＡのＳ５０７、Ｓ５２０、図５ＢのＳ５６６、Ｓ５６９等において採用可能）について説明する。本開示の一実施形態において、図１６のスタンプ付与処理は、支援サーバが実行するが、本開示はこれに限定されるものではなく、店舗サーバが実行してもよい（以下では、動作主体を支援サーバとして記載するが、店舗サーバを動作主体としてもよい。）。

スタンプ付与処理を開始すると（ステップＳ１６０１）、支援サーバは、特定のユーザ（対象ユーザ）に関して取引履歴または行動履歴の取得が必要であるか否かを判定する（ステップＳ１６０２）。当該判定は、例えば、ユーザ毎のスタンプシートの内容に応じて行う。すなわち、未処理のラリー対象の中に取引履歴または行動履歴に関するものがあるか否かに応じてフローは進行する。取引履歴または行動履歴の取得が必要である場合（Ｓ１６０２において、Ｙｅｓ）、支援サーバは、店舗サーバから取引履歴または行動履歴の情報を取得する（ステップＳ１６０３）。取引履歴及び行動履歴の取得が必要でない場合（Ｓ１６０２において、Ｎｏ）またはステップＳ１６０３の後、ステップＳ１６０４に進む。

ステップＳ１６０４において、支援サーバは、取得した取引履歴の中に決済履歴があるか否かを判定する。決済履歴がある場合（Ｓ１６０４において、Ｙｅｓ）、支援サーバは、決済履歴に基づくスタンプを集計する（ステップＳ１６０５）。このとき、未処理のラリー対象がある場合には、当該対象に対するスタンプ付与処理を実行し、それらを集計することもできる。

本開示の一実施形態において、スタンプの付与処理は、所定期間における次の（１Ａ）～（１Ｃ）の少なくとの１つの条件を考慮して行うことができる。
（１Ａ）ユーザによる決済回数、１回あたりの決済金額、決済金額合計のうち、少なくとも１つを含む決済実績。
（１Ｂ）ユーザによる決済回数、１回あたりの決済金額、決済金額合計のうち、少なくとも１つを含む決済実績の順位。
（１Ｃ）ユーザによる決済時の季節、天候、時間帯に関する少なくとも１つに基づく基準。

上記（１Ａ）については、例えば、決済の有無によってスタンプ付与するかを決定してもよい。あるいは、決済回数が多いほど、１回当あたりの決済金額が多いほど、または決済金額合計が多いほど、スタンプ付与に関する優遇を与えてもよい。また、上記（１Ｂ）については、決済実績の順位が高いほど、スタンプ付与に関する優遇を与えてもよい。さらに、上記（１Ｃ）については、人手が少なくなる傾向にある季節、天候、時間帯の場合に、スタンプ付与に関する優遇を与えてもよい。なお、上記（１Ａ）～（１Ｃ）は、後述する他のステップ（例えば、ステップＳ１６１１、Ｓ１６１３）において考慮することも可能である。決済履歴がない場合（Ｓ１６０４において、Ｎｏ）またはステップＳ１６０５の後、ステップＳ１６０６に進む。

ステップＳ１６０６において、支援サーバは、取得した履歴の中に行動履歴があるか否かを判定する。行動履歴がある場合（Ｓ１６０６において、Ｙｅｓ）、支援サーバは、行動履歴に基づくスタンプを集計する（ステップＳ１６０７）。このとき、未処理のラリー対象がある場合には、当該対象に対するスタンプ付与処理を実行し、それらを集計することもできる。

本開示の一実施形態において、スタンプの付与処理は、所定期間における次の（２Ａ）～（２Ｃ）の少なくとの１つの条件を考慮して行うことができる。
（２Ａ）ユーザによる訪問の有無、訪問回数のうち、少なくとも１つを含む訪問実績。
（２Ｂ）ユーザによる訪問順位（先着順）。
（２Ｃ）ユーザによる訪問時の季節、天候、時間帯に関する少なくとも１つに基づく基準。

上記（２Ａ）については、例えば、訪問有りの場合、または訪問回数が多いほど、スタンプ付与に関する優遇を与えてもよい。また、上記（２Ｂ）については、訪問順位が高いほど（より早く訪問したほど）、スタンプ付与に関する優遇を与えてもよい。さらに、上記（２Ｃ）については、人手が少なくなる傾向にある季節、天候、時間帯の場合に、スタンプ付与に関する優遇を与えてもよい。なお、上記（２Ａ）～（２Ｃ）は、後述する他のステップ（例えば、ステップＳ１６１１、Ｓ１６１３）において考慮することも可能である。行動履歴がない場合（Ｓ１６０６において、Ｎｏ）またはステップＳ１６０７の後、ステップＳ１６０８に進む。

ステップＳ１６０８において、支援サーバは、関連スタンプ実績があるか否かを判定する。例えば、同一ユーザが過去に行ったスタンプラリーにおいて、今回のスタンプラリーに関連するものがあるか否かを判定する。関連スタンプ実績がある場合（Ｓ１６０８において、Ｙｅｓ）、支援サーバは、関連スタンプ実績を考慮してスタンプを付与する（ステップＳ１６０９）。例えば、当該ユーザが前回のスタンプラリーを完遂できなかった場合、今回のスタンプラリーにおいて優遇措置をとってもよい。例えば、今回のスタンプシートに含まれるラリー対象（スタンプ）の数を少なくして、スタンプラリーを完遂し易くする。或いは、当該ユーザが前回のスタンプラリーを完遂できなかった場合、前回のスタンプラリーの実績を今回のスタンプラリーに引き継いでリスタート可能としてもよい。関連スタンプ実績がない場合（Ｓ１６０８において、Ｎｏ）またはステップＳ１６０９の後、ステップＳ１６１０に進む。

ステップＳ１６１０において、支援サーバは、先着・ランキング実績があるか否かを判定する。例えば、同一ユーザが過去に行ったスタンプラリーにおいて所定の順番以内でラリーを完了させたか（先着順）を判定する。また、同一ユーザが過去に行ったスタンプラリーにおいて所定順位以内のランキングでラリーを完了させたか（ランキング順）を判定する。ランキングの項目は、決済金額、決済回数、来店回数等を用いることができる。先着・ランキング実勢がある場合（Ｓ１６１０において、Ｙｅｓ）、支援サーバは、先着・ランキング実績を考慮してスタンプを付与する（ステップＳ１６１１）。例えば、先着順またはランキング順が所定範囲内である場合、今回のスタンプラリーにおいて優遇措置をとる。例えば、今回のスタンプシートについて、最初から１または複数のスタンプがクリアされたものとしてもよい。先着・ランキング実績がない場合（Ｓ１６１０において、Ｎｏ）またはステップＳ１６１１の後、ステップＳ１６１２に進む。

ステップＳ１６１２において、支援サーバは、季節・天候・時間要素の考慮を要するか否かを判定する。例えば、同一ユーザが過去に行ったスタンプラリーにおいて所定の季節、天候または時間帯（特に人手が少ない季節、天候または時間帯）についてラリー対象をクリアしているかを判定する。季節・天候・時間要素の考慮を要する場合（Ｓ１６１２において、Ｙｅｓ）、支援サーバは、季節・天候・時間要素を考慮してスタンプを付与する（ステップＳ１６１３）。例えば、人手が少ない季節、天候または時間帯について過去のスタンプラリーでラリー対象をクリアしている場合、今回のスタンプラリーにおいて優遇措置をとる。例えば、今回のスタンプシートについて、最初から１または複数のスタンプがクリアされたものとしてもよい。季節・天候・時間要素の考慮を要さない場合（Ｓ１６１２において、Ｎｏ）またはステップＳ１６１３の後、ステップＳ１６１４に進む。

ステップＳ１６１４において、支援サーバは、その他の要素の考慮を要するか否かを判定する。その他の要素の考慮を要する場合（Ｓ１６１４において、Ｙｅｓ）、支援サーバは、その他の要素を考慮してスタンプを付与する（ステップＳ１６１５）。その他の要素の考慮を要さない場合（Ｓ１６１４において、Ｎｏ）またはステップＳ１６１５の後、今回のスタンプ付与処理を終了する（ステップＳ１６１６）。なお、ここでのスタンプの集計結果は、支援サーバのスタンプラリーデータベースに保存され、必要に応じてユーザに提示されてもよい。

本開示の一実施形態において、上記「その他の要素」の考慮には、次のようなものがある。
（１）ユーザがスタンプラリーを完遂できなかった場合（一例として、所定期間に所定個数のスタンプを集められなかったなど）、関連するスタンプラリーが次回開催される際に、優遇措置をとる（たとえば、所定個数のスタンプをあらかじめ付与しておくなど）。
（２）ユーザがスタンプラリーを完遂できなかった場合（一例として、所定期間に所定個数のスタンプを集められなかったなど）、関連するスタンプラリーが次回開催される際に、リマインド通知を行う。
（３）ユーザがスタンプラリーを完遂できなかった場合（一例として、所定期間に所定個数のスタンプを集められなかったなど）、スタンプラリーの開催期間を所定期間自動延長する。

また、上記のように、図１６の例ではスタンプの付与に関して説明したが、本開示はこれに制限されるものではなく、スタンプの付与と共に、あるいは、スタンプの付与に代えて、他の特典の付与（ポイントの付与等）を行うことが可能である。すなわち、所定期間における決済履歴、行動履歴、関連スタンプ実績、先着・ランキング実績、季節・天候・時間要素、その他の要素の１つまたは複数に基づいて特典を付与することができる。

＜他のバリエーション＞
本開示の他の実施形態においては、次のような機能を実装することもできる。
（１）グループ参加
ユーザ同士を対応付けたりグループを形成したりする。そして、一実施形態においては、生成されるスタンプラリーの難易度をユーザ個人で生成するものよりも高く設定する（例えば、選択が必須なスタンプ選択肢の数を多くする、スタンプ付与の条件となる決済金額を大きくする、要求される来店回数を多くするなど。）。特典付与は、相互に対応付けられたユーザ、又はグループに対応づけられたユーザの数で均等に配分してもよいし、スタンプラリー達成に対する各々のユーザの貢献率に応じて配分されてもよい。貢献率は、決済金額や決済金額、訪問回数などに基づいて決定されてもよい。
（２）参加店舗／エリアへの報酬処理等
各ユーザが実施するスタンプラリーにおいて、最も多く選択された店舗／エリア、最も多く訪問された店舗／エリア、最も決済額が高かった店舗等を記録しておき、当該記録に基づいて店舗／エリアに対する報償処理を行う。
（３）レポート出力
ユーザのスタンプラリー終了後に、その結果や経過がわかるデータをレポート出力させる。また、ユーザの属性ごとに、選択肢に選定されたカテゴリや店舗／エリア等の統計情報を出力する。

以上、具体例に基づき、ユーザ行動促進支援システム等の実施形態を説明したが、本開示の実施形態としては、システム又は装置を実施するための方法又はプログラムの他、プログラムが記録された記憶媒体（一例として、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＣＤ－ＲＷ、磁気テープ、ハードディスク、メモリカード）等としての実施態様をとることも可能である。

また、プログラムの実装形態としては、コンパイラによってコンパイルされるオブジェクトコード、インタプリタにより実行されるプログラムコード等のアプリケーションプログラムに限定されることはなく、オペレーティングシステムに組み込まれるプログラムモジュール等の形態であってもよい。

さらに、プログラムは、必ずしも制御基板上のＣＰＵにおいてのみ、全ての処理が実施される必要はなく、必要に応じて基板に付加された拡張ボードや拡張ユニットに実装された別の処理ユニット（ＤＳＰ等）によってその一部又は全部が実施される構成とすることもできる。

本明細書（特許請求の範囲、要約、及び図面を含む）に記載された構成要件の全て及び／又は開示された全ての方法又は処理の全てのステップについては、これらの特徴が相互に排他的である組合せを除き、任意の組合せで組み合わせることができる。

また、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された特徴の各々は、明示的に否定されない限り、同一の目的、同等の目的、または類似する目的のために働く代替の特徴に置換することができる。したがって、明示的に否定されない限り、開示された特徴の各々は、包括的な一連の同一又は均等となる特徴の一例にすぎない。

さらに、本開示は、上述した実施形態のいずれの具体的構成にも制限されるものではない。本開示は、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された全ての新規な特徴又はそれらの組合せ、あるいは記載された全ての新規な方法又は処理のステップ、又はそれらの組合せに拡張することができる。

１０ ユーザ行動促進支援システム
１１ 支援サーバ（群）
１３ａ～１３ｃ スマートフォンあるいはタブレット端末（ユーザ端末の一形態）
１４ 携帯電話（ユーザ端末の一形態）
１５ ＰＣ（ユーザ端末の一形態）
１６ａ～１６ｃ、１７ 通信回線
１８ 公衆回線（専用線、インターネット等）
１２２ 店舗サーバ
２０２ 支援サーバの記憶部（データベース）
２０５ 支援サーバの制御部（制御装置）

Claims (14)

1. １以上のサーバと、前記１以上のサーバの少なくともいずれかのサーバに接続可能に構成された複数のユーザ端末とを有するユーザ行動促進支援システム上で実行される方法であって、
   前記サーバに、
   前記複数のユーザ端末のユーザに関するユーザ情報と、１以上のスポット及び／又はイベントに関するスタンプラリー対象情報と、前記スポット及び／又はイベントにおける前記ユーザの行動記録とをデータベースに記憶させ、
   スタンプシートに含まれる対象候補となる前記１以上のスポット及び／又はイベントを、前記ユーザ情報及び／又は前記行動記録に基づいて前記ユーザ端末のユーザごとに提示させ、
   前記ユーザ端末に、前記サーバから前記１以上のスポット及び／又はイベントが提示された場合に、前記１以上のスポット及び／又はイベントの中から１以上のスポット及び／又はイベントの選択を受け付けさせて前記サーバに送信させ、
   前記サーバに、前記選択された１以上のスポット及び／又はイベントを含むスタンプシートのスタンプシート情報を前記データベースに記憶させ、
   前記ユーザ端末に、前記選択されたスポット及び／又はイベントにおける行動を前記ユーザが行った場合にその行動記録を前記サーバへ送信させ、
   前記サーバに、前記行動記録及び前記スタンプシート情報に基づいて前記ユーザ端末のユーザに特典付与を行わせる、ことを特徴とする方法。
2. 前記スポットは店舗を含み、前記ユーザの行動は、前記ユーザによる前記店舗への訪問を含む請求項１に記載の方法。
3. 前記スポットは店舗を含み、前記ユーザの行動は、前記ユーザによる前記店舗における商品またはサービスの決済行動を含む請求項１又は２に記載の方法。
4. 前記店舗は、ウェブ上の仮想店舗を含む請求項２または３に記載の方法。
5. 前記スポットは地域あるいはエリアを含み、前記ユーザの行動は、前記ユーザによる前記地域あるいはエリアへの訪問を含む請求項１に記載の方法。
6. 前記スポットは地域あるいはエリアを含み、前記ユーザの行動は、前記ユーザによる前記地域あるいはエリアにおける所定の動作を含む請求項１又は５に記載の方法。
7. 前記ユーザの前記行動の有無は、前記ユーザ端末の位置情報に基づいて判断される請求項２、５または６のいずれか１項に記載の方法。
8. 前記特典付与は、前記決済行動の履歴に基づいて行われる請求項３に記載の方法。
9. 前記特典付与は、所定期間における次の（Ａ）～（Ｃ）の少なくとの１つの条件を満たす場合に行われる請求項２に記載の方法。
   （Ａ）前記ユーザによる前記店舗への訪問回数が閾値を超えること。
   （Ｂ）前記ユーザによる前記店舗への訪問順位が所定順位以内であること。
   （Ｃ）前記ユーザによる前記店舗への訪問時の季節、天候、時間帯に関する少なくとも１つに基づく基準。
10. 前記特典付与は、所定期間における次の（Ａ）～（Ｃ）の少なくとの１つの条件を満たす場合に行われる請求項３に記載の方法。
    （Ａ）前記ユーザによる前記店舗での決済回数、１回あたりの決済金額、決済金額合計のうち、少なくとも１つを含む決済実績が閾値を超えること。
    （Ｂ）前記ユーザによる前記店舗での決済回数、１回あたりの決済金額、決済金額合計のうち、少なくとも１つを含む決済実績の順位が所定順位以内であること。
    （Ｃ）前記ユーザによる決済時の季節、天候、時間帯に関する少なくとも１つに基づく基準。
11. 前記データベースに記録される前記スポット及び／又はイベントに関するスタンプラリー対象情報は、当該スポットのオーナー及び／又は当該イベントの主催者が個別に登録できるように制御される請求項１～１０のいずれか１項に記載の方法。
12. 前記スポットのオーナー及び／又は前記イベントの主催者による個別の登録は、個々の申請に対するサーバ管理者による承認によってなされる請求項１１に記載の方法。
13. １以上のサーバと、前記１以上のサーバの少なくともいずれかのサーバに接続可能に構成された複数のユーザ端末とを有するユーザ行動促進支援システムであって、
    前記サーバは、
    前記複数のユーザ端末のユーザに関するユーザ情報と、１以上のスポット及び／またはイベントに関するスタンプラリー対象情報と、前記スポット及び／またはイベントにおける前記ユーザの行動記録と、前記ユーザ毎のスタンプシートに関するスタンプシート情報とを記憶するデータベースと、
    前記スタンプシートに含まれる対象候補となる前記１以上のスポット及び／またはイベントの組み合わせを、前記ユーザ情報及び前記行動記録に基づいて抽出して前記ユーザ端末のユーザごとに提示するサーバ制御部と
    を有し、
    前記ユーザ端末は、前記サーバから前記１以上のスポット及び／またはイベントの組み合わせが提示されたときに当該組み合わせの中から１以上のスポット及び／またはイベントの選択を受け付けて前記サーバに送信し、
    前記サーバ制御部は、前記選択された１以上のスポット及び／またはイベントを含むスタンプシートのスタンプシート情報を前記データベースに記憶し、
    前記ユーザ端末は、前記選択されたスポット及び／またはイベントにおける行動を前記ユーザが行ったときにその行動記録を前記サーバへ送信し、
    前記サーバ制御部は、前記行動記録及び前記スタンプシート情報に基づいて前記ユーザ端末のユーザに特典付与を行う、ことを特徴とするユーザ行動促進支援システム。
14. 複数のユーザ端末と接続可能に構成されたユーザ行動促進支援サーバであって、
    前記ユーザ行動促進支援サーバは、
    前記複数のユーザ端末のユーザに関するユーザ情報と、１以上のスポット及び／またはイベントに関するスタンプラリー対象情報と、前記スポット及び／またはイベントにおける前記ユーザの行動記録と、前記ユーザ毎のスタンプシートに関するスタンプシート情報とを記憶するデータベースと、
    前記スタンプシートに含まれる対象候補となる前記１以上のスポット及び／またはイベントの組み合わせを、前記ユーザ情報及び前記行動記録に基づいて抽出して前記ユーザ端末のユーザごとに提示するサーバ制御部と
    を有し、
    前記サーバ制御部は、
    前記ユーザ端末において、前記１以上のスポット及び／またはイベントの組み合わせの中から選択された１以上のスポット及び／またはイベントを前記ユーザ端末から受信し、
    前記選択された１以上のスポット及び／またはイベントを含むスタンプシートのスタンプシート情報を前記データベースに記憶し、
    前記選択されたスポット及び／またはイベントにおける行動を前記ユーザが行ったときの行動記録を前記ユーザ端末から受信し、
    前記行動記録及び前記スタンプシート情報に基づいて前記ユーザ端末のユーザに特典付与を行う、ことを特徴とするユーザ行動促進支援サーバ。

Images