(57)【要約】【課題】  広告を配信する場合、広告を受け取る顧客を取り巻く実環境（位置・天候・時間など）、顧客の趣味・嗜好といった個人情報を、単独ではなく組み合せて使用し、顧客により有益な広告を配信することが望ましい。【解決手段】  ネットワークを介して顧客の携帯端末へ広告を配信する際に、顧客の携帯端末から受信した位置情報を記録した配信候補顧客ファイルの1レコードに対して、店舗情報ファイルを参照して(S310)、配信元店舗候補を抽出し(S312-326)、配信元店舗候補ファイルに記録された店舗ごとに、顧客情報ファイルおよび店舗情報ファイルを参照して、配信候補顧客ファイルの1レコードに対応する携帯端末に配信すべき広告の店舗を決定する(S332, S334)。【選択図】  図12
2005078497.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して顧客の携帯端末へ広告を配信するサーバ装置であって、
顧客の携帯端末から受信した位置情報を、データベースに格納された配信候補顧客ファイルに記録する受信手段と、
前記配信候補顧客ファイルの1レコードに対して、前記データベースに格納された、少なくとも店舗情報ファイルを参照して配信元店舗候補を抽出し、その抽出結果を前記データベースに格納された配信元店舗候補ファイルに記録する抽出手段と、
前記配信元店舗候補ファイルに記録された店舗ごとに、前記データベースに格納された、少なくとも顧客情報ファイルおよび前記店舗情報ファイルを参照して、前記配信候補顧客ファイルの1レコードに対応する携帯端末に配信すべき広告の店舗を決定する決定手段とを有することを特徴とするサーバ装置。
【請求項２】
さらに、前記データベースに格納された広告配信履歴ファイルおよび前記顧客情報ファイルを参照して、顧客の携帯端末の位置情報を要求する要求手段と、
前記広告の配信結果に基づき前記広告配信履歴ファイルを更新する履歴更新手段とを有することを特徴とする請求項1に記載されたサーバ装置。
【請求項３】
前記抽出手段は、前記配信候補顧客ファイルのレコードが、前記要求手段の要求に応じて位置情報を返した携帯端末に対応する場合、前記店舗情報ファイルに加えて前記広告配信履歴ファイルを参照して前記配信元店舗候補を抽出することを特徴とする請求項2に記載されたサーバ装置。
【請求項４】
前記抽出手段は、前記携帯端末の位置情報、および、前記店舗情報ファイルに記録された店舗の営業情報ないし位置情報に基づき、前記配信元店舗候補を絞り込むことを特徴とする請求項1から請求項3の何れかに記載されたサーバ装置。
【請求項５】
前記決定手段は、さらに、現在時刻、前記データベースに格納された商品カテゴリテーブルおよび天候テーブルを参照して、配信すべき広告の店舗を決定することを特徴とする請求項1に記載されたサーバ装置。
【請求項６】
前記決定手段は、前記携帯端末と前記配信元店舗候補との距離、前記顧客情報ファイルに記録された顧客の嗜好情報と前記店舗情報ファイルに記録された前記配信元店舗候補の商品カテゴリ情報との対応、並びに、前記現在時刻および前記商品カテゴリテーブルないし前記天候テーブルに記録された情報と前記店舗情報ファイルに記録された前記配信元店舗候補の商品カテゴリ情報との関係から、前記配信元店舗候補ごとのスコアを計算し、最大のスコアをもつ前記配信元店舗候補を配信すべき広告の店舗に決定することを特徴とする請求項5に記載されたサーバ装置。
【請求項７】
ネットワークを介して顧客の携帯端末へ広告を配信する広告配信方法であって、
顧客の携帯端末から受信した位置情報を、データベースに格納された配信候補顧客ファイルに記録し、
前記配信候補顧客ファイルの1レコードに対して、前記データベースに格納された、少なくとも店舗情報ファイルを参照して配信元店舗候補を抽出し、その抽出結果を前記データベースに格納された配信元店舗候補ファイルに記録し、
前記配信元店舗候補ファイルに記録された店舗ごとに、前記データベースに格納された顧客情報ファイルおよび前記店舗情報ファイルを参照して、前記配信候補顧客ファイルの1レコードに対応する携帯端末に配信すべき広告の店舗を決定することを特徴とする広告配信方法。
【請求項８】
情報処理装置を制御して、請求項7に記載された広告の配信処理を実現することを特徴とするプログラム。
【請求項９】
請求項8に記載されたプログラムが記録されたことを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はサーバ装置および広告配信方法に関し、例えば、広告の配信先である顧客の実環境などを考慮した広告配信に関する。
【背景技術】
【０００２】
インターネットは双方向性のある、かつ、個人対象の情報交換が可能な手段である。それにもかかわらず、インターネット上のホームページや電子メールを利用した広告は不特定多数を対象とした大衆向け広告が大半であり、関心のない顧客にとっては迷惑広告になる。そのため、広告効果、成約率が低いだけでなく、反対に、情報提供主への悪印象を植え付けてしまうこともある。
【０００３】
大衆ではなく、個人としての消費者が広告に興味を示す、もしくは、広告を見て商品購買の意思をもつに至る理由としては、様々な要因が考えられる。例えば、個人の趣味・嗜好は意思決定に大きな影響を与える一要素である。また、広告を受け取る際の個人を取り巻く実環境（現在位置・天候・時間など）といった外的要因も意思決定に間接的な影響を与える要素になる。これらは、意思決定に影響を与える要素として、それぞれ単独に、広告配信支援システムで使用されている。しかし、例えば興味のある食品メーカから、勤務中に、おやつの情報が送られてきても購買に結び付く確率は低い。また、その場所に居るという理由だけで興味のない店舗の情報が送られてきても、広告効果は上がらないであろう。つまり、購買に関わる前述の要因は、それぞれ単独で使用しても、大きな効果は得られないと言える。
【０００４】
しかし、個人の趣味・嗜好や個人を取り巻く実環境などの複数の要素を考慮して、最適な広告を配信しようとすると、複数の条件の組合わせを取り扱わなければならず処理が複雑になる。さらに、他の要素が加わると、変更のための対応に工数と時間がかかる。
【０００５】
携帯電話の位置情報と携帯電話の電子メール機能とを利用して、携帯電話モニタに対して、即時性のあるダイレクトマーケティングを行うシステムが提案されている（例えば、特許文献1の4-7頁、図1-3参照）。しかし、電子メール送信の都度、人が画面から条件を指定してモニタの抽出やメール本文の作成を行わなければならない問題がある。
【０００６】
また、携帯電話の顧客が、希望する商品広告を顧客が移動中のエリアに連動して自動的に入手できるようにする、商品広告の配布方法が提案されている（例えば、特許文献2の3-5頁、図1-4参照）。この方法も、上述したような複数の条件の組合わせを取り扱うことが必要になり、処理が複雑になる問題、変更のための対応に工数と時間がかかる問題がある。
【０００７】
【特許文献１】特開2002-366464公報
【特許文献２】特開2002-259821号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
広告を受け取る顧客を取り巻く実環境（位置・天候・時間など）、顧客の趣味・嗜好といった個人情報を、単独ではなく組み合せて使用し、顧客により有益な広告を配信することが望ましい。
【０００９】
また、在庫状況やキャンペーン内容により、優先的に広告したい商品を効果的に広告できるようにすることが望まれる。
【００１０】
本発明は、上述の問題を個々にまたはまとめて解決するもので、顧客と、その実環境に応じた広告を配信することを目的とする。
【００１１】
また、店舗が優先的に広告したい商品を効果的に広告できるようにすることを他の目的とする。
【課題を解決するための手段】
【００１２】
本発明は、前記の目的を達成する一手段として、以下の構成を備える。
【００１３】
本発明は、ネットワークを介して顧客の携帯端末へ広告を配信する際に、顧客の携帯端末から受信した位置情報を、データベースに格納された配信候補顧客ファイルに記録し、配信候補顧客ファイルの1レコードに対して、データベースに格納された、少なくとも店舗情報ファイルを参照して配信元店舗候補を抽出し、その抽出結果をデータベースに格納された配信元店舗候補ファイルに記録し、配信元店舗候補ファイルに記録された店舗ごとに、データベースに格納された顧客情報ファイルおよび店舗情報ファイルを参照して、配信候補顧客ファイルの1レコードに対応する携帯端末に配信すべき広告の店舗を決定することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、顧客と、その実環境に応じた広告を配信することができる。
【００１５】
また、店舗が優先的に広告したい商品を効果的に広告できるようにすることができる。
【発明を実施するための最良の形態】
【００１６】
以下に説明する実施形態の広告配信システムおよびその方法は、顧客の趣味・嗜好といった購買の内的要因に基づいたワンツーワンマーケティングの効果と、顧客を取り巻く位置・天候・時間などといった購買の外的要因に基づいたダイナミックマーケティングの効果を相互に関連させて、広告情報に顧客が興味を示す率を向上させるものである。また、興味のない、垂れ流し広告的な煩わしさから顧客を解放し、顧客にとって、より有益な広告情報のみを受け取るようにするためのものである。さらに、広告主にとっては、広告に対する消費者の反応率を高め、効果的な広告を実施するためのものであり、同時に、迷惑広告によって消費者に悪印象を植え付ける危険性を回避するためのものである。
【００１７】
以下、本発明にかかる実施例の広告配信支援システムおよび方法を図面を参照して詳細に説明する。
【実施例１】
【００１８】
［構成］
図1は広告配信支援システムの構成例を示すブロック図である。
【００１９】
広告配信支援システム1は、広告配信支援サーバ2、外部記憶装置に保持されたデータベース3、および、広告配信サーバ2を操作するための端末4などから構成される。
【００２０】
広告配信支援サーバ2は、インターネットや携帯電話網などのネットワーク5を介して、店舗端末6や携帯端末7と通信するとともに、図示しない携帯端末の通信事業者のサーバや天候情報を提供するサーバなど、各種サーバと通信する。端末4および店舗端末6はパーソナルコンピュータであり、携帯端末7は携帯電話、PHS (Personal Handy phone System)、PDA (Personal Digital Assistants)などである。なお、図1には、広告配信支援サーバ2が一台の構成例を示すが、データベース3を共有する複数の広告配信支援サーバ2を用意して、後述する顧客や店舗を分割して処理することもできる。また、広告配信支援サーバ2のハードディスクなどの不揮発性のメモリ2aには、後述する処理を広告配信支援サーバ2が実行するためのプログラムが格納されている。
【００２１】
データベース3は、広告配信支援サーバ2が作成し管理する顧客情報ファイル、店舗情報ファイル、広告配信履歴ファイル、商品カテゴリテーブル、天候テーブル、係数テーブルなどを保持する。
【００２２】
●商品カテゴリテーブル
商品カテゴリテーブルは、顧客の商品に対する嗜好や関心度と、店舗の商品販売意欲とを適合させるためのテーブルである。広告配信支援サーバ2、広告配信支援システム1の管理者の端末（例えば端末4）から入力された情報を商品カテゴリテーブルのテーブルデータとしてデータベース3に保存する。
【００２３】
図2は商品カテゴリテーブルの一例を示す図で、ファストフードの一例を示している。
【００２４】
横方向に商品カテゴリを並べ、縦方向に時間帯、天気、気温などの条件をとり、縦横相互一致の割合を表す数値をもつ。例えば、図2において、商品カテゴリ「ハンバーガー」と時間帯の条件「6時〜9時」との一致の割合が「0.5」であることが示されている。なお、広告配信支援サーバ2は、一つのカテゴリについて、条件ごとに割合の合計値が「1」になるように調整したテーブルデータをデータベース3に保存する。
【００２５】
●天候テーブル
広告配信支援サーバ2は、所定時間ごと、または、予め設定された時間にネットワーク5を介して外部の天候情報提供サーバから天候情報を入手し、入手した最新情報によって、データベース3に保存された天候テーブルを更新する。図3は天候テーブルの一例を示す図で、地域別、時間帯別（数時間単位）に天気（晴れ、曇り、雨など）、気温、湿度などの予想値をもつ。
【００２６】
●顧客情報ファイル
広告配信支援サーバ2は、顧客が携帯端末7などから入力した登録情報やアンケートなどの情報を基に顧客情報ファイルを作成しデータベース3に保存する。図4は顧客情報ファイルの一例を示す図で、顧客識別番号、氏名、住所、携帯端末電話番号、電子メールアドレス、性別、年齢などの個人属性情報、並びに、嗜好品名とその嗜好比率を一組とする複数の嗜好品セットなどをもつ。
【００２７】
「嗜好品名」は、図2に示す商品カテゴリテーブルの商品カテゴリに登録された品名から選定されるもので、顧客端末7からの入力や、他の販売実績収集システムにより収集され、集計されたデータに基づき、広告配信支援サーバ2が設定する。「嗜好比率」は、その嗜好品を好む割合を示す数値で、顧客アンケートや、他の販売実績収集システムにより収集され、集計されたデータに基づき、広告配信支援サーバ2が設定する。例えば、図4において顧客識別番号が「abc1234567」の顧客は、嗜好品名として「コーヒー」を選択し、その嗜好比率が「23」パーセントであることが示されている。なお、広告配信支援サーバ2は、顧客情報ファイルを作成または変更する際、顧客一件ごとに嗜好比率の合計が100%になるよう調整する。例えば、顧客アンケートデータにおいて、嗜好品が一位から四位まで順序付けされていれば、広告配信支援サーバ2は、それら嗜好品の嗜好品比率をそれぞれ40、30、20、10%などに設定する。
【００２８】
●店舗情報ファイル
広告配信支援サーバ2は、店舗の経営者や担当者（以下、単に「店舗」と呼ぶ場合がある）が店舗端末6を操作して入力した情報を基に店舗情報ファイルを作成しデータベース3に保存する。図5は店舗情報ファイルの一例を示す図で、店舗識別番号、店舗名称、住所、電話番号などの店舗属性情報、店舗位置、天候地域、並びに、商品カテゴリとその推奨比率を一組とする複数の推奨商品セットなどをもつ。
【００２９】
「店舗位置」は、GPS (Global Positioning System)や通信事業者の基地局の情報によって得た位置情報で、下記のフォーマットにより位置を示す。
Addd.mm.ss.xx
Bddd.mm.ss.xx
ここで、Aは緯度を表し、N（北緯）またはS（南緯）
Bは経度を表し、E（東経）またはW（西経）
ddd.mm.ss.xxは「度.分.秒.百分の一秒」を表す数値
【００３０】
「営業時間」は、下記のフォーマットにより店舗の営業時間を示す。
Wwhhmm.hhmm
ここで、Wwは曜日を表し、Su（日）Mo（月）Tu（火）We（水）Th（木）
Fr（金）Sa（土）の何れか
hhmm.hhmmは「開店時間.閉店時間」を表し、例えば、午前九
時開店、午後七時半閉店の場合は「0900.1930」である。また、
店舗が休みの曜日は「Ww0000.0000」で表現する。さらに、年
末年始などの期間閉店する場合は、対応する曜日のデータを
「Ww0000.0000」にすればよい
【００３１】
また、「天候地域」は、この店舗の天候として天候テーブルのどの地域のデータを採用するかを示す。「商品カテゴリ」は、商品カテゴリテーブルに登録された商品カテゴリの中から、その店舗が推奨商品として選定したものを示す。「推奨比率」は、その店舗の推奨商品を顧客に広告宣伝すべき程度を示す。広告配信支援サーバ2は、店舗一件ごとの推奨比率の合計値が100になるよう、推奨比率を調整する。
【００３２】
勿論、店舗は、ネットワーク5および広告配信支援システム1が提供するウェブサイトに接続された店舗端末6を操作して、随時、推奨商品に関する情報を変更することができ、変更情報を受け付けた広告配信支援サーバ2は、変更情報を反映するためにデータベース3に保存された店舗情報ファイルを更新する。
【００３３】
●広告配信履歴ファイル
広告配信支援サーバ2は、後述する広告配信を行った場合、その履歴を広告配信履歴ファイルとして作成しデータベース3に保存する。図6は広告配信履歴ファイルの一例を示す図で、広告の配信先を示す顧客識別番号ごとに、広告の配信日時、配信元店舗の店舗識別番号、配信先位置（配信時の携帯端末7の位置）などをもつ。なお、「直近配信実績」には、その顧客識別番号に対する最新の配信情報を保存し、「配信履歴n」(n=1, 2, 3, …)には、その顧客識別番号に対する以前の配信情報をスタックする（nの増加とともに古くなる）。
【００３４】
●係数テーブル
広告配信支援サーバ2は、データベース3に保存された情報のうち、一部の判定値について、広告配信支援システム1の管理者の端末4からの入力を受け付けて係数テーブルに反映し、処理内容の調整を可能としている。図7は係数テーブルの一例を示す図で、詳細は後述するが、項目として広告配信の基準になる時間間隔、気温情報（暑いか、暖かいか、涼しいか、寒いかを判定する実際の気温の値）、後述する店舗スコアを計算するために使用するパラメータ値などを保持する。
【００３５】
［処理］
広告配信支援サーバ2は、位置情報の問合処理、位置情報の受領処理、および、広告配信処理などを行うが、以下、それら処理を順に説明する。
【００３６】
●位置情報の問合処理
広告配信支援サーバ2は、係数テーブルの「稼動時間帯」が示す期間、「起動間隔」が示す時間間隔で位置情報の問合処理を起動し実行する。例えば、図7に示す係数テーブルによれば、7時から23時までの間、0.7時間（42分）ごとに位置情報の問合処理を起動し実行する。図8は位置情報の問合処理の一例を示すフローチャートである。
【００３７】
広告配信支援サーバ2は、顧客情報ファイルに登録された一人の顧客のデータを顧客情報ファイルおよび広告配信履歴ファイルから読み込み(S110)、現在時刻とその顧客の直近配信実績の配信日時とを比較して、係数テーブルの「基準配信間隔」（図7の例では三時間）以上の時間が経過しているか否かを判定する(S112)。経過していれば当該顧客を、位置情報を問い合わせる顧客として、図示しないRAMの所定領域に記憶する(S114)。また、未経過であれば、ステップS114の処理をスキップして、顧客情報ファイルが登録された全顧客について、ステップS112の判定が終了したか否かを判断する(S116)。未了であれば、顧客情報ファイルが登録された次の顧客に対するステップS112の判定を行うために、処理をステップS110に戻す。このようにして、全顧客（登録された全顧客情報ファイル）についてステップS112の判定を終了すると処理をステップS118へ進める。
【００３８】
このように、ステップS112の経過時間の判定により、同一の顧客に対して「基準配信間隔」に設定された時間内に続けて広告を配信しないようにし、顧客に不快感を与えることを避ける。
【００３９】
広告配信支援サーバ2は、位置情報を問合わせる顧客として記憶した顧客について、その携帯端末7の通信事業者に対して、位置情報を問い合わせるためのショートメッセージを携帯端末7へ送るように要求する(S118)。この要求は、係数テーブルの「位置要求送出単位」に設定された人数分ごとにまとめて行う。また、ステップS114において、位置情報を問合わせる顧客として記憶した顧客の数が「位置要求送出単位」の設定値に達するごとに、ステップS118の要求を行ってもよい。
【００４０】
一方、顧客は、広告配信支援システム1が提供するウェブサイトから自身の携帯端末7に、位置情報アプリケーションプログラムをダウンロードすることができる。その際、顧客識別番号の入力を必要とし、ダウンロードした位置情報アプリケーションプログラムには顧客識別番号が記録されている。以降、顧客は、既に、位置情報アプリケーションプログラムをダウンロードしたものとして説明する。
【００４１】
顧客の携帯端末7は、携帯端末7の通信事業者から位置情報を問合わせるショートメッセージを受信すると、位置情報アプリケーションプログラムを起動する（この場合、起動種別が「プッシュ(push)」であるという）。なお、位置情報アプリケーションプログラムは、ショートメッセージの受信に伴う（自動）起動だけではなく、顧客が広告配信を希望する場合に、顧客が携帯端末7を操作することによっても起動する（この場合、起動種別が「プル(pull)」であるという）。位置情報アプリケーションプログラムは、携帯端末7の種類や携帯端末7の通信事業者に応じて処理内容が異なるにしても、GPS、基地局、通信事業者と通信して、自身の現在の位置情報を入手した上で、広告配信支援サーバ2に対して、顧客識別番号、取得した位置情報、その誤差、および、起動種別などの情報を位置情報の問い合せに対するレスポンスとして電子メールまたはHTTPプロトコルにより送信する。
【００４２】
●位置情報の受領処理
次に、広告配信支援サーバ2が行う位置情報の受領処理について説明する。なお、位置情報の受領処理は停止することなく稼動し続ける。図9は位置情報の受領処理の一例を示すフローチャートである。
【００４３】
広告配信支援サーバ2は、携帯端末7の位置情報アプリケーションプログラムから顧客識別番号、位置情報、その誤差、起動種別などの情報を受信すると(S120)、受信した情報をデータベース3に格納された配信候補顧客ファイルの最後尾に一件のレコードとして記録し(S122)、処理をステップS120に戻す。
【００４４】
図10は配信候補顧客ファイルの一例を示す図で、顧客識別番号、要求日時、位置情報、誤差レベル、配信タイプなどをもつ。
【００４５】
「位置情報」は携帯端末7から受信した位置情報で、そのフォーマットは店舗位置と同じである。
【００４６】
「誤差レベル」は携帯端末7から受信した位置情報の誤差の平均的な値で、通信事業者ごとに異なる誤差情報を本システム用に統一化したものである。例えば、ある通信事業者が提供する位置情報の誤差が距離範囲で表される場合は、その中間点、誤差範囲0〜50mならば25mにする。また、他の通信事業者が提供する位置情報の誤差が誤差距離と確度で与えられる場合は、(誤差距離/確度)/2の値、65%の確度で誤差30m以内ならば{(30+0)/0.65}/2=23mにする。
【００４７】
「配信タイプ」は携帯端末7から受信した、位置情報アプリケーションプログラムの起動種別を示し、ショートメッセージを受信して位置情報アプリケーションプログラムが自動起動した場合は「push」、顧客の操作によって起動した場合は「pull」になる。
【００４８】
●広告配信処理
次に、広告配信支援サーバ2が行う広告配信処理について説明する。なお、広告配信処理は停止することなく稼動し続ける。図11は広告配信処理の一例を示すフローチャートである。
【００４９】
広告配信支援サーバ2は、配信候補顧客ファイルにレコードがあるか否かを判定し(S210)、レコードがなければ、係数テーブルの「待機時間」に設定された時間（図7の例では0.001時間(3.6秒間)）だけ処理を休止し(S212)、その後、処理をステップS210へ戻す。
【００５０】
配信候補顧客ファイルにレコードがあれば、配信候補顧客ファイルの先頭から一件のレコードを読み込み(S214)、読み込んだレコードの顧客識別番号に基づき、顧客情報ファイルおよび広告配信履歴ファイルから対応する顧客のデータを読み込む(S216)。
【００５１】
次に、広告配信支援サーバ2は、読み込んだレコードの配信タイプの値が「push」か否かを判定し(S218)、そうであれば（以降「プッシュ型顧客」と呼ぶ）、読み込んだレコードの誤差レベルと係数テーブルの「許容誤差」の設定値とを比較して(S220)、誤差レベル＜許容誤差であればプッシュ型顧客に対する処理を行う(S222)。また、誤差レベル≧許容誤差であれば処理をステップS226へ進める。つまり、位置情報の誤差が大きい携帯端末7については、その携帯端末7と店舗との距離が正確に把握できず、両者の距離が遠い場合もあるので広告配信をせずに、効果の少ない広告配信を行う可能性を回避する。
【００５２】
また、配信タイプの値が「pull」であれば（以降「プル型顧客」と呼ぶ）、プル型顧客に対する処理を行い(S224)、その後、処理をステップS226へ進める。なお、プル型顧客については誤差レベルを調査することなくプル型顧客に対する処理を行う。
【００５３】
ステップS226では、配信候補顧客ファイルの先頭のレコード、つまり処理済みのレコードを削除し、その後、処理をステップS210へ戻す。
【００５４】
●プッシュ型顧客に対する処理
図12はプッシュ型顧客に対する処理の流れを説明するフローチャートである。
【００５５】
広告配信支援サーバ2は、店舗情報ファイルのレコードを一件読み込み(S310)、まず、営業時間のデータから当該店舗が営業中か否かを判定し(S312)、営業中でなければ処理をステップS328へ進める。
【００５６】
当該店舗が営業中であれば、店舗情報ファイルの「店舗位置」と配信候補顧客ファイルの「位置情報」から、店舗と携帯端末7の間の距離を計算する(S314)。例えば、ヒュベニの距離計算式を使って計算する場合、両者の位置における緯度の平均値をP、緯度の差をdP、経度の差をdRとしてそれらを求め、続いて、子午線曲率半径Mおよび卯酉線曲率半径Nを次式により計算する。
M = 6334834/√(1 - 0.006674・sin2P)3
N = 6377397/√(1 - 0.006674・sin2P)
【００５７】
そして両者の距離Dを次式により計算する。
D = √{(M・dP)2 + (N・cos P・dR)2}
【００５８】
例えば、店舗位置を北緯35度32分57.53秒、東経139度31分22.82秒、携帯端末の位置を北緯35度32分56.00秒、東経139度31分17.00秒とすると、両者の距離Dは上式により154メートルと計算される。広告配信支援サーバ2は、計算した距離Dと係数テーブルの「店舗距離」とを比較し(S316)、距離D＜店舗距離ならば処理をステップS318へ進め、距離D≧店舗距離ならば処理をステップS328へ進める。
【００５９】
次に、広告配信支援サーバ2は、広告配信履歴ファイルを参照して、対象顧客の直近配信実績に当該店舗が登録されているか否かを判定し(S318)、登録されている場合は、その配信日時から係数ファイルの「同一店舗連続配信間隔」以上の時間が経過しているか否かを調べる(S320)。また、直近配信実績に当該店舗が登録されていなければ、配信履歴を参照して配信履歴nに当該店舗が登録されているか否かを調べ(S322)、登録されている場合は、その配信日時から係数テーブルの「同一店舗最短配信間隔」以上の時間が経過しているか否かを調べる(S324)。
【００６０】
例えば、図6に示すように、顧客識別番号「abc1234567」の顧客について、店舗識別番号「sh11223」の店舗が直近配信実績に登録されていれば、たとえ当該店舗と携帯電話7（対象顧客）の距離が近くても、その配信日時から同一店舗連続配信間隔（図7では「125時間」）が経過するまでは、配信条件を満たさないと判定する。また、店舗識別番号「sh11223」の店舗が配信履歴nに登録されている場合は、その配信日時から同一顧客最短配信間隔（図7では「27時間」）が経過するまでは、配信条件を満たさないと判定する。勿論、配信履歴nにも登録されていなければ条件を満たすと判定する。この判定により、同一店舗の広告を短期間に繰り返し配信して顧客に不快感を与えることを避ける。
【００６１】
そして、広告配信支援サーバ2は、配信条件を満たせば処理をステップS326へ進み、配信条件を満たさなければ処理をステップS328へ進める。
【００６２】
次に、広告配信支援サーバ2は、係数テーブルの「店舗絞り込み数」に設定された数分（図7では「10」）、より距離Dが近い店舗の店舗識別番号および距離Dを一組として、データベース3に格納された配信元店舗候補ファイルに記憶し(S326)、店舗情報ファイルの全レコードを参照したか否かを判定し(S328)、未参照のレコードがあれば処理をステップS310へ戻し、未参照のレコードがなければ処理をステップS330へ進める。
【００６３】
店舗情報ファイルの全レコードを参照した場合、広告配信支援サーバ2は、配信元店舗候補があるか否かを判定し(S330)、あれば記憶した配信元店舗候補ごとに店舗スコアSを計算する(S332)。なお、配信元店舗候補がなければプッシュ型顧客に対する処理を終了する。
S = Σ(Wm・Pm)
【００６４】
ここで、Wmは重みで、その値は係数テーブルに登録されている。例えば、図7には、距離重み、嗜好重み、時間天候重み、配信実績重みを示す。Pmは、広告配信支援サーバ2が計算するポイントで、以下に計算例を示す。
【００６５】
（1）距離ポイントPdを次式で計算する。次式において、Lは係数テーブルの「店舗距離」の設定値（図7の例では「500メートル」）、Dは店舗と携帯端末7との距離である。すなわち、距離ポイントPdは、店舗と顧客の位置の近さ度合いを示す。
Pd = {(L - D)/L}・100
【００６６】
（2）嗜好ポイントPfを次式で計算する。次式において、右辺の( )内は商品カテゴリごとに計算し、Cnは処理対象の顧客の顧客情報ファイルの嗜好品名に該当する商品カテゴリが登録されていれば、その嗜好比率であり、未登録であれば「0」である。Knは店舗情報ファイルの商品カテゴリに該当する商品カテゴリが登録されていれば、その推奨比率であり、未登録であければ「0」である。言い換えれば、顧客情報ファイルの嗜好品名に登録されていて、かつ、店舗情報ファイルの推奨商品に登録されている商品カテゴリ、つまり顧客の嗜好品と店舗の推奨商品が一致するものについて計算し、その合計を嗜好ポイントPfとする。
Pf = Σ(Cn・Kn)
【００６７】
例えば、顧客識別番号「abc1234567」の嗜好品（図4参照）と、店舗識別番号「sh11223」の推奨品（図5参照）とを比較すると「デザート一般」が一致し、その他が一致しなければ、嗜好ポイントPfは次のようになる。
pf = Σ(Cn・Kn) = 18・20 = 360
【００６８】
（3）時間天候ポイントPtを次式で計算する。次式において、右辺の( )内は商品カテゴリごとに計算し、Knは前述した嗜好ポイントpfと同様に店舗情報ファイルに登録された商品カテゴリの推奨比率である。
Pt = Σ(Bn・Kn)
ここで、Bn = G・g + H・h + J・j
【００６９】
上式において、Bnは、現在の時刻、および、携帯端末7の位置情報に対応する場所の、天候テーブルが示す現在の天気・気温、並びに、係数テーブルおよび商品カテゴリテーブルに基づき計算される。具体的には、Gは係数テーブルの「時間係数」の設定値（図7の例では「5」）、Hは同「天気係数」の設定値（図7の例では「1」）、Jは同「気温係数」の設定値（図7の例では「2」）である。また、gは、商品カテゴリテーブルの当該商品カテゴリにおける、現在時刻に相当する「時間帯」の設定値、hは現在の天気に相当する「天気」の設定値、jは現在の気温に相当する「気温」の設定値である。
【００７０】
例えば、店舗識別記号「sh11267」の推奨商品「デザート冷」（図5参照）について、現在時刻が16時であれば、図2に示す商品カテゴリテーブルの時間帯「13時〜17時」からg=0.6を取得しする。
G・g = 5・0.6 = 3
【００７１】
同店舗の天候地域「○○市」（図5参照）に基づき天候テーブルを参照して「○○市」の15時〜18時の天気「くもり」（図3参照）を取得する。ただし、商品カテゴリテーブルの商品カテゴリ「デザート冷」には天気「くもり」に対応する値はないのでh=0にする。
H・h = 1・0 = 0
【００７２】
同じく天候テーブルを参照して天候地域「○○市」の15時〜18時の気温「18」（図3参照）を取得する。18度は係数テーブルを参照すると「暖かい」に該当し、当該店舗の推奨商品「デザート冷」（図5参照）から、商品カテゴリテーブルの商品カテゴリ「デザート冷」の気温「暖かい」に対応する値からj=2にする。
J・j = 2・0.2 = 0.4
【００７３】
従って、現在時刻の○○市における商品カテゴリ「デザート冷」のBnは次のように計算され、当該店舗の「デザート冷」の嗜好ポイントBn・Knは、その推奨比率「80」から次のように計算される。
Bn = G・g + H・h + J・j = 3 + 0 + 0.4 = 3.4
Bn・Kn = 3.4・80 = 272
【００７４】
（4）配信実績ポイントPrを次式で計算する。次式において、Rは、現在時刻から溯って、係数テーブルの「配信実績カウント時間」の設定値（図7の例では「24時間」）内の、当該店舗の広告の配信回数である。なお、配信実績カウント時間内の店舗ごとの配信回数は、広告配信履歴ファイルを参照して調べることができる。また、配信実績ポイントPrはマイナスの値になるが、これは、繁華街に位置するなど条件の良い店舗と、そうではない店舗の間の広告配信件数の格差是正を図ることを目的とする。
Pr = -R
【００７５】
このようにして、広告配信支援サーバ2は、配信元店舗候補の各店舗について店舗スコアSを計算し、その後、最大の店舗スコアSをもつ店舗を配信元店舗に決定し、図13に一例を示すメール案文ファイルを参照して配信内容を決定する(S334)。具体的には、メール案文ファイルの、配信元店舗および現在時刻に基づき、対応する店舗識別番号かつ配信時間帯のメールコンテンツの内容を、対象顧客の携帯端末7に宛に配信する電子メールの内容にする。なお、店舗は、随時、店舗端末6を操作して配信時間帯およびメールコンテンツの数および内容を変更することができる。
【００７６】
広告配信支援サーバ2は、ステップS334で決定した配信内容の電子メールを対象顧客の携帯端末7に送信し、当該顧客の広告配信履歴ファイルの直近配信実績を更新し(S336)、プッシュ型顧客に対する処理を終了する。なお、直前に直近配信実績として記憶されてデータは配信履歴nにスタックされる。その際、係数テーブルの「配信履歴保存時間」の設定値以上の時間が経過した配信履歴nを削除する。
【００７７】
●プル型顧客に対する処理
図14はプル型顧客に対する処理の流れを説明するフローチャートである。なお、図14において、図12と同一の処理内容については同一符号を付して、その詳細説明を省略する。以下、図12と図14で処理が異なる部分を中心に説明する。
【００７８】
プル型顧客は、自発的に広告配信を要求した顧客であるから、配信履歴に関係なく、直ちに広告を配信すればよい。このため広告配信支援サーバ2は、図12に示す距離Dの判定(S316)および配信後の時間経過の判定(S318-S324)を行わない。また、ステップS330において配信元店舗候補がない場合は、店舗識別番号を空白としてステップS366へ進み、メール案文ファイルの店舗識別番号が空白であるメールコンテンツ、図13の例ではメール識別番号が「1」の内容の電子メールを送信して、広告を配信すべき店舗が見つからない旨を通知する。
【００７９】
このように、実施例1によれば、広告を受け取る際の、顧客を取り巻く実環境（位置・天候・時間など）、および、顧客の趣味・嗜好といった個人情報、並びに、広告元の店舗の位置、商品カテゴリおよび推奨度などをパラメータ化し、広告を配信する際にそれらパラメータに基づきスコアを算出し、得られたスコア（顧客と店舗とのマッチング度合いを表す）に応じて広告を配信する。従って、顧客がより望むだろう広告を提供することができる。さらに、広告の配信履歴を考慮して広告を配信することで、広告の配信を受けた顧客に垂れ流し広告、迷惑広告のような不快感を与えることを極力避けることが可能な広告配信支援システムにすることができる。
【００８０】
［変形例１］
上記の実施例では、店舗としてファストフード店を例に挙げて説明したが、適用する業種により、次に示すような変形適用も可能である。
【００８１】
（1）旅行業の店舗に適用する場合は、係数テーブルの基準配信間隔、同一店舗最短配信間隔、同一店舗連続配信間隔の尺度を時間から日数に変更する。
【００８２】
（2）多数の商売カテゴリを扱う百貨店やスーパマーケットなどに適用する場合は、売り場単位に店舗情報ファイルに登録することが好ましい。
【００８３】
（3）限定商品（コーヒー、アイスクリーム、ハンバーガーなど）のチェーン店の場合は、商品カテゴリの代わりに、例えばフィッシュバーガーやアイスコーヒーといった個別の商品名を登録することが好ましい。
【００８４】
（4）化粧品業の店舗に適用する場合は、商品カテゴリテーブルの条件に「肌条件」などを採用することが好ましい。例えば、かさかさ＝低温低湿、ぱさぱさ＝中温低湿、しっとり＝中温中湿、べとべと＝高温高湿、などを設定すれば、気象条件との対応を細かくとることができる。
【００８５】
［変形例２］
以上の説明においては、天候テーブル、配信候補顧客ファイル、広告配信履歴ファイルについて、常時更新し、最新の状態としているが、これを一定期間保存することもできる。そうすれば、それらファイルを参照して、稼働時間帯以外の時間に広告配信支援サーバ2に、または、他のサーバに統計処理を実行させ、時間帯別、店舗別の広告配信実績を表やグラフに表示することができる。
【００８６】
また、管理者の端末4からの指示に応じて、係数テーブルの設定値や商品カテゴリテーブルの値を変化させて、広告配信支援サーバ2の実時間とは異なる仮の設定時間を基に、配信候補顧客ファイルの「要求日時」、「位置情報」の値を使用して、広告配信処理の広告配信元店舗の決定(S334)までを疑似実行（実際の広告配信は行わない）すれば、時間帯別、店舗別の広告配信状況がどのようになるかをシミュレートして、仮の広告配信履歴ファイルを作成することができる。このようなデータに基づき、広告配信支援サーバ2が統計処理を行い、時間帯別、店舗別の広告配信実績の表やグラフを作成し表示して、妥当な係数テーブルの設定値の評価用データを準備することができる。
【００８７】
上記のシミュレーションは、店舗の追加・削除、商品カテゴリの追加、削除、顧客の追加、削除が比較的多い際や、季節の変わり目、スコア計算式、ポイント計算式の変更時に有効である。これにより、店舗間の広告配信量の制御や平準化につなげることも可能である。
【００８８】
［変形例３］
以上では、広告配信支援サーバ2は、商品カテゴリテーブルの時間帯、天気、気温の条件を一組もつとして説明したが、この条件を、図15に示すように、店舗情報ファイルの推奨商品ごとに保持してもよい。また、時間条件については、店舗ごとの時間帯指定を可能にするなどして、店舗ごとの特徴を反映し易くすることもできる。なお、この場合であっても、広告配信支援サーバ2は一つのカテゴリについて、条件ごと（時間帯、天気、気温）の値の合計が「1」になるように調整して、店舗間の格差を少なくするようにする。
【図面の簡単な説明】
【００８９】
【図１】広告配信支援システムの構成例を示すブロック図、
【図２】商品カテゴリテーブルの一例を示す図、
【図３】天候テーブルの一例を示す図、
【図４】顧客情報ファイルの一例を示す図、
【図５】店舗情報ファイルの一例を示す図、
【図６】広告配信履歴ファイルの一例を示す図、
【図７】係数テーブルの一例を示す図、
【図８】位置情報の問合処理の一例を示すフローチャート、
【図９】位置情報の受領処理の一例を示すフローチャート、
【図１０】配信候補顧客ファイルの一例を示す図、
【図１１】広告配信処理の一例を示すフローチャート、
【図１２】プッシュ型顧客に対する処理の流れを説明するフローチャート、
【図１３】メール案文ファイルの一例を示す図、
【図１４】プル型顧客に対する処理の流れを説明するフローチャート、
【図１５】店舗情報ファイルの他の例を示す図である。
【図１】
2005078497.tif 000003
【図２】
2005078497.tif 000004
【図３】
2005078497.tif 000005
【図４】
2005078497.tif 000006
【図５】
2005078497.tif 000007
【図６】
2005078497.tif 000008
【図７】
2005078497.tif 000009
【図８】
2005078497.tif 000010
【図９】
2005078497.tif 000011
【図１０】
2005078497.tif 000012
【図１１】
2005078497.tif 000013
【図１２】
2005078497.tif 000014
【図１３】
2005078497.tif 000015
【図１４】
2005078497.tif 000016
【図１５】
2005078497.tif 000017