JP6147944B1 - 情報処理装置、情報処理方法、プログラム、記憶媒体 - Google Patents

Abstract

本発明では、店舗の配信目的人数に応じて適切なクーポンを配信することを目的とする。このため情報処理装置は、配信対象者を抽出するための条件として用いられる配信対象者の属性条件を店舗端末３（配信依頼者端末）から取得する属性条件取得部２ａと、店舗端末３（配信依頼者端末）が指定する店舗（施設）から所定の距離の範囲内に位置する人を配信候補者として判定する配信候補者判定部２ｂと、配信候補者のうち配信条件に適合する人を配信対象者として判定する配信対象者判定部２ｃと、配信対象者の人数を算出する人数算出部２ｄと、店舗端末３（依頼者端末）に配信対象者の人数を提示させる提示制御部２ｅと、配信要求を店舗端末３（配信依頼端末）から取得する配信要求取得部２ｆと、配信対象者のユーザ端末４に配信要求に応じた情報を配信する情報配信部２ｇと、を備えるものである。

Description

本発明は、情報処理装置、情報処理方法、プログラム及び記憶媒体に関し、特に配信対象者が事前に登録した条件に基づいてクーポンを配信するための技術に関する。

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

従来配信対象者が事前に配信を希望するクーポンを選択し、配信対象者に当該クーポンを配信するといった電子クーポン配信システムが知られている。
クーポンの配信にあたっては、クーポンの配信数を店舗の事情に応じて調整するとともに、配信したクーポンを配信対象者に効率よく使用してもらうことが重要である。
上記特許文献１には、会員端末のＧＰＳ（Global Positioning System）情報に基づいて、店舗までの距離が近い順にあらかじめ設定された人数分だけ対象者を抽出し、抽出した会員端末に対してクーポンを配信する手法が開示されている。
この手法を用いることで、例えば急にクーポンを配信してもすぐに来店できる可能性が高い配信対象者にクーポンを配信することができる。

ところで、例えば女性の配信対象者に男性服を扱う店舗のクーポンを配信しても使用される可能性があまりない、といったように、店舗までの距離が近い配信対象者であったとしても、配信されたクーポンが使用されるかどうかはわからない。
また店舗管理者がクーポンの配信を希望する配信対象者が、店舗から所定の距離の範囲内にどれくらいの人数がいるのかを把握するのは困難である。
そこで本発明では、店舗の配信目的人数に応じて適切なクーポンを配信することを目的とする。

本発明に係る情報処理装置は、配信対象者を抽出するための条件として用いられる属性条件を配信依頼者端末から取得する属性条件取得部と、前記配信依頼者端末に対応する施設から所定の距離範囲内に位置する人を配信候補者として判定する配信候補者判定部と、前記配信候補者のうち前記属性条件に適合する人を前記配信対象者として判定する配信対象者判定部と、前記配信対象者の人数を算出する人数算出部と、前記配信依頼者端末に前記配信対象者の人数を提示させる提示制御部と、配信要求を前記配信依頼者端末から取得する配信要求取得部と、前記配信対象者の端末に前記配信要求に応じた情報を配信する情報配信部と、前記施設の滞在人数を判定する滞在人数判定部と、を備え、前記配信候補者判定部は、前記施設の滞在人数に応じて、前記所定の距離範囲を変更するものである。
このような情報処理装置によるサービスを享受する配信依頼者は、任意に指定した属性情報に該当する配信対象者が、店舗の周辺に何人いるのかを確認することができる。またその後、配信依頼者は、配信依頼者端末を用いて当該配信対象者の人数に応じた配信情報の生成を情報処理装置に依頼し、当該配信情報を配信対象者に配信させることができる。
また、施設（例えば店舗）内の滞在人数によって、配信対象者と判定される人の数が変動する。

上記した情報処理装置においては、前記人数算出部は、前記施設からの異なる距離範囲ごとに前記配信対象者の人数を算出することが考えられる。
これにより、施設（例えば店舗）のスタッフ（配信依頼者）は、その施設からの各距離範囲ごとに何人の配信対象者がいるか確認することができる。

上記した情報処理装置においては、前記配信候補者判定部が判定した前記配信候補者の属性情報ごとの人数を属性人数として算出する属性人数算出部を有し、前記提示制御部は、前記属性人数を前記配信依頼者端末の端末に提示させることが考えられる。
これにより、施設（例えば店舗）のスタッフ（配信依頼者）は、自分が選択した属性条件以外の属性の人数についてどのくらいの人数がいるかを確認することができる。

上記した情報処理装置においては、前記配信候補者判定部が判定した前記配信候補者の人数の属性情報ごとの割合を属性割合として算出する属性割合算出部を有し、前記提示制御部は、前記属性割合を前記配信依頼者端末の端末に提示させることが考えられる。
これにより、施設（例えば店舗）のスタッフ（配信依頼者）は、自分が選択した属性条件以外の属性の人がどのくらいの割合でいるかを確認することができる。

上記した情報処理装置においては、前記属性割合算出部は、前記配信候補者の人数うち前記施設のジャンルごとに設定した属性情報ごとの割合を属性割合として算出することが考えられる。
これにより、店舗は、自己の店舗に関係のある属性の割合情報を閲覧することが可能となる。

本発明に係る情報処理方法は、配信対象者を抽出するための条件として用いられる属性条件を配信依頼者端末から取得するステップと、前記配信依頼者端末に対応する施設から所定の距離範囲内に位置する人を配信候補者として判定するステップと、前記配信候補者のうち前記属性条件に適合する人を前記配信対象者として判定するステップと、前記配信対象者の人数を算出するステップと、前記配信依頼者端末に前記配信対象者の人数を提示させるステップと、配信要求を前記配信依頼者端末から取得するステップと、前記配信対象者の端末に前記配信要求に応じた情報を配信するステップと、前記施設の滞在人数を判定するステップと、前記施設の滞在人数に応じて、前記所定の距離範囲を変更するステップとを情報処理装置が実行する情報処理方法である。
これにより、配信依頼者が指定した属性の人が施設（店舗）の周辺にどのくらい居るかを示すサービス、さらには配信依頼者の求めに応じて情報配信を行うサービスを提供するための情報処理装置を実現できる。
本発明に係るプログラムは、上記情報処理方法の各ステップとしての処理を情報処理装置に実行させるプログラムである。
本発明に係る記憶媒体は、上記プログラムを記憶した記憶媒体である。これらのプログラムや記憶媒体により上記の情報処理装置を実現する。

本発明によれば、例えば店舗スタッフ等の配信依頼者は、施設（店舗等）の周囲に配信対象としたい属性の人が何人いるかを容易に確認することができる。また、確認した配信対象者の人数に応じた配信情報を作成することで、より配信対象者の興味を惹く適切な情報を配信することが可能となる。これにより、配信対象者の配信情報の使用の促進及び店舗等の情報配信の効率化を図ることができる。

実施の形態のネットワークシステムの構成例についての説明図である。 実施の形態のハードウェア構成についての説明図である。 実施の形態の配信サーバについての説明図である。 実施の形態のユーザデータベースに記憶される情報の一部の説明図である。 実施の形態の位置データベースに記憶される情報の一部の説明図である。 実施の形態の店舗データベースに記憶される情報の一部の説明図である。 実施の形態の判定距離データベースに記憶される情報の一部の説明図である。 実施の形態のユーザ端末に提示される提示画面の説明図である。 実施の形態のユーザ端末に提示される提示画面の説明図である。 実施の形態のユーザ端末に提示される提示画面の説明図である。 実施の形態のユーザ端末の処理を示すフローチャートである。 実施の形態の処理の流れの一例を示す説明図である。 実施の形態の配信サーバが実行する処理の第１例を示すフローチャートである。 実施の形態の配信候補者判定処理の第１例を示すフローチャートである。 実施の形態の配信対象者判定処理を示すフローチャートである。 実施の形態の配信候補者判定処理の第２例を示すフローチャートである。 実施の形態のユーザ端末に提示される提示画面の説明図である。 実施の形態の配信候補者判定処理の第３例を示すフローチャートである。 実施の形態のユーザ端末に提示される提示画面の説明図である。 実施の形態の配信サーバが実行する処理の第２例を示すフローチャートである。 実施の形態のユーザ端末に提示される提示画面の説明図である。 実施の形態の配信サーバが実行する処理の第３例を示すフローチャートである。

以下、実施の形態を次の順序で説明する。
＜１．全体構成＞
＜２．サーバの機能構成及びデータベース＞
［２−１．サーバの機能構成］
［２−２．データベース］
＜３．店舗端末の提示画面の概要＞
＜４．ユーザ端末の処理＞
＜５．クーポンの配信に関する処理＞
［５−１．全体の処理］
［５−２．配信サーバの処理］
＜６．変形例及び他の実施例＞
［６−１．配信候補者判定処理の第２例］
［６−２．配信候補者判定処理の第３例］
［６−３．配信サーバの処理の第２例］
［６−４．配信サーバの処理の第３例］
＜７．まとめ＞
＜８．プログラム及び記憶媒体＞

＜１．全体構成＞
図１に実施の形態のネットワークシステムの構成例を示す。この例では、当該ネットワークシステムはネットワークを利用して電子クーポンを配信する電子クーポン配信システムとして機能する。図１における配信サーバが本発明請求項の情報処理装置の実施の形態に相当する。
なお、以下では「電子クーポン」を単に「クーポン」と表記する。
また実施の形態では、配信依頼者の例として店舗管理者（店舗のスタッフや経営者等）、配信依頼者端末の例として店舗管理者が使用する店舗端末を挙げる。
また配信対象者は、一般の人（ユーザ）の内でクーポン配信対象として選択された人である。ユーザ端末とは、一般ユーザがクーポンを受け取る端末をいう。

図１に示すように、本実施の形態に係るネットワークシステムは、配信サーバ２、複数の店舗端末３、複数のユーザ端末４がネットワーク１により相互に通信可能な状態で接続されている。また配信サーバ２はデータベース５にアクセス可能とされている。
なお、以下では「データベース（Database）」を「ＤＢ」と表記する。

ネットワーク１の構成は多様な例が想定される。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網などが想定される。
またネットワーク１の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線などの有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも使用可能である。

配信サーバ２は、一般ユーザの内で選択された配信対象者にクーポンを配信するサーバである。配信サーバ２は、例えば店舗管理者が配信を希望する属性条件に該当する人を配信対象者に選択して、クーポンを配信する。
配信サーバ２は店舗端末３やユーザ端末４から受信した処理要求に基づく処理を実行する。例えば属性条件の入力画面情報を店舗端末３へ送信する処理や、配信対象者の人数を提示するための画面情報を店舗端末３に送信する処理、クーポンの内容入力画面情報を店舗端末３に送信する処理、ユーザ端末４へクーポンを配信する処理、ユーザ端末４から位置情報などを受信する処理、店舗管理に係る処理、配信対象者管理に係る処理などを行う。

店舗端末３は、クーポン配信サービスを利用して配信対象者にクーポン配信を要求する店舗管理者によって操作される情報処理装置である。具体的には、店舗端末３は、或る店舗に設置されたコンピュータ装置や、店舗管理者が使用する携帯型或いは据え置き型等の情報処理装置である。
店舗端末３は、配信サーバ２から提供される属性条件入力画面や人数提示画面を提示部に提示する処理を実行する。

ユーザ端末４は、配信対象者が使用する情報処理装置である。ユーザ端末４は、配信サーバ２からクーポンの内容が提示されたクーポン内容画面情報を取得する。またユーザ端末４は、ユーザ端末４の位置情報を取得し、配信サーバ２に送信する。ユーザ端末４は、例えば通信機能を備えたＰＣ（Personal Computer）やフィーチャーフォンやＰＤＡ（Personal Digital Assistant）、或いはスマートフォンやタブレット端末などのスマートデバイスなどにより実現される。但し本実施の形態の場合、ユーザ端末４は、ユーザが所持して行動する携帯型の端末であることを想定している。

本実施形態の場合、例えば、配信サーバ２ではＨＴＴＰ（Hypertext Transfer Protocol）デーモンが起動される。また店舗端末３ではブラウザが起動され、店舗端末３からは、ブラウザを介して処理要求（ＨＴＴＰリクエスト）が配信サーバ２に送信される。配信サーバ２からは、上記の処理要求に対応する処理結果（ＨＴＴＰレスポンス）が店舗端末３に送信される。例えば、ウェブページ記述言語で記載されたページデータが店舗端末３に送信される。そして、このページデータに基づいて、処理結果に基づくウェブページ（画面）が店舗端末３の提示制御部に提示される。
配信サーバ２は、このような動作により店舗端末３への属性条件入力画面情報（属性条件入力画面のウェブページデータ）の送信、人数提示画面情報（人数提示画面のウェブページデータ）の送信、店舗端末３からの要求に応じた処理を行う。また、配信サーバ２は、同様の動作で、ユーザ端末４にクーポン提示画面を提示させる。

これらのウェブページデータは、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible Hyper Text Markup Language）などの構造化文書ファイルである。構造化文書ファイルには、記事などのテキストデータや記事に添付された画像などの画像データと、それらの配置や提示態様（文字色、フォント、大きさ及び装飾など）が記述されている。

ＤＢ５は、配信サーバ２が配信対象者にクーポンを配信するために必要な情報が格納されたＤＢを包括的に示している。ＤＢ５の詳細については後述する。

続いて、図１に示した配信サーバ２、店舗端末３、ユーザ端末４、ＤＢ５を構成する情報処理装置のハードウェア構成を図２に示す。配信サーバ２、店舗端末３、ユーザ端末４、ＤＢ５として示した各装置は、情報処理及び情報通信が可能な図２に示すようなコンピュータ装置として実現できる。

図２において、コンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ( Read Only Memory)１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ( Random Access Memory )１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、及びＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
入出力インターフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力部１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力部１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、ネットワーク１を介しての通信処理や機器間通信を行う通信部１０９が接続されている。
入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介してデータやプログラムを受け渡したりすることが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、配信サーバ２、店舗端末３、ユーザ端末４、ＤＢ５としての必要な情報処理や通信が実行される。
なお、配信サーバ２、店舗端末３、ユーザ端末４、ＤＢ５を構成する情報処理装置は、図２のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮなどによりシステム化されていてもよいし、インターネットなどを使用したＶＰＮなどにより遠隔地に通信可能な状態で配置されたものでもよい。

＜２．サーバの機能構成及びデータベース＞
［２−１．サーバの機能構成］

図３に一又は複数の情報処理装置で構成される配信サーバ２としての機能構成を示す。
配信サーバ２としての各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される。但し以下説明する全部又は一部の各構成の処理をハードウェアにより実現してもよい。
また各機能をソフトウェアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。

配信サーバ２は、属性条件取得部２ａ、配信候補者判定部２ｂ、配信対象者判定部２ｃ、人数算出部２ｄ、提示制御部２ｅ、配信要求取得部２ｆ、情報配信部２ｇ、滞在人数判定部２ｈ、属性人数算出部２ｉ、属性割合算出部２ｊを有する。

属性条件取得部２ａは、店舗管理人が配信を希望する配信対象者を特定するための条件として用いられる配信対象者の属性条件を店舗端末３から取得する。具体的には、属性条件取得部２ａは、店舗管理者が操作により入力した属性条件情報を店舗端末３から受信する。例えば店舗管理者が属性条件として「男性」、「２０代」、「会社員」といった属性条件を入力すると、当該属性条件が店舗端末３から属性条件取得部２ａに送信される。

配信候補者判定部２ｂは、店舗端末３に対応する施設から所定の距離範囲内に位置する人を配信候補者として判定する。具体的には、配信候補者判定部２ｂは、位置ＤＢ５ｂからユーザの位置情報を取得し、施設（店舗）から所定の距離の範囲内にいるユーザを抽出することで、配信候補者を判定する。配信候補者とは、ユーザのうち判定距離範囲内にいる者をいう。配信候補者の判定処理の詳細については後述する。
なお、配信依頼者端末としての店舗端末３に対応する施設（店舗）とは、その店舗端末３を用いる店舗管理者が、配信サーバ２が提供するサービスにログインした場合に、その店舗管理者のＩＤもしくは店舗端末３のＩＤに対応して登録されている施設（店舗等）であるとする。つまり、店舗管理者がログインした状態で、位置が特定される店舗のことを、ここでは「店舗端末３に対応する施設（店舗）」としている。

配信対象者判定部２ｃは、配信候補者のうち属性条件に適合する人を配信対象者として判定する。具体的には、配信対象者判定部２ｃは、ユーザＤＢ５ａから取得した配信候補者の属性情報と、店舗端末３から受信した属性条件情報を参照する。そして配信対象者判定部２ｃは、店舗端末３から受信した属性情報を有する配信候補者を配信対象者として判定する。例えば、店舗管理者が配信希望属性として「男性」、「２０代」、「会社員」といった属性情報を店舗端末３に入力した場合、配信候補者から「男性」、「２０代」、「会社員」といった属性情報を有する配信対象者を配信対象者として判定する。

人数算出部２ｄは、配信対象者の人数を算出する。具体的には、人数算出部２ｄは、配信対象者判定部２ｃが判定した配信対象者の人数を算出する。

提示制御部２ｅは、クーポン配信システムを構成する各種ウェブページデータの生成（ＨＴＭＬデータ生成）を行う。例えば配信対象者の人数を提示させる対象人数画面情報やクーポンの内容画面情報などの各種ウェブページデータの生成を行う。

配信要求取得部２ｆは、配信要求を店舗端末３から取得する。具体的には、配信要求取得部２ｆは、店舗管理者が店舗端末３に入力したクーポン情報を店舗端末３から受信する。例えば、配信要求取得部２ｆは、「受け取った人に限り、全品３０％オフ、本日限り有効」などの店舗管理者が配信を希望するクーポン内容を店舗端末３から受信する。
なお、店舗端末３から配信要求されたクーポン情報は、編集前のクーポン内容であってもよいし、すぐに配信できるような編集済みのクーポンであってもよい。

情報配信部２ｇは、配信対象者のユーザ端末４にクーポン内容情報を送信する。具体的には、情報配信部２ｇは、配信要求取得部２ｆが受け取ったクーポン内容に応じたクーポン画像を生成したり、或いは当該クーポン内容に該当するクーポン画像をウェブページＤＢ５ｄから取得するなどして、クーポン画像を含む情報、例えば電子メール情報等を生成し、当該情報をユーザ端末４に送信する。

滞在人数判定部２ｈは、店舗に滞在する人の人数を判定する。つまり店舗内の客の数である。なお、必ずしも正確な人数を判定する必要はない。
属性人数算出部２ｉは、例えば店舗の周辺に居る人として判定された配信候補者の人数に対する属性ごとの人数を属性人数として算出する。
属性割合算出部２ｊは、例えば店舗の周辺に居る人として判定された配信候補者の人数に対する属性ごとの人数の割合を属性割合として算出する。

［２−２．データベース］

以下これらの機能を備えた配信サーバ２が、配信候補者や配信対象者の判定、ユーザ端末４における配信内容の提示などを行うために用いるＤＢ５について説明する。

ＤＢ５は、例えばユーザ端末４及びユーザ端末４を所持するユーザに関するデータが記憶されるユーザＤＢ５ａ、ユーザ端末４の位置情報などが記憶される位置ＤＢ５ｂ、店舗端末３及びその店舗に関するデータが記憶される店舗ＤＢ５ｃ、店舗端末３及びユーザ端末４に提示する様々なウェブページデータが記憶されているウェブページＤＢ５ｄ、店舗に滞在する顧客の人数に応じた所定の距離のデータが記憶されている判定距離ＤＢ５ｅなどで構成されている。もちろんこれ以外にもＤＢ５は、インターネットの配信サーバ２として機能するために必要なＤＢを含んで構成されていてもよい。

ユーザＤＢ５ａは、例えば図４に示すように、クーポン配信サービスを利用するユーザ端末４を所持するユーザに関するデータが記憶される。例えば、ユーザ識別情報であるユーザＩＤ（identification）に対して、閲覧履歴情報、住所、氏名、性別や年齢などの属性情報、電子メールアドレスなどが紐付けられて記憶される。
なお、属性情報は性別、年齢、職業に限られることなく、趣味、好きな食べ物、性格など様々な属性情報を属性条件として記憶されていてもよい。
またユーザＤＢ５ａに登録されるユーザは、例えば配信サーバ２が提供するクーポン配信等のサービスを受けるために登録されたユーザなどであり、ユーザＩＤは当該登録に応じて付与されるものとすれば良い。

位置ＤＢ５ｂは、各ユーザの現在位置を登録するＤＢである。例えば図５に示すように位置ＤＢ５ｂには、ユーザＩＤ毎に、位置情報、当該位置情報の受信日時、配信候補者フラグ、配信対象者フラグなどが記憶される。
例えば配信サーバ２は、ユーザ端末４から位置情報を受信する度に、そのユーザＩＤに対応させて、位置情報及び受信日時を更新していく。即ち配信サーバ２は、携帯端末位置情報をユーザの位置情報として受信し、当該携帯端末位置情報に基づいて位置ＤＢ５ｂを更新する。携帯端末位置情報とは、ユーザが所持して行動する携帯型のユーザ端末４の位置情報である。位置情報は緯度情報と経度情報を有する。
このために、ユーザ端末４はビーコン（Beacon）やＧＰＳ（Global Positioning System）からビーコンＩＤやＧＰＳ位置情報などを取得し、当該情報を配信サーバ２に送信し、配信サーバ２は当該情報をから位置情報を特定する。
例えばＧＰＳ位置情報を用いる場合、ユーザ端末４は、例えば定期的に、ＧＰＳ受信器で受信した情報から現在位置としての緯度情報や経度情報を取得し、それを配信サーバ２に送信する。
またビーコンを用いる場合、ユーザ端末４は、ビーコンから特定の範囲内に位置するとビーコンＩＤを取得する。ユーザ端末４は当該ビーコンＩＤを配信サーバ２に送信し、当該ビーコンＩＤを受信した配信サーバ２は、ビーコンＩＤに基づいて位置情報を取得する。 位置ＤＢ５ｂにおける配信候補者フラグは、後述の配信候補者判定処理で配信候補者と判定されたか否かを示すフラグである。具体的には、配信サーバ２は、店舗端末３に対応する施設から所定の距離範囲内に位置する配信候補者を、携帯端末位置情報に基づいて判定する。
配信対象者フラグは、後述の配信対象者判定処理で配信対象者と判定されたか否かを示すフラグである。

店舗ＤＢ５ｃは、図６に示すように、ユーザへのクーポンの配信を希望する店舗に関するデータが記憶される。例えば各店舗について、店舗識別情報としての店舗ＩＤ、店舗名、住所、電話番号、及び店舗に関するウェブページへのリンク情報（ＵＲＬ（Uniform Resource Locator））、配信候補者を判定する店舗からの距離範囲を指定した判定距離情報、などが記憶される。
なお、各店舗の店舗ＩＤは、店舗管理者のログインＩＤに紐づけられるなどして、店舗管理者と対応づけられている。

ウェブページＤＢ５ｄには、クーポン配信サービスを構成する様々なウェブページデータがウェブページのリンク情報（ＵＲＬ）に紐付けられて記憶されている。例えばログイン画面のウェブページデータやウェブサイトのウェブページデータ、属性入力画面情報、人数提示画面情報、クーポン画面情報などが挙げられる。

判定距離ＤＢ５ｅには、図７に示すように、店舗ＩＤごとに滞在人数情報とその人数に応じた判定距離情報が記憶されている。判定距離情報は、あらかじめ店舗管理者が店舗端末３を操作して登録要求することで、配信サーバ２が判定距離ＤＢ５ｅに記憶させる。
なお、判定距離情報は、このように店舗管理者が登録操作で設定するものに限られず、配信サーバ２によりあらかじめ決められていてもよい。

以上の各ＤＢを有するＤＢ５は、配信サーバ２とは別のサーバコンピュータ内に構築されていてもよいし、配信サーバ２内に構築されていてもよい。
また図示及び説明の便宜上、ＤＢ５として示したが、ユーザＤＢ５ａ、位置ＤＢ５ｂ、店舗ＤＢ５ｃ、ウェブページＤＢ５ｄ、判定距離ＤＢ５ｅの各ＤＢは、配信サーバ２がアクセス可能とされていればどのような形態で実現されていてもよい。例えば配信サーバ２と同一システム内の記憶部に各ＤＢのすべてが形成されていてもよいし、各ＤＢの一部又は全部が別体、遠隔地などのコンピュータシステムに設けられていてもよい。もちろん各ＤＢが一つの装置（例えば一つのＨＤＤなど）内に形成されている必要はない。また各ＤＢのそれぞれが、それぞれ１つのＤＢとして構成される必要もない。例えばユーザＤＢ５ａとして記憶される情報が、複数の配信対象者ＤＢ（例えばログイン用の配信対象者ＤＢと取引用の配信対象者ＤＢなど）により記憶管理されてもよい。実施の形態で説明する上記各ＤＢは、実施の形態の処理に関連する情報の記憶部を、それぞれ一つのＤＢの形態で例示したものに過ぎない。

＜３．店舗端末の提示画面の概要＞

以下本実施の形態の店舗がクーポン配信システムを使用する場合に、配信サーバ２によって店舗端末３に提示される画面の一例について図８乃至図１０を参照して説明する。

店舗端末３には、図８に示すように、店舗管理者が属性条件を入力する画面である属性条件入力画面１０が提示される。
属性条件入力画面１０は、属性条件情報を入力する属性入力エリア１１、１１、１１…と配信対象者の属性条件を配信サーバ２に送信する属性送信ボタン１２を有する。
属性入力エリア１１、１１、１１…は、店舗管理者が配信を希望する属性条件を操作（タッチ、クリック、キーボード操作等）により入力する。例えば店舗管理者は、属性入力エリア１１、１１、１１に「男性」かつ「２０代」かつ「会社員」といった属性条件を入力する。属性条件の入力には例えばプルダウンが用いられ、店舗管理者は、プルダウンに提示された項目から属性条件を選択することができる。
属性送信ボタン１２は、属性入力情報の入力が完了したときに属性条件を送信するために店舗管理者により操作されるボタンである。
なお、図示していないが、配信候補者を判定するための判定距離範囲の入力エリアを設け、この属性入力画面において店舗管理者が自ら判定距離範囲を設定することができることとしてもよい。これにより店舗管理者が知りたい距離の範囲内の配信対象者の人数を容易に知ることができるため店舗管理者の利便性の向上を図ることができる。

店舗端末３には、図９に示すように、配信対象者の人数が人数提示画面２０に提示される。この人数提示画面２０では、例えば店舗を中心とした周囲１００ｍの範囲に、配信対象者が５０人居ることなどが提示される。
人数提示画面２０は、店舗管理者が再度属性条件を送信したいときに操作する再入力ボタン２１と、店舗管理者が配信対象者を決めたときに操作する対象決定ボタン２２を有する。
再入力ボタン２１は、例えば店舗管理者が、「配信対象者が想定よりも少なかったため属性情報を再入力したい」といった場合などに操作される。これにより、店舗管理者は、納得できる配信対象人数になるまで再度属性条件を入力することができる。
また対象決定ボタン２２は、店舗管理者が配信対象者の人数をみて、それで良いと判断し、クーポン内容を入力する場合に操作するボタンである。即ち店舗管理者は、店舗の周囲の特定の距離範囲内における、指定した属性に該当する配信対象者の人数を確認して、それらの人に対してクーポンを配信したいと決心した場合に、対象決定ボタン２２を操作する。

店舗端末３には、図１０に示すように、店舗端末３は、クーポン内容を入力するクーポン内容入力画面３０が提示される。
クーポン内容入力画面３０は、配信するクーポン内容を入力する内容入力エリア３１と配信するクーポン内容を配信サーバ２に送信するための内容送信ボタン３２を有する。
このクーポン内容入力画面３０は、上記の対象決定ボタン２２を操作した後に提供される画面である。店舗管理者は、先に人数提示画面２０で表示された人数に応じてクーポン内容を考えることができる。例えば所定の距離範囲内に入力した属性条件に該当する配信対象者が少ない場合は「３０％割引」に、該当する配信対象者が多い場合は「１０％割引」に割引率を変えるなど店舗の周辺にいる人数に応じた柔軟な内容のクーポン配信検討することができる。
店舗管理者は、内容入力エリア３１に、例えば「受け取った人に限り、全品３０％オフ、本日限り有効」などのクーポンの内容を入力する。入力後、店舗管理者が内容送信ボタン３２を操作すると、そのクーポンの内容が店舗端末３から配信サーバ２に送信される。
なお、内容送信ボタン３２を操作する際に、例えば配信対象者の属性、人数、クーポン内容が提示された確認画面が提示され、そこで配信決定を選択することで、店舗端末３から配信サーバ２にクーポン内容の情報が送信されるようにしても良い。

＜４．ユーザ端末の処理＞

ユーザの位置情報を送信する処理としてユーザ端末４が実行する処理について図１１を参照して説明する。
ユーザ端末４は、図１１に示す処理を実行することにより現在のユーザの位置情報を定期的に配信サーバ２に送信する。

まず、ユーザ端末４は、ステップＳ４０１において、位置情報を受信したか否かを判定する処理を行う。
例えばユーザ端末４は、前述のように、現在位置情報をビーコンやＧＰＳ情報などを用いて取得する。

位置情報を受信していないと判定した場合、ユーザ端末４は、ステップＳ４０１の処理を継続して行う。

位置情報を取得したと判定した場合、ユーザ端末４は、ステップＳ４０１からＳ４０２に処理を進め、位置情報送信処理を行う。例えばユーザ端末４は、取得した緯度情報や経度情報等の位置情報をユーザＩＤとともに配信サーバ２に送信する。
これに応じて配信サーバ２は、位置ＤＢ５ｂの更新を行う。つまり受信したユーザＩＤに対応させて位置情報を更新し、また受信日時を現在（受信時）の日時に更新する。

続いて、ユーザ端末４は、ステップＳ４０３において、位置情報送信処理を行ってから一定時間が経過したか否かについて判定する。
位置情報送信処理を行ってから一定時間が経過したと判定した場合、ユーザ端末４は、ステップＳ４０３からＳ４０１に処理を進め、以下同様の処理を行う。
なお、一定時間については特に限定されることはなく、例えば１０秒や５分等に設定することが考えられる。
多数のユーザ端末５が以上の処理を行うことで、位置ＤＢ５ｂには、各ユーザの最新の位置情報が登録されることになる。
例えばユーザ端末５では、配信サーバ２のサービスを享受するためのアプリケーションソフトウェアが起動されているときに、常時図１１の処理を行うことが考えられる。

＜５．クーポンの配信に関する処理＞

以下、配信サーバ２によるクーポン配信サービスに関する処理例を説明する。なお、以下の説明における配信サーバ２の処理は、図３に示した属性条件取得部２ａ、配信候補者判定部２ｂ、配信対象者判定部２ｃ、人数算出部２ｄ、提示制御部２ｅ、配信要求取得部２ｆ、情報配信部２ｇ、滞在人数判定部２ｈ、属性人数算出部２ｉ、属性割合算出部２ｊとしての各機能が連携して実行されるものである。

［５−１．全体の処理］

図１２は、配信サーバ２と店舗端末３が実行する処理の流れの一例を示している。ここでは、配信サーバ２が提供する配信サービスを利用するために、店舗管理者が店舗端末３を用いてクーポンの配信要求をする例を説明する。なお、店舗管理者が店舗端末３を用いて配信サーバ２が提供するサービスにログインしている状態であるとする。

店舗端末３は、ステップＳ３１において、配信サーバ２に属性条件を入力するための入力画面情報要求処理を行う。

入力画面情報要求を店舗端末３から受信すると、配信サーバ２は、ステップＳ２１において、入力画面情報送信処理を行う。即ち配信サーバ２は店舗端末３において属性条件入力画面１０を表示させる。

その後、属性条件入力画面１０に対する店舗管理者による入力等の操作に応じて、店舗端末３は、ステップＳ３２において、属性条件情報を配信サーバ２に送信する属性情報送信処理を行う。

店舗端末３から配信サーバ２へ属性条件情報が送信されると、配信サーバ２は、ステップＳ２２において、配信候補者を判定する配信候補者判定処理を行う。
次に配信サーバ２は、ステップＳ２３において、配信対象者を判定する配信対象者判定処理を行う。
そして配信対象者を判定すると、配信サーバ２は、ステップＳ２４において、判定された配信対象者の人数を算出する人数算出処理を行う。

人数算出処理により配信対象者の人数を算出すると、配信サーバ２は、ステップＳ２５において、算出した配信対象者の人数を提示する人数提示画面２０の画面情報を店舗端末３に送信する。

店舗端末３において人数提示画面２０を確認した店舗管理者が、対象決定ボタン２２を操作すると、店舗端末３は、ステップＳ３３において、クーポン内容を入力する画面情報を要求する処理を行う。

クーポン内容を入力する画面情報の要求を受信すると、配信サーバ２は、ステップＳ２６において、クーポン内容入力画面３０の画面情報を店舗端末３に送信する処理を行う。

その後、店舗端末３においてクーポン内容入力画面３０に対し、店舗管理者がクーポン内容を入力して内容送信ボタン３２を操作すると、店舗端末３は、ステップＳ３４において、配信サーバ２にクーポン内容情報を送信する。このクーポン内容情報の送信は、ユーザ端末４へのクーポン配信をすることの要求としての意味も持つ（配信要求）。

店舗端末３からクーポン内容情報を受信すると、配信サーバ２は、ステップＳ２７において、クーポン内容情報に応じたクーポンのデータを生成し、ユーザ端末２にクーポンを配信する（配信処理）。

以上が配信サーバ２が提供するサービスにおける処理の、一般的な流れとなる。

［５−２．配信サーバの処理］

以上のようなクーポン配信サービスを実現するために配信サーバ２が行う処理の第１例について図１３を参照して説明する。

配信サーバ２は、ステップＳ１０１、Ｓ１１１、Ｓ１２１、Ｓ１３１、Ｓ１４１において、店舗端末３やユーザ端末４から送信される店舗管理者の操作情報や配信対象者の位置情報などを受信したか否かを判定する処理を行う。

ステップＳ１０１において、配信サーバ２が、店舗端末３から属性条件を入力する画面情報の要求を受信したと判定した場合、配信サーバ２は、ステップＳ１０１からＳ１０２に処理を進め、属性入力画面提示処理を行う。
具体的には配信サーバ２は、ウェブページＤＢ５ｄから属性入力画面の画面情報（ウェブページデータ）を取得し、店舗端末３に当該画面情報を送信する。店舗端末３では当該画面情報を受信することに応じて、属性条件入力画面１０を表示する（図８）。

配信サーバ２は、ステップＳ１１１において、店舗端末３から属性条件情報を受信したと判定した場合、ステップＳ１１１からＳ１１２に処理を進め、配信候補者判定処理を行う。
具体的には配信サーバ２は、位置ＤＢ５ｂからユーザの位置情報を取得し、そのうち店舗から所定の距離の範囲内にいるユーザを配信候補者として判定する。
またこのとき配信サーバ２は、位置ＤＢ５ｂにおいて配信候補者と判定されたユーザに配信候補者フラグをオンにする処理を行う。配信候補者フラグがオンのユーザは、配信候補者であることを示している。
所定の距離については、店舗管理者が店舗端末３から入力して登録要求しておくことで配信サーバ２が店舗ＤＢ５ｃに記憶させている。
なお、判定距離情報については配信サーバ２が固定値として決めておいても良い。

ここで、配信候補者判定処理（Ｓ２２、Ｓ１１２）の第１例について図１４を参照して説明する。

まず配信サーバ２は、ステップＳ２０１において、位置ＤＢ５ｂにおける全ユーザの配信候補者フラグをオフとする。

配信サーバ２は、ステップＳ２０２において、判定距離範囲を決定する判定距離決定処理を行う。例えば配信サーバ２は、店舗ＤＢ５ｃから判定距離情報を取得することで判定距離範囲を決定する。上記のように判定距離範囲を固定値として取得してもよい。

配信サーバ２は、ステップＳ２０３において、処理対象のユーザを特定する。即ち位置ＤＢ５ｂにエントリされているユーザの内の一人を処理対象として選択する。
そして配信サーバ２は、ステップＳ２０４において、選択したユーザが判定距離の範囲内に位置しているか否かを判定する。具体的には配信サーバ２は、当該ユーザの位置情報を取得し、例えば店舗ＤＢ２ｃに記憶された判定距離情報に基づいてユーザが判定距離の範囲内に位置するか否かを判定する。
つまり当該ユーザの位置情報が、店舗の所在地から判定距離範囲内にあるか否かを確認する。
なお、ここで、位置ＤＢ５ｂに登録された当該ユーザの位置情報については、受信日時の情報が所定時間以上過去である場合は、有効な位置情報として用いないことが適切である。即ち、ユーザの現在位置は常に変動しており、一方で、ユーザ端末４からの位置情報送信が必ず常時実行されているとは限らないためである。
例えば受信日時が現在より１時間前より過去である場合などは、その位置情報は無効とし、仮に店舗の近傍の位置であったとしても、判定距離範囲内とはしない。１時間とは一例であり、より精度を高めるには１０分、５分などとしてもよいし、場合によっては２時間等としてもよい。

対象のユーザが判定距離の範囲内に位置していると判定した場合、配信サーバ２は、ステップＳ２０４からＳ２０５に処理を進め、位置ＤＢ５ｂにおいて当該ユーザについて配信候補者フラグをオンとする。
対象のユーザが判定距離の範囲内に位置していない判定した場合、配信サーバ２は、ステップＳ２０４からＳ２０６に処理を進める。つまり配信候補者フラグをオフのままとする。

配信サーバ２は、ステップＳ２０６で、全ユーザについて配信候補者の判定が完了しているか否かを判定する。

全ユーザについて配信候補者の判定が完了していない場合、配信サーバ２は、ステップＳ２０６からＳ２０３に処理を進め、以下同様の処理を行う。つまり、位置ＤＢ５ｂにエントリされている次のユーザを処理対象とし、同様の処理を行う。
全ユーザについて配信候補者の判定が完了している場合、配信サーバ２は、図１４に示す処理を終了し、続いて図１３の配信対象者判定処理（Ｓ２３、Ｓ１１３）に進む。
この時点で、配信候補者フラグがオンとされたユーザが、配信候補者と判定されたユーザとなる。

以上のように配信候補者を判定すると、続いて配信サーバ２は、図１３のステップＳ１１３において、店舗管理者が入力した属性情報に基づいて配信対象者を判定する配信対象者判定処理を行う。
具体的には配信サーバ２は、配信候補者フラグによって示された配信候補者のうちで、受信した属性条件情報を有する人を配信対象者と判定する。

配信対象者判定処理（Ｓ２３、Ｓ１１３）の具体例を図１５を参照して説明する。
配信サーバ２はステップＳ３０１において、位置ＤＢ５ｂにエントリされている全ユーザの配信対象者フラグをオフにする処理を行う。

配信サーバ２は、ステップＳ３０２において、属性条件取得処理を行う。具体的には配信サーバ２は、店舗端末３からの受信データとしての属性条件情報をを取得する。例えば配信サーバ２は、店舗管理者が店舗端末３を介して属性入力画面１０に入力した「男性」、「２０代」、「会社員」などの属性条件情報を取得する。

配信サーバ２は、ステップＳ３０３において、配信候補者のなかから一人のユーザを処理対象として選択する。具体的には配信サーバ２は、位置ＤＢ５ｂにおいて配信候補者フラグがオンになっているユーザのなかから一人のユーザを抽出する。

配信サーバ２は、ステップＳ３０４において、処理対象の配信候補者の属性情報の確認を行う。具体的には、配信サーバ２は、該配信候補者のユーザＩＤに基づいてユーザＤＢ５ａを検索し、当該配信候補者の属性情報を取得する。

配信サーバ２は、ステップＳ３０５において、当該配信候補者の属性が店舗端末３から受信した属性条件情報に該当するか否かを判定する。

当該配信候補者の属性が店舗端末３から受信した属性条件情報に該当すると判定した場合、配信サーバ２は、ステップＳ３０５からＳ３０６に処理を進め、位置ＤＢ５ｂにおいて配信対象者フラグをオンとする。
当該配信候補者の属性が店舗端末３から受信した属性条件情報に該当しないと判定した場合、配信サーバ２は、ステップＳ３０５からＳ３０７に処理を進める。つまり配信対象者フラグをオフのままとする。

配信サーバ２は、ステップＳ３０７で、全配信候補者について配信対象者の判定が完了しているか否かを判定する。

全配信候補者について配信対象者とするか否かの判定が完了していない場合、配信サーバ２は、ステップＳ３０７からＳ３０３に処理を進め、同様の処理を行う。つまり、配信候補者とされている次のユーザを処理対象とし、同様の処理を行う。
全配信候補者について配信対象者の判定が完了した場合、配信サーバ２は、図１５に示す処理を終了し、続いて図１３の人数算出処理（Ｓ２４、Ｓ１１４）に進む。
この時点で、配信対象者フラグがオンとされたユーザが、配信対象者と判定されたユーザとなる。

配信サーバ２は、ステップＳ１１４において、配信対象者の人数を算出する人数算出処理を行う。

そして、人数算出処理により配信対象者の人数を算出すると、配信サーバ２は、ステップＳ１１５において、算出した配信対象者の人数情報を用いて、人数提示画面２０のウェブページデータを生成し、当該ウェブページデータを店舗端末３に送信する。これにより店舗端末３上に人数提示画面２０が提示される（図９）。

店舗端末３からクーポン内容入力画面３０の要求を受信したと判定した場合、配信サーバ２はステップＳ１２１からステップＳ１２２に処理を進め、クーポン内容入力画面情報送信処理を行う。
具体的には、配信サーバ２は、ウェブページＤＢ５ｄからクーポン内容入力画面情報を取得して当該画面情報を店舗端末３に送信することで、店舗端末３上にクーポン内容入力画面３０を提示させる（図１０）。

配信サーバ２は、ステップＳ１３１において店舗端末３からクーポン内容情報（クーポンの配信要求）を受信したと判定した場合、ステップＳ１３１からＳ１３２に処理を進め、クーポンの配信処理を行う。
具体的には、配信サーバ２は、ウェブページＤＢ５ｄから取得したクーポン画面情報と受信したクーポン内容に応じてクーポン画面情報を生成する。そして例えば電子メール等によりクーポンをユーザ端末４に送信する。送信するユーザ端末４とは、配信対象者フラグがオンとされたユーザのユーザ端末４である。
これにより、配信要求を行った店舗管理者の店舗の近傍に居て、かつ店舗管理者が指定した属性を有するユーザのユーザ端末４上に、店舗管理者が設定した内容のクーポンが表示されることになる。

配信サーバ２は、ステップＳ１４１において、ユーザ端末４から位置情報を受信したか否かを判定する処理を行う。
配信サーバ２は、ユーザ端末４から位置情報を受信したと判定した場合、ステップＳ１４１からＳ１４２に処理を進め、位置ＤＢ更新処理を行う。
具体的には、配信サーバ２は、図１１の処理として定期的に多数のユーザ端末４から送信される当該位置情報を受信し、受信毎に位置ＤＢ５ｂにユーザＩＤに対応して当該位置情報を記憶する。

＜６．変形例及び他の実施例＞
［６−１．配信候補者判定処理の第２例］

配信候補者判定処理（Ｓ２２、Ｓ１１２）の第２例について図１６を参照して説明する。なお、図１４と同様の処理については同一符号を付し、説明を省略する。
この第２例は第１例（図１４）とはステップＳ２１０の滞在人数判定処理とステップＳ２１１の判定距離決定処理が異なるものである。例えば店舗に滞在する顧客の人数である滞在人数に応じて配信候補者を判定する距離を変動させる処理である。

配信サーバ２は、ステップＳ２１０において、滞在人数を判定する滞在人数判定処理を行う。
滞在人数を判定する手法としては、例えば店舗内に設置したビデオカメラと撮影した映像から人物を解析する画像解析ソフトを用い、滞在人数を算出する手法や、店舗の出入口にセンサーを設置し、入店者と退店者の人数を把握することで、滞在人数を算出する手法などが考えられる。
そして例えば店舗端末３等が、滞在顧客人数を１０秒や５分等の短い間隔で定期的に算出し、当該滞在顧客人数を配信サーバ２に送信する。

配信サーバ２は、ステップＳ２１１において、配信候補者を判定するために用いる店舗からの距離範囲である判定距離範囲を決定する判定距離決定処理を行う。具体的には、配信サーバ２は、滞在人数に応じて判定距離ＤＢ５ｅから判定距離範囲情報を取得する。例えば図７に示すように店舗での顧客の滞在人数が「１１〜２０人」である場合、配信サーバ２は、判定距離範囲として滞在人数ＤＢ５ｅから「２００ｍ」を取得する。

ステップＳ２０３以降は図１４と同様である。従って、店舗内が混んでいるときと空いているときなどで、配信候補者の条件とする距離範囲が変化されることになる。
例えば空いているときは、距離範囲を広げ、配信候補者が多くなるようにし、逆に混んでいるときは距離範囲を狭め、配信候補者が少なくなるようにすることができる。

［６−２．配信候補者判定処理の第３例］

配信候補者判定処理（Ｓ２２、Ｓ１１２）の第３例について図１７及び図１８を参照して説明する。なお、図１４と同様の処理については、説明を省略する。この変形例はステップＳ１１２の変形例であり、例えば図１７に示すように、店舗から「１００ｍ」、「２００ｍ」、「３００ｍ」と、一定の距離ごとに配信候補者を判定したいときに用いる処理である。図１７においては、人数提示画面２０ａにおいて、判定距離と判定距離ごとの配信対象者の人数が２０ｂ、２０ｂ、２０ｂとして提示されている。
また本例の場合、位置ＤＢ５ｂには判定距離としての「１００ｍ」、「２００ｍ」、「３００ｍ」のそれぞれに配信候補者フラグが設けられている。
つまり位置ＤＢ５ｂには、各ユーザに対応して「１００ｍ配信候補者フラグ」、「２００ｍ配信候補者フラグ」、「３００ｍ配信候補者フラグ」と「配信対象者フラグ」が用意される。

まず配信サーバ２は、ステップＳ２２１において、全ユーザの「１００ｍ配信候補者フラグ」、「２００ｍ配信候補者フラグ」、「３００ｍ配信候補者フラグ」を全てオフとする。

配信サーバ２は、ステップＳ２２２において、判定距離範囲を「３００ｍ」に決定し、ステップＳ２２３において、処理対象のユーザを特定する。即ち位置ＤＢ５ｂにエントリされているユーザの内の一人を処理対象として選択する。

配信サーバ２は、ステップＳ２２４において、選択したユーザが店舗から「３００ｍ」の範囲内に位置しているか否かを判定する。具体的には配信サーバ２は、位置ＤＢ５ｂから判定するユーザの位置情報を取得し、ユーザが店舗から「３００ｍ」の範囲内（判定距離範囲内）に位置するか否かを判定する。
なお、図１４で説明した場合と同様、受信日時の情報が所定時間以上過去である場合は、そのユーザの位置情報は有効な位置情報として用いないことが適切である。

該ユーザが店舗から「３００ｍ」の範囲内に位置していると判定した場合、配信サーバ２は、ステップＳ２２４からＳ２２５に処理を進め、位置ＤＢ５ｂの「３００ｍ配信候補者フラグ」をオンとする。
該ユーザが店舗から「３００ｍ」の範囲内に位置していない判定した場合、配信サーバ２は、ステップＳ２２４からＳ２２５に処理を進める。つまり「３００ｍ配信候補者フラグ」をオフのままとする。

このような処理を、ステップＳ２２６で全ユーザについて３００ｍでの配信候補者の判定が完了していると判断されるまで、各ユーザについて実行する。

全ユーザについて３００ｍでの配信候補者の判定が完了したら、配信サーバ２は、ステップＳ２２２ａに処理を進める。
配信サーバ２は、ステップＳ２２２ａにおいて、判定距離範囲を「２００ｍ」に決定し、ステップＳ２２３ａ、Ｓ２２４ａ、Ｓ２２５ａ、Ｓ２２６ａの処理を行う。
つまり判定距離範囲を変更した上で、上記ステップＳ２２３〜Ｓ２２６と同様の処理を行い、２００ｍ範囲内に居るユーザについて「２００ｍ配信候補者フラグ」をオンとする処理を行う。

さらにステップＳ２２６ａで全ユーザについて２００ｍでの配信候補者の判定が完了していると判断されたら、配信サーバ２は、ステップＳ２２２ｂに処理を進める。
配信サーバ２は、ステップＳ２２２ｂにおいて、判定距離範囲を「１００ｍ」に決定し、ステップＳ２２３ｂ、Ｓ２２４ｂ、Ｓ２２５ｂ、Ｓ２２６ｂの処理を行う。
つまり判定距離範囲を変更した上で、上記ステップＳ２２３〜Ｓ２２６と同様の処理を行い、１００ｍ範囲内に居るユーザについて「１００ｍ配信候補者フラグ」をオンとする処理を行う。

以上の処理が完了したら、配信サーバ２は、図１３に示す配信対象者判定処理（Ｓ２４、Ｓ１１３）に移る。
この場合、図１３のステップＳ１１３では、「１００ｍ配信候補者フラグ」、「２００ｍ配信候補者フラグ」、「３００ｍ配信候補者フラグ」のいずれかがオン、つまりは少なくとも「３００ｍ配信候補者フラグ」とされているユーザを対象として、属性を確認して配信対象者を判定し、属性条件が満たされたら配信対象者フラグをオンとする処理を行う。

また続くステップＳ１１４では、配信対象者フラグがオンとされたユーザを対象として、人数算出処理を「１００ｍ配信候補者フラグ」、「２００ｍ配信候補者フラグ」、「３００ｍ配信候補者フラグ」のそれぞれについて行えば良い。つまり、
・「配信対象者フラグ：オン」であり「３００ｍ配信候補者フラグ」の人数
・「配信対象者フラグ：オン」であり「２００ｍ配信候補者フラグ」の人数
・「配信対象者フラグ：オン」であり「１００ｍ配信候補者フラグ」の人数
をそれぞれ算出する。
この算出結果を用いて人数提示画面２０ａのウェブページデータを生成し、当該ウェブページデータを店舗端末３に送信する。これにより店舗端末３上に例えば図１７に示す人数提示画面２０ａが提示される。

なお、本例においては「１００ｍ」、「２００ｍ」、「３００ｍ」について配信候補者判定処理を行ったが、判定する距離は３つに限られることはなく、例えば２又は４以上であってもよい。また距離の間隔においても本変形例では１００ｍ間隔で表示したが、必ずしもこの間隔に限られることはなく５０ｍ間隔や１０００ｍ間隔など様々な間隔を設定することができる。さらに距離の間隔は一定の間隔であるい必要はなく、他にも「１００ｍ」、「３００ｍ」、「７００ｍ」…のように間隔が徐々に広がっているものなどが考えられる。

［６−３．配信サーバの処理の第２例］

配信サーバ２が行う処理の第２例について図１９及び図２０を参照して説明する。なお、図２０において図１３と同様の処理については同一符号を付し、説明を省略する。
この第２例は図１３のステップＳ１１４とＳ１１５の間にステップＳ１５１を追加し、ステップＳ１１５をＳ１５２に変更した例である。

配信サーバ２は、ステップＳ１５１において、属性人数算出処理を行う。具体的には、配信サーバ２が判定した配信候補者の属性情報ごとの人数を属性人数として算出する。例えば配信サーバ２は、位置ＤＢ５ｂにおいて配信対象者フラグがオンとされている配信候補者の属性情報をユーザＤＢ５ａから取得し、図１９に示すように、「性別」、「年代」、「職業」など、様々な属性の人数を算出する。

そして配信サーバ２はステップＳ１５２において、算出した配信対象者の人数情報や、配信候補者の属性人数の情報を用いて、図１９のような人数提示画面２０ｃのウェブページデータを生成し、当該ウェブページデータを店舗端末３に送信する。これにより店舗端末３上に人数提示画面２０ｃが提示される。

つまり、この図１９の例の場合、配信対象者の５０人は、店舗の近辺に居る人で、店舗管理者が指定した属性の人の人数であるが、実際には配信対象者にならなかった配信候補者も多く居ることが想定される。そこで、配信候補者も含めて、どのような属性の人が店舗の近辺にいるかを示す情報を提示する。
これにより、例えば店舗管理者が、見落としていた属性条件を満たす配信候補者が店舗の周囲に多く位置していたなど、入力した属性条件は有さないものの店舗の潜在的な顧客である配信候補者を知ることができるようになる。
なお、算出の手法としては、配信サーバ２が、店舗ＤＢ５ｃから店舗のジャンル情報を取得して、取得した店舗のジャンルに応じた属性に基づいて配信候補者に対する当該属性の人数を算出することも考えられる。
例えば店舗が「若年層向けの紳士服」の販売店だった場合、店舗の属性を「２０代」、「会社員」、「男性」とし、配信サーバ２は、配信候補者に対する前記属性を有する配信対象者の人数を算出する。

［６−４．配信サーバの処理の第３例］

配信サーバ２が行う処理の第３例について図２１及び図２２を参照して説明する。なお、図２２において図１３と同様の処理については同一符号を付し、説明を省略する。
この第３例は図１３のステップＳ１１４とＳ１１５の間にステップＳ１６１を追加し、ステップＳ１１５をＳ１６２に変更した例である。

配信サーバ２は、ステップＳ１６１において、属性割合算出処理を行う。具体的には、配信サーバ２が判定した配信候補者の人数に対する属性情報ごとの人数の割合を属性割合として算出する。例えば、配信サーバ２は、ユーザＤＢ５ａから算出した配信候補者の属性情報を取得し、、配信候補者の「男女比率」、「年代分布」、「職業割合」など、様々な属性の割合を算出する。
なお、算出の手法としては、配信サーバ２が、店舗ＤＢ５ｃから店舗のジャンル情報を取得して、取得した店舗のジャンルに応じた属性に基づいて配信候補者に対する当該属性の割合情報を算出することも考えられる。例えば店舗が「若年層向けの紳士服」の販売店だった場合、店舗の属性を「年齢」、「職業」、「性別」とし、配信サーバ２は、配信候補者に対する当該属性を有する配信対象者の割合を算出する。

そして配信サーバ２は、ステップＳ１６２において、算出した配信対象者の人数情報や、配信候補者の属性割合の情報を用いて、図２１のような人数提示画面２０ｄのウェブページデータを生成し、当該ウェブページデータを店舗端末３に送信する。これにより店舗端末３上に人数提示画面２０ｄが提示される。
つまり、この図２１の例の場合、配信対象者の５０人という情報とともに、実際には配信対象者にならなかった配信候補者も含めて、店舗の近辺にいる人の属性の割合を示す情報を提示する。

＜７．まとめ＞

以上の実施の形態では、次のような効果が得られる。
実施の形態の配信サーバ２（情報処理装置）は、配信対象者を抽出するための条件として用いられる配信対象者の属性条件を店舗端末３（配信依頼者端末）から取得する属性条件取得部２ａと、店舗端末３（配信依頼者端末）が指定する店舗（施設）から所定の距離の範囲内に位置する人を配信候補者として判定する配信候補者判定部２ｂと、配信候補者のうち配信条件に適合する人を配信対象者として判定する配信対象者判定部２ｃと、配信対象者の人数を算出する人数算出部２ｄと、店舗端末３（配信依頼者端末）に配信対象者の人数を提示させる提示制御部２ｅと、配信要求を店舗端末３（配信依頼端末）から取得する配信要求取得部２ｆと、配信対象者のユーザ端末４に配信要求に応じた情報を配信する情報配信部２ｇと、を備える。
このような配信サーバ２によるサービスを享受する店舗管理者（配信依頼者）は、店舗端末３により任意に指定した属性情報に該当する配信対象者が、店舗の周辺に何人いるのかを確認することができる。またその後、店舗管理者は、店舗端末３を用いて当該配信対象者の人数に応じたクーポン内容を配信サーバ２に指示することで、配信対象者に対してその内容のクーポン配信を配信サーバ２に依頼できる。
従って、店舗管理者は、店舗の周囲に配信対象としたい属性の人が何人いるかを容易に確認することができる。また、確認した配信対象者の人数に応じた配信情報を作成することで、より配信対象者の興味を惹く適切な内容のクーポンを配信することが可能となる。
例えば、店舗管理者は、表示された人数に応じてクーポン内容を考えることができる。例えば所定の距離範囲内に入力した属性条件に該当する配信対象者が少ない場合は「３０％割引」に、該当する配信対象者が多い場合は「１０％割引」に割引率を変えるなど店舗の周辺にいる人数に応じた柔軟な内容のクーポンを配信対象者に配信することができる。よって、配信対象者の配信情報の使用の促進及び店舗の情報配信の効率化を図ることができる。

また、店舗（施設）の滞在人数を判定する滞在人数判定部２ｈを有し、店舗（施設）の滞在人数に応じて、所定の距離範囲を変更する。（図１６参照）
これにより、店舗内の滞在人数によって、配信対象者の数が変動する。
従って、店舗管理者は、店舗内の滞在人数に応じて、情報の配信人数を変動させることで、店舗の都合に合った配信対象者の配信情報の使用の促進を図ることができ、その結果、店舗は効率的に来店者の確保を図ることができる。

また、人数算出部２ｄは、店舗（施設）から一定の距離ごとに配信対象者の人数を算出する。（図１７、図１８参照）
これにより、店舗管理者は、店舗から各距離ごとに何人の配信対象者がいるか確認することができる。
従って、店舗管理者は各距離ごとの配信対象者を参照しながら配信する範囲を選択できるため、より効率的に来店者の確保を図ることができる。

また、配信候補者判定部２ｂが判定した配信候補者の属性情報ごとの人数を属性人数として算出する属性人数算出部２ｉを有し、提示制御部２ｅは、属性人数を配信対象者のユーザ端末４に提示させる。（図１９、図２０参照）
これにより、店舗管理者は、自分が選択した属性条件以外の属性の人数についてどのくらいの人数がいるかを確認することができる。
従って、例えば店舗管理者が、見落としていた属性条件を満たす配信候補者が店舗の周囲に多く位置していたなど、入力した属性条件は有さないものの店舗の潜在的な顧客である配信候補者を知ることができるようになる。

また、配信候補者判定部２ｂが判定した配信候補者の人数に対する属性情報ごとの人数の割合を属性割合として算出する属性割合算出部２ｊを有し、提示制御部２ｅは、属性割合を配信対象者のユーザ端末４に提示させる。（図２１、図２２参照）
これにより、店舗管理者は、自分が選択した属性情報以外の属性がどのくらいの割合でいるかを確認することができる。
従って、店舗管理者は自分が選択した属性情報以外の属性の人がどのくらいの割合でいるかを容易に確認することができるため、それらを参照し、店舗にとって適した属性の人を選択し、クーポン内容を考えることなどが可能となる。よって、店舗はより効率的に来店者の確保を図ることができる。

属性割合算出部２ｊは、配信候補者の人数のうち店舗（施設）のジャンルごとに設定した属性情報ごとの割合を属性割合として算出する。（図２１、図２２参照）
これにより、店舗は、自己の店舗に関係のある属性の割合情報を閲覧することが可能となる。
従って、関係のないジャンルの属性情報が表示されることを防止することで、自己の店舗に必要な割合情報を容易に閲覧することができ、その結果、より容易に店舗にとって適した属性を選択し直すことが可能となる。

なお、本実施の形態においては、情報配信の一例としてクーポンを用い、クーポン配信システムとして説明したが、本発明の配信情報はクーポンに限られることはなく、所定の事項に関する情報であれば特に限定されることはない。配信情報としては、例えば広告、施設への入場券、整理券、施設についての各種案内、紹介情報、店舗等の施設に関するブログやレビューなどが挙げられる。
従って店舗以外に公共施設、イベント会場、遊園地、テーマパーク、公園等、各種の「施設」について本発明を適用できる。その場合の配信依頼者端末は、それらの施設の関係者が利用する端末装置となる。

また、本実施の形態においては、配信依頼者を店舗管理者、配信対象者をクーポンをユーザ端末を介して受信する者としたが、本発明の「店舗管理者」と「配信対象者」の関係は「店舗」と「クーポンの配信を受ける者」の関係に限られることはなく、例えば「コンサート会場」と「整理券の配信の受信者」や「図書館」と「推薦図書の紹介情報の受信者」、「学校」と「開講講座情報の受信者」など様々な実施の形態が考えられる。

＜６．プログラム及び記憶媒体＞
以上、本発明の情報処理装置の実施の形態としての配信サーバ２を説明してきたが、実施の形態のプログラムは、配信サーバ２における少なくとも属性条件取得部２ａ、配信候補者判定部２ｂ、配信対象者判定部２ｃ、人数算出部２ｄ、提示制御部２ｅ、配信要求取得部２ｆ、情報配信部２ｇの処理を情報処理装置（ＣＰＵなど）に実行させるプログラムである。

実施の形態のプログラムは、配信対象者を抽出するための条件として用いられる配信対象者の属性条件を店舗端末３（配信依頼者端末）から取得する処理を情報処理装置に実行させる。また店舗端末３（配信依頼者端末）が指定する店舗（施設）から所定の距離の範囲内に位置する人を配信候補者として判定する処理を情報処理装置に実行させる。さらに配信候補者のうち配信条件に適合する人を配信対象者として判定する処理を情報処理装置に実行させる。さらにまた、配信対象者の人数を算出する処理を情報処理装置に実行させる。その上、店舗端末３（配信依頼者端末）に配信対象者の人数を提示させる処理を情報処理装置に実行させる。加えて、配信要求を店舗端末３（配信依頼端末）から取得する処理を情報処理装置に実行させる。また、配信対象者のユーザ端末４に配信要求に応じた情報を配信する処理を情報処理装置に実行させる。
即ちこのプログラムは、配信サーバ２に対して図１３〜図１６、図１８、図２０、図２２で説明した処理を実行させるプログラムである。

このようなプログラムにより、上述した配信サーバ２としての情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置などの機器に内蔵されている記録媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭなどに予め記録しておくことができる。或いはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記録媒体に、一時的或いは永続的に格納（記録）しておくことができる。またこのようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記録媒体からパーソナルコンピュータなどにインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。

最後に、上述した各実施の形態の説明は本発明の一例であり、本発明は上述の実施の形態に限定されることはない。このため、上述した各実施の形態以外であっても、本発明に係る技術的思想を逸脱しない範囲であれば、設計などに応じて種々の変更が可能であることはもちろんである。

１…ネットワーク、２…配信サーバ、３…店舗端末、４…ユーザ端末、２ａ…属性条件取得部、２ｂ…配信候補者判定部、２ｃ…配信対象者判定部、２ｄ…人数算出部、２ｅ…提示制御部、２ｆ…配信要求取得部、２ｇ…情報配信部、２ｈ…滞在人数判定部、２ｉ…属性人数算出部、２ｊ…属性割合算出部

Claims (8)

1. 配信対象者を抽出するための条件として用いられる属性条件を配信依頼者端末から取得する属性条件取得部と、
   前記配信依頼者端末に対応する施設から所定の距離範囲内に位置する人を配信候補者として判定する配信候補者判定部と、
   前記配信候補者のうち前記属性条件に適合する人を前記配信対象者として判定する配信対象者判定部と、
   前記配信対象者の人数を算出する人数算出部と、
   前記配信依頼者端末に前記配信対象者の人数を提示させる提示制御部と、
   配信要求を前記配信依頼者端末から取得する配信要求取得部と、
   前記配信対象者の端末に前記配信要求に応じた情報を配信する情報配信部と、
   前記施設の滞在人数を判定する滞在人数判定部と、を備え、
   前記配信候補者判定部は、前記施設の滞在人数に応じて、前記所定の距離範囲を変更する
   情報処理装置。
2. 前記人数算出部は、前記施設からの異なる距離範囲ごとに前記配信対象者の人数を算出する
   請求項１に記載の情報処理装置。
3. 前記配信候補者判定部が判定した前記配信候補者の属性情報ごとの人数を属性人数として算出する属性人数算出部を有し、
   前記提示制御部は、前記属性人数を前記配信依頼者端末に提示させる
   請求項１に記載の情報処理装置。
4. 前記配信候補者判定部が判定した前記配信候補者の人数の属性情報ごとの割合を属性割合として算出する属性割合算出部を有し、
   前記提示制御部は、前記属性割合を前記配信依頼者端末に提示させる
   請求項１に記載の情報処理装置。
5. 前記属性割合算出部は、前記配信候補者の人数うち前記施設のジャンルごとに設定した属性情報ごとの割合を属性割合として算出する
   請求項４に記載の情報処理装置。
6. 配信対象者を抽出するための条件として用いられる属性条件を配信依頼者端末から取得するステップと、
   前記配信依頼者端末に対応する施設から所定の距離範囲内に位置する人を配信候補者として判定するステップと、
   前記配信候補者のうち前記属性条件に適合する人を前記配信対象者として判定するステップと、
   前記配信対象者の人数を算出するステップと、
   前記配信依頼者端末に前記配信対象者の人数を提示させるステップと、
   配信要求を前記配信依頼者端末から取得するステップと、
   前記配信対象者の端末に前記配信要求に応じた情報を配信するステップと、
   前記施設の滞在人数を判定するステップと、
   前記施設の滞在人数に応じて、前記所定の距離範囲を変更するステップとを
   情報処理装置が実行する情報処理方法。
7. 配信対象者を抽出するための条件として用いられる属性条件を配信依頼者端末から取得する機能と、
   前記配信依頼者端末に対応する施設から所定の距離範囲内に位置する人を配信候補者として判定する機能と、
   前記配信候補者のうち前記属性条件に適合する人を前記配信対象者として判定する機能と、
   前記配信対象者の人数を算出する機能と、
   前記配信依頼者端末に前記配信対象者の人数を提示させる機能と、
   配信要求を前記配信依頼者端末から取得する機能と、
   前記配信対象者の端末に前記配信要求に応じた情報を配信する機能と、
   前記施設の滞在人数を判定する機能と、
   前記施設の滞在人数に応じて、前記所定の距離範囲を変更する機能とを
   情報処理装置に実行させるプログラム。
8. 配信対象者を抽出するための条件として用いられる属性条件を配信依頼者端末から取得する機能と、
   前記配信依頼者端末に対応する施設から所定の距離範囲内に位置する人を配信候補者として判定する機能と、
   前記配信候補者のうち前記属性条件に適合する人を前記配信対象者として判定する機能と、
   前記配信対象者の人数を算出する機能と、
   前記配信依頼者端末に前記配信対象者の人数を提示させる機能と、
   配信要求を前記配信依頼者端末から取得する機能と、
   前記配信対象者の端末に前記配信要求に応じた情報を配信する機能と、
   前記施設の滞在人数を判定する機能と、
   前記施設の滞在人数に応じて、前記所定の距離範囲を変更する機能とを
   情報処理装置に実行させるプログラムを記憶した記憶媒体。

Images