JP5661727B2 - 情報配信装置、情報配信方法および情報配信プログラム - Google Patents

Description

本発明は、情報配信装置、情報配信方法および情報配信プログラムに関する。

近年、スマートフォンの普及や公衆無線ＬＡＮ（Local Area Network）の高速化に伴って、ユーザは、場所を選ばすインターネットにアクセスすることができる。企業では、ユーザのアクセス数が増大する中で、有用な広告等をユーザに提供することで、他の企業との差別化を図っている。

例えば、レストランなどの店舗は、日替わりメニューやランチ情報などを予め登録しておき、ユーザのスマートフォンからアクセスがあった場合に、検索条件を入力させる。そして、店舗は、入力された検索条件に一致するメニューをユーザのスマートフォンに応答することで、店舗への来店を促す技術が知られている（例えば、特許文献１、特許文献２参照）。

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

しかしながら、従来の技術では、メニューなどの情報提供側は、ユーザ側にアクセスしてもらって検索条件を入力してもらわなければ、ユーザが所望する情報を提供することができない、このため、情報提供が十分ではなく、サービスの利用を促すには十分ではない。なお、ユーザの情報を店舗側に登録して、登録情報に対応するサービス情報を、店舗側からユーザへ情報を直接提供することも考えられるが、店舗側に個人情報を登録することはセキュリティ上好ましくない。

本願は、上記に鑑みてなされたものであって、ユーザが所望する情報を効率的に提供することができる情報配信装置、情報配信方法および情報配信プログラムを提供することを目的とする。

本願の開示する情報配信装置は、一つの態様において、ユーザに提供される各商品の属性を記憶する記憶手段と、前記ユーザが所有する通信装置から前記ユーザの位置情報を取得する取得手段と、前記取得手段によって取得されたユーザの位置情報を少なくとも用いて、前記ユーザの状況を特定する状況特定手段と、前記状況特定手段によって特定されたユーザの状況を前記属性として有する前記商品を前記記憶手段から特定する情報特定手段と、前記情報特定手段によって特定された商品を前記通信装置に配信する配信手段とを有することを特徴とする。

本願の開示する情報配信装置、情報配信方法および情報配信プログラムは、ユーザが所望する情報を効率的に提供することができるという効果を奏する。

図１は、第１の実施形態に係るシステムの全体構成例を示す図である。 図２は、第１の実施形態に係る情報配信装置の機能構成を示す機能ブロック図である。 図３は、ユーザ情報ＤＢに記憶される情報の例を示す図である。 図４は、メニューＤＢに記憶される情報の例を示す図である。 図５は、第１の実施形態に係る情報配信装置が実行するクーポン発行処理の流れを示すフローチャートである。 図６は、マッチングの具体例を説明する図である。 図７は、第２の実施形態に係る情報配信装置の処理を説明する図である。 図８は、第３の実施形態に係る情報配信装置の処理を説明する図である。 図９は、マッチング処理の例１を説明する図である。 図１０は、マッチング処理の例２を説明する図である。

以下に、本願の開示する情報配信装置、情報配信方法および情報配信プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

（第１の実施形態）
［１．システム構成］
まず、第１の実施形態に係るシステムの全体構成について説明する。図１は、第１の実施形態に係るシステムの全体構成例を示す図である。図１に示すように、このシステムは、端末装置１と店舗５と情報配信装置１０とを有して構成され、情報配信装置１０が端末装置１に対してクーポンなどの情報を提供するシステムである。

端末装置１は、ユーザが所有する携帯電話やスマートフォンなどの一例であり、インターネットなどのネットワークを介して、情報配信装置１０と通信を実行する。また、端末装置１は、情報配信装置１０に登録された登録ユーザであり、位置情報を定期的に情報配信装置１０に送信する。

店舗５は、ユーザに情報を提供するサービス提供側の一例であり、インターネットなどのネットワークを介して、情報配信装置１０と通信を実行する。また、店舗５は、ユーザに提供する食事や喫茶のメニューと当該メニューの属性とを情報配信装置１０に登録する。なお、店舗５は、メニューが変更された場合や属性を変更した場合に、メニューと属性との登録を随時行う。

情報配信装置１０は、ユーザにクーポン等を提供するサーバ装置の一例である。この情報配信装置１０は、登録ユーザに関する情報を記憶する。例えば、情報配信装置１０は、ユーザ情報として、ユーザの氏名、ユーザＩＤ、住所、電話番号、メールアドレス、性別、年齢等を記憶する。

このような状態において、情報配信装置１０は、店舗５からメニューと当該メニューの属性とを受け付けて、メニューＤＢに登録する（Ｓ１）。例えば、情報配信装置１０は、「店舗情報、メニュー名、属性」として「レストランＡ、コーヒー、雨・暇つぶし・１５分」を記憶する。また、情報配信装置１０は、「店舗情報、メニュー名、属性」として「レストランＡ、サラダ、前菜・ダイエット・３０分」を記憶する。同様に、また、情報配信装置１０は、「店舗情報、メニュー名、属性」として「レストランＡ、定食Ａ、食事・メイン料理・昼夜・１時間」を記憶する。店舗５は、メニューに対して自由に属性を設定できる。

そして、情報配信装置１０は、端末装置１から位置情報を取得する（Ｓ２）。また、情報配信装置１０は、位置情報を取得したタイミングで、当該位置情報に対応する環境情報を外部の天気サーバ４等から取得する（Ｓ３）。ここで取得される位置情報の一例は、住所などであり、環境情報の一例は、「雨、１５分後に止む」などの天気予報である。

次に、情報配信装置１０は、ユーザの位置情報を少なくとも用いて、ユーザの状況を特定する（Ｓ４）。具体的には、情報配信装置１０は、位置情報として住所等を取得し、前回の位置情報および取得時間と、今回の位置情報および取得時間と、環境情報とを用いてユーザの状況を特定する。例えば、情報配信装置１０は、前回取得されたユーザの位置を示す住所が電車の線路上であり、前回から今回までの移動距離や移動時間から２ｋｍを５分で移動したことが特定された場合、今回の位置情報が取得される直前までユーザが電車３に乗車していたと特定する。さらに、情報配信装置１０は、今回の位置情報が駅周辺であることから、現在は電車３から降車していると特定する。これらのことから、情報配信装置１０は、端末装置１のユーザの状況として「直前まで電車に乗車、雨、１５分で止む」を特定する。

続いて、情報配信装置１０は、ユーザの状況とメニュー情報とをマッチングして（Ｓ５）、ユーザの状況を属性として有する提供情報をメニューＤＢから特定する（Ｓ６）。例えば、情報配信装置１０は、特定したユーザの状況「直前まで電車に乗車、雨、１５分で止む」から、属性として「電車、雨、１５分」を抽出する。そして、情報配信装置１０は、メニューＤＢを参照し、属性「電車」に対応付けられるメニューがなく、属性「雨」に対応付けられるメニューが「コーヒー」であり、属性「１５分」に対応付けられるメニューが「コーヒー」であることを特定する。この結果、情報配信装置１０は、ユーザの状況「直前まで電車に乗車、雨、１５分で止む」に対応するメニューとして「レストランＡのコーヒー」を特定する。

その後、情報配信装置１０は、特定されたメニューの情報を端末装置１に配信する（Ｓ７）。例えば、情報配信装置１０は、Ｓ５で特定された「レストランＡのコーヒー」のクーポンを、端末装置１にメール等で配信する。このとき、情報配信装置１０は、クーポンとあわせて、ユーザの現在位置からレストランＡまでの所要時間「レストランＡまで徒歩１分！」や天気サーバ４から取得した天気予報「予報では雨は１５分ほどで止みます！」などを配信する。そして、端末装置１は、配信されたクーポンをバナーやダイアログで画面に表示する。

この結果、端末装置１は、現在の状況に対応して有用なクーポンを自動で取得することができる。また、情報配信装置１０は、天気予報や所要時間などもあわせて通知することで、ユーザにクーポンの使用を促すこともできる。このように、情報配信装置１０は、ユーザが所望する情報を効率的に提供することができる。

また、情報配信装置１０は、クーポンを配信した場合、または、配信されたクーポンが実際に使用された場合に、店舗５へ課金することで、効率的に課金することができ、有用なビジネスモデルを構築することもできる。なお、クーポンが実際に使用されたか否かは、例えば、端末装置１がクーポンアプリや近距離無線通信（NFC：Near Field Communication）を用いて、店舗５にクーポンを送信したか等によって判定することができる。

［２．情報配信装置の構成］
次に、情報配信装置の機能構成を説明する。なお、端末装置１は、一般的なスマートフォン等と同様の機能構成を有し、店舗５や天気サーバ４は、一般的なサーバと同様の機能構成を有するので、ここでは詳細な説明は省略する。

図２は、第１の実施形態に係る情報配信装置の機能構成を示す機能ブロック図である。図２に示すように、情報配信装置１０は、通信部１１と記憶部１２と制御部１５とを有して構成される。

通信部１１は、ＮＩＣ（Network Interface Card）や無線通信インタフェースである。通信部１１は、店舗５と通信を確立して、メニュー情報を受け付ける。また、通信部１１は、端末装置１にクーポンを配信する。また、通信部１１は、端末装置１から位置情報を受信し、天気サーバ４から天気予報を受信する。

記憶部１２は、メモリやハードディスクなどの記憶装置であり、ユーザ情報ＤＢ１３とメニューＤＢ１４とを保持する。なお、記憶部１２は、各店舗の各メニューのクーポンを予め記憶する。ユーザ情報ＤＢ１３は、登録ユーザごとに個人情報や位置情報等を記憶するデータベースである。図３は、ユーザ情報ＤＢに記憶される情報の例を示す図である。

図３に示すように、ユーザ情報ＤＢ１３は、「ユーザ名、嗜好情報、位置ログ、行動情報、環境情報、通知履歴」などを記憶する。なお、ここで示した情報は例示であり、これに限定されるものではなく、例えば、ユーザの氏名、ユーザＩＤ、住所、電話番号、メールアドレス、ユーザが利用しているＳＮＳ（Social Networking Service）などの他サービス情報等なども記憶する。

ここで記憶される「ユーザ名」は、登録済みユーザの名前やＩＤなどユーザを識別する情報であり、例えば「Ｕ００１」などユーザによって設定登録される。「嗜好情報」は、ユーザが登録した嗜好情報であり、例えば「アルコール嫌い」や「ダイエット」などの情報である。「位置ログ」は、後述する位置情報取得部１７によって端末装置１から取得された位置情報の履歴であり、例えば「東京都千代田区・・・」などの情報が時系列で記憶される。「行動情報」は、後述する状況特定部１９によって特定されたユーザの行動を示す情報であり、例えば「直前まで電車移動」、「徒歩移動」、「走行移動」、「停止」、「滞在」などの情報である。「環境情報」は、後述する環境取得部１８によって取得されたユーザの現在位置における環境に関する情報であり、例えば「雨、１５分後に止む予報」、「晴れ」、「紫外線が多い」、「渋滞中」などの情報である。

メニューＤＢ１４は、店舗５から登録されたメニューと属性との対応関係を記憶するデータベースである。図４は、メニューＤＢに記憶される情報の例を示す図である。図４に示すように、メニューＤＢ１４は、「店舗情報、所在地、メニュー名、属性」を対応付けて記憶する。

ここで記憶される「店舗情報」は、店舗名などの登録店舗を識別する情報であり、例えば「レストランＡ」や「喫茶店Ｂ」などの店舗名である。「所在地」は、店舗５によって登録される店舗の所在地を示す情報であり、例えば「東京都千代田区・・・」などである。「メニュー名」は、店舗５によって登録される、店舗５がユーザに提供するメニューを特定する情報であり、例えば「コーヒー」、「サラダ」、「定食Ａ」などである。

「属性」は、店舗５がメニュー名ごとに登録した情報であり、例えばユーザがメニューを利用すると想定される状況を示す情報などである。例としては、「メニュー：コーヒー」に対して属性「雨、暇つぶし、所要時間１５分」が対応付けられる。これは、ユーザがレストランでコーヒーを飲むシチュエーションとして、１５分程度の雨宿りをする場合などが考えられることを想定したものである。また、「メニュー：サラダ」には属性「前菜、ダイエット、所要時間３０分」が対応付けられる。これは、ユーザがレストランでサラダを注文するケースとしては、３０分程度で食することができ、前菜やダイエットメニューとして注文されることを想定したものである。

ここで示した属性の詳細はあくまで例示であり、図示したものに限定されない。例えば、関連度の強いメニュー間では、相互にメニューを属性として登録することもできる。一例を挙げると、コーヒーを飲んだユーザはその後に定食Ａを注文する場合や定食Ａを注文したユーザは食後にコーヒーを注文する場合がある。このことから、メニュー名「コーヒー」に属性「定食Ａ」を対応付けるように、メニュー相互に属性を記憶してもよい。情報配信装置は、メニューＤＢ１４に記憶されたメニュー情報や、店舗の所在地等を店舗毎にユーザに配信する、広告的役割も担っている。

図２に戻り、制御部１５は、情報配信装置１０全体を司る処理部であり、例えばプロセッサなどである。この制御部１５は、メニュー受付部１６と位置情報取得部１７と環境取得部１８と状況特定部１９とマッチング実行部２０とクーポン発行部２１とを有する。

メニュー受付部１６は、店舗５からメニューの入稿を随時受け付けて受け付けた情報をメニューＤＢ１４に格納する処理部である。例えば、メニュー受付部１６は、メニューや属性の新規登録、削除、更新等を随時受け付けて、メニューＤＢ１４を更新する。

位置情報取得部１７は、ユーザが所有する端末装置１からユーザの位置情報を取得する処理部である。例えば、位置情報取得部１７は、ユーザの状況とメニューの属性とをマッチングするタイミングに到達した場合に、ＧＰＳ（Global Positioning System）、Ｗｉ−Ｆｉ（Wireless Fidelity）、端末装置１が登録しているＳＮＳサーバを用いて、端末装置１の現在位置の情報を取得する。そして、位置情報取得部１７は、取得した端末装置１の位置情報を、ユーザ情報ＤＢ１３における端末装置１のレコードの「位置ログ」に格納する。

例えば、位置情報取得部１７は、端末装置１の現在位置を示す住所に限らず、現在位置から想定されるランドマーク名、高速道路、電車等の情報を取得することもできる。

環境取得部１８は、ユーザの位置情報に対応する天気、紫外線、地震、渋滞等の環境情報を取得する処理部である。具体的には、環境取得部１８は、位置情報取得部１７から端末装置１の現在位置を受け付けると、当該現在位置に対応する環境情報を外部サーバ等から取得して、ユーザ情報ＤＢ１３における端末装置１のレコードの「環境情報」に格納する。

例えば、環境取得部１８は、現在位置として「東京都千代田区・・・」を受け付けた場合、天気サーバ４にアクセスして、「東京都千代田区」の天気予報「雨、１５分後に止む」を取得してユーザ情報ＤＢ１３に格納する。また、環境取得部１８は、現在位置が「高速道路」である場合には渋滞の情報を取得し、現在位置が「電車」である場合には遅延状況等を取得する。

状況特定部１９は、位置情報取得部１７によって取得されたユーザの位置情報を少なくとも用いて、ユーザの状況を特定する処理部である。具体的には、状況特定部１９は、端末装置１について、ユーザ情報ＤＢ１３を参照して端末装置１に対応付けられる「位置ログ」を取得し、ユーザの位置履歴を用いて端末装置１の行動履歴を特定してユーザ情報ＤＢ１３の「行動情報」に格納する。また、状況特定部１９は、「行動情報」、「環境情報」、「嗜好情報」などを用いて、ユーザの状況を特定する。

すなわち、状況特定部１９は、「位置ログ」を用いてユーザがどのような手段でどこに移動したかを示す「行動情報」を特定した後、ユーザが置かれている「ユーザの状況」を特定する。なお、状況特定部１９は、必ずしも「行動情報」、「環境情報」、「嗜好情報」を全て用いる必要はなく、少なくとも「行動情報」を用いて特定することができる。

例えば、状況特定部１９は、ユーザ情報ＤＢ１３の「位置ログ」から端末装置１が「所定時間同じ場所にいる」ことを特定すると、「行動情報」を「滞在」と特定する。さらに、状況特定部１９は、「位置ログ」からランドマーク名「Ａタワー」を特定するとともに、ユーザ情報ＤＢ１３に記憶される「環境情報：晴れ」を取得する。この結果、状況特定部１９は、「滞在、Ａタワー、晴れ」をユーザの状況として特定する。

マッチング実行部２０は、状況特定部１９によって特定されたユーザの状況を属性として有するメニュー名をメニューＤＢ１４から特定する処理部である。具体的には、マッチング実行部２０は、状況特定部１９によって特定されたユーザの状況と、メニューＤＢ１４に記憶される各メニューの属性とをマッチングして、所定の条件を満たすメニューを特定する。

このとき、マッチング実行部２０は、端末装置１の現在の位置情報を取得し、当該位置情報から所定距離の範囲内ある店舗をマッチング対象として、以下に説明するマッチング処理を実行する。例えば、現在位置が「東京都千代田区霞ヶ関１丁目付近」であった場合には、マッチング実行部２０は、「東京都千代田区霞ヶ関１丁目付近」から半径１ｋｍ以内または徒歩５分以内に位置する店舗をマッチング対象とする。

ここで、マッチングの一例を説明する。例えば、マッチング実行部２０は、ユーザの状況が「直前まで電車に乗車、雨、１５分」であった場合、各メニューが「電車」、「雨」、「１５分」のうち属性として何個有しているかを計数する。そして、マッチング実行部２０は、２個以上を属性として有しているメニューを、マッチング結果として特定する。なお、マッチング実行部２０は、２個以上有しているメニューが存在しない場合には、マッチング結果なしと判定する。

ここで説明したマッチング手法以外にも、広告や画像等で使用される様々なマッチング手法を用いることができる。例えば、マッチング実行部２０は、メニューに対応付けられる各属性に「重み」を予め対応付けておき、スコア値を算出して、マッチング結果を特定することもできる。

一例を挙げると、メニューＤＢ１４が、「メニュー：コーヒー」に対して属性「雨（重み１．８）、暇つぶし（０．５）、所要時間１５分（１．２）」を対応付けて記憶する場合を想定する。この場合、マッチング実行部２０は、ユーザの状況「電車、雨、１５分」のうち、「メニュー：コーヒー」が「雨（重み１．８）」と「所要時間１５分（１．２）」とを有していると特定する。続いて、マッチング実行部２０は、「メニュー：コーヒー」のスコア値を「１．８＋１．２＝３．０」と算出する。そして、マッチング実行部２０は、このスコア値が所定値以上である場合に、当該メニューをマッチング結果として特定する。

また、マッチング実行部２０は、メニューに対応付けられる属性のうち、ユーザの状況に対応する属性の割合を算出して、マッチング結果を特定することもできる。

一例を挙げると、メニューＤＢ１４が、「メニュー：コーヒー」に対して３つの属性「雨、暇つぶし、所要時間１５分」を対応付けて記憶する場合を想定する。この場合、マッチング実行部２０は、ユーザの状況「電車、雨、１５分」のうち、「メニュー：コーヒー」が属性として「雨、所要時間１５分」を有していると特定する。したがって、マッチング実行部２０は、「メニュー：コーヒー」については３つの対応付けられる属性のうち２つの属性がユーザの状況と一致したと判定する。この結果、マッチング実行部２０は、「メニュー：コーヒー」に対する割合を「２／３＝０．６６６・・・」と算出する。そして、マッチング実行部２０は、この割合が所定値以上である場合に、当該メニューをマッチング結果として特定する。

また、マッチング実行部２０は、メニューに対応付けられた属性を関連語等で拡張してマッチングを行ってもよい。例えば、属性として「ダイエット」が対応付けられている場合に、ダイエットの関連語（例えば、ランニング）を予め定められた辞書等から収集し、この関連語を属性として再付与してマッチングしてもよい。

クーポン発行部２１は、マッチング実行部２０によって特定されたメニューのクーポンを端末装置１に発行する処理部である。具体的には、クーポン発行部２１は、マッチング実行部２０からマッチング結果を受け付けた場合、当該マッチング結果に対応するクーポンを特定して対象の端末装置にメール等で送信する。

例えば、クーポン発行部２１は、端末装置１に対するマッチング結果が「レストランＡのコーヒー」であった場合、「レストランＡのコーヒー」のクーポンを記憶部１２やレストランＡのサーバ等から取得する。そして、クーポン発行部２１は、ユーザ情報ＤＢ１３に記憶される端末装置１のメールアドレスを用いて、「レストランＡのコーヒー」のクーポンを端末装置１に送信する。

［３．処理の流れ］
続いて、第１の実施形態に係る情報配信装置１０の処理の流れを説明する。図５は、第１の実施形態に係る情報配信装置が実行するクーポン発行処理の流れを示すフローチャートである。ここでは、情報配信装置１０は、メニューと属性との対応付けを既に記憶しているものとする。また、情報配信装置１０は、登録されている各ユーザについて図５の処理を実行するが、ここでは、端末装置１について実行する場合を例にして説明する。

図５に示すように、情報配信装置１０の位置情報取得部１７は、端末装置１のマッチングタイミングに到達すると（Ｓ１０１：Ｙｅｓ）、端末装置１から位置情報を取得する（Ｓ１０２）。このとき、位置情報取得部１７は、取得した位置情報をユーザ情報ＤＢ１３の「位置ログ」に格納する。

続いて、環境取得部１８は、位置情報取得部１７によって位置情報が取得されると、Ｓ１０２で取得された端末装置１の位置情報を位置情報取得部１７から受け付け、受け付けた位置情報に対応する環境情報を取得する（Ｓ１０３）。このとき、環境取得部１８は、取得した環境情報をユーザ情報ＤＢ１３の「環境情報」に格納する。

その後、状況特定部１９は、位置情報や環境情報がユーザ情報ＤＢ１３に格納されたことを検知すると、ユーザ情報ＤＢ１３に記憶される位置情報の履歴から、ユーザの行動を特定する（Ｓ１０４）。このとき、状況特定部１９は、取得した行動情報をユーザ情報ＤＢ１３の「行動情報」に格納する。

そして、状況特定部１９は、ユーザ情報ＤＢ１３に記憶される「行動情報」と「環境情報」を用いて、ユーザの状況を特定する（Ｓ１０５）。このとき、状況特定部１９は、ユーザ情報ＤＢ１３に記憶される「嗜好情報」をさらに用いてもよい。なお、状況特定部１９は、特定したユーザの状況をマッチング実行部２０へ出力する。

続いて、マッチング実行部２０は、状況特定部１９からユーザの状況が入力されると、ユーザの状況とメニューの属性とをマッチングする（Ｓ１０６）。このとき、マッチング実行部２０は、端末装置１の現在位置をユーザ情報ＤＢ１３から取得し、現在位置から所定の距離内にある店舗を抽出する。そして、マッチング実行部２０は、抽出した各店舗について、マッチング処理を実行する。

そして、マッチングしたメニューがない場合には（Ｓ１０７：Ｎｏ）、Ｓ１０１に戻って以降の処理が繰り返される。一方、マッチング実行部２０は、マッチングしたメニューがある場合には、マッチングしたメニューをクーポン発行部２１へ通知する（Ｓ１０７：Ｙｅｓ）。

マッチングしたメニューを受け取ったクーポン発行部２１は、当該メニューに対応するクーポンを記憶部１２や店舗５から取得し、ユーザ情報ＤＢ１３に記憶される端末装置１のメールアドレス等を用いて、当該クーポンを端末装置１へ発行する（Ｓ１０８）。

その後、発行されたクーポンが有効期限内に実際に使用された場合（Ｓ１０９：Ｙｅｓ）、クーポン発行部２１は、クーポンが使用された店舗へ課金する（Ｓ１１０）。一方、発行されたクーポンが有効期限内に使用されなかった場合（Ｓ１０９：Ｎｏ）、Ｓ１０１に戻って以降の処理が繰り返される。

［４．具体例］
続いて、上述した具体例以外の例について説明する。図６は、マッチングの具体例を説明する図である。図６に示すシステム構成は、図１と同様である。なお、ここでは、説明上、端末装置１の現在位置から所定距離内にある店舗が「レストランＢ」と仮定する。

図１と異なる点は、端末装置１を保持するユーザが、電車３から降車したところではなく、ランニングしている点である。また、情報配信装置１０は、「店舗情報、メニュー名、属性」として「レストランＢ、コーヒー、雨・ノンアルコール・カロリー１５０」や「レストランＢ、サラダ、軽食・ダイエット・カロリー３００」や「レストランＢ、日替定食、カロリー８００・メイン料理・昼夜」を記憶する点である。

このような状況において、情報配信装置１０の位置情報取得部１７は、マッチングタイミングに到達すると、端末装置１から位置情報を取得して、ユーザ情報ＤＢ１３に格納する（Ｓ１１）。また、環境取得部１８は、位置情報取得部１７によって位置情報が取得されると、取得された位置に対応する天気予報「晴れ」を天気サーバ４から取得して、ユーザ情報ＤＢ１３に格納する（Ｓ１２）。

その後、状況特定部１９は、ユーザの状況を特定する（Ｓ１３）。具体的には、状況特定部１９は、ユーザの位置ログから「ユーザが１ｋｍを１０分で移動した」ことが特定された場合、ユーザの行動情報を「ランニング中」と特定してユーザ情報ＤＢ１３に格納する。また、状況特定部１９は、ユーザによって予め登録されたユーザ情報から「年齢、体重、身長、体脂肪」等を取得して、「１ｋｍ、１０分」のランニングでの消費カロリー「３００ｃａｌ」を算出する。また、状況特定部１９は、ユーザによって予め登録されたユーザ情報から嗜好情報として「禁酒、ダイエット中」を取得する。

これらの結果、状況特定部１９は、上記行動情報、環境情報、嗜好情報等を用いて、端末装置１のユーザの状況を「ランニング中、消費カロリー（３００ｃａｌ）、晴れ、ダイエット、ノンアルコール」と特定する。なお、消費カロリーの計算は、状況特定部１９が一般的なアルゴリズムを用いて算出することができる。

続いて、マッチング実行部２０は、ユーザの状況「ランニング中、消費カロリー（３００ｃａｌ）、晴れ、ダイエット、ノンアルコール」と、メニューの「属性」とのマッチングを実行する（Ｓ１４）。この例では、マッチング実行部２０は、レストランＢのメニュー「コーヒー」については、属性「ノンアルコール」が一致すると判定する。また、マッチング実行部２０は、レストランＢのメニュー「サラダ」については、属性「ダイエット」と「カロリー３００」とが一致すると判定する。また、マッチング実行部２０は、レストランＢのメニュー「日替定食」については、いずれの属性も一致しないと判定する。

この結果、マッチング実行部２０は、属性が一致した個数が最も多くかつ閾値以上である「サラダ」を、マッチング結果として特定する（Ｓ１５）。その後、クーポン発行部２１は、レストランＢのサラダに対するクーポンを、端末装置１に発行する（Ｓ１６）。

［５．第１の実施形態による効果］
第１の実施形態によれば、情報配信装置１０は、ユーザの端末装置１から取得した位置ログ、環境情報、嗜好情報などを用いて、発行するクーポンを特定するので、ユーザが店舗のサーバへアクセスする必要がない。このため、ユーザのクーポン取得までの煩わしさを簡素化できる。

また、情報配信装置１０は、ユーザの位置ログや環境を随時取得することで、ユーザの行動や嗜好の変化に追従することができるので、ユーザにとって有用なタイミングで有用なクーポンを配信することができ、訴求率を高めることができる。また、情報配信装置１０は、ユーザの現在位置が利用可能なクーポンを、ユーザ所持する端末装置１に配信することができるので、ユーザのクーポンの利用意識を向上させることができる。

また、情報配信装置１０は、ユーザがダイエット中である場合には消費カロリーの少ないメニューや消費したカロリー分のメニューなど、ユーザの嗜好に合致したクーポンを取捨選択して配信することができるので、クーポンの利用率の向上が期待できる。

また、メニューに属性を付与して情報配信装置１０に登録することで、ユーザに直接的にメニューを提供して来店までに誘導できることが期待できるので、店舗５は、メニューＤＢ１４の更新を行う。従って、情報配信装置１０が提供する情報の更新頻度が高まり、広告効果も高まる。

（第２の実施形態）
ところで、第１の実施形態では、情報配信装置１０がメニューの関連性に関係なくマッチング処理を実行する例を説明したが、これに限定されるものではない。そこで、第２の実施形態では、メニュー間の関連性を考慮して、マッチング処理を行う例を説明する。

具体的には、情報配信装置１０の状況特定部１９は、メニューが配信されてから所定時間経過後もユーザの位置情報に変化がないか否かを特定する。そして、マッチング実行部２０は、状況特定部１９によって所定時間経過後もユーザの位置情報に変化がないと特定された場合、所定時間経過後に取得されたユーザの位置情報から特定されたユーザの状況と、配信済みのメニューのクーポンに関連する関連情報とを、属性として有するメニューをメニューＤＢ１４から特定する。

図７は、第２の実施形態に係る情報配信装置の処理を説明する図である。図７に示すように、まず、情報配信装置１０は、ユーザの端末装置１から位置情報を取得し、レストランＡにいることを特定する。また、情報配信装置１０は、ユーザの現在位置の天気が「雨」で「１５分後に止む」ことを取得する。この場合、情報配信装置１０は、ユーザの状況「雨、１５分」にマッチングするメニューとして「コーヒー」を特定し、「レストランＡのコーヒー」のクーポンを端末装置１に配信する。

２０分後、情報配信装置１０は、ユーザの端末装置１から位置情報を取得し、まだレストランＡにいることを特定する。ここで、ユーザの滞在時間２０分は閾値未満とする。この場合、情報配信装置１０は、ユーザの状況「雨」にマッチングするレストランＡのメニューがないことから、クーポンを端末装置１へ配信しない。

さらに１０分後、情報配信装置１０は、ユーザの端末装置１から位置情報を取得し、まだレストランＡにいることを特定する。ここで、ユーザの滞在時間３０分は閾値を超えるものとする。また、滞在している間に１２：００を過ぎたものとする。この場合、情報配信装置１０は、ユーザの状況「雨、昼」に、３０分前に配信したクーポン「コーヒー」を加えた「雨、昼、コーヒー」をユーザの状況と決定する。そして、情報配信装置１０は、ユーザの状況「雨、昼、コーヒー」にマッチングするメニューとして「定食」を特定し、「レストランＡの定食」のクーポンを端末装置１に配信する。このとき、情報配信装置１０は、「レストランまで徒歩３分」や「消費カロリーは３００ｃａｌです」など、ユーザの状況を特定する際に用いた各種情報をあわせて配信することもできる。

このように、第２の実施形態によれば、ユーザの状況に変化がない場合に、同じクーポンを何度も配信することを抑制できるので、ユーザの利用意欲の低下やクーポンの乱用を抑制できる。また、情報配信装置１０は、ユーザが店舗に長居する場合であっても、異なるクーポンを定期的にユーザに配信することができる。このため、店舗側にとっても、クーポンを使ってメニューを消費してもらえる可能性が高くなり、利益の向上を図れる。また、店舗側は、クーポンの利用率を向上させるために、メニューの関連性を調査して随時設定しなおすことが予想されるので、ユーザの利用意欲を向上させるクーポンのマッチングが期待できる。

（第３の実施形態）
第１の実施形態や第２の実施形態では、ユーザが個人で行動している場合を想定した例を説明したが、これに限定されるものではない。例えば、最初、個人で行動しており、その後に、グループで行動する場合も考えられ、同様に、最初、グループで行動しており、その後に、個人で行動する場合も考えられる。

そこで、第３の実施形態では、一例として、端末装置１を保持するユーザが最初個人で行動しており、その後にグループで行動する例を説明する。図８は、第３の実施形態に係る情報配信装置の処理を説明する図である。なお、ここでは、説明上、端末装置１の現在位置から所定距離内にある店舗が「レストランＡ」と仮定する。

図８に示すように、まず、情報配信装置１０は、電車３から降車したユーザの端末装置１から位置情報を取得するとともに、当該位置情報に対応する環境情報を取得する。ここでは、情報配信装置１０は、位置情報や環境情報から、ユーザの状況「雨、雨が止むまで１５分」を特定する。さらに、情報配信装置１０は、当該端末装置１が利用しているＳＮＳサーバ６にアクセスし、チェックイン機能等を用いて端末装置１のユーザが「１人」であることを特定する。この結果、最終的に、情報配信装置１０は、ユーザの状況を「雨、雨が止むまで１５分、１人」と特定する。

この場合、情報配信装置１０は、ユーザの状況「雨、雨が止むまで１５分、１人」にマッチングするメニューとして「コーヒー」を特定し、「レストランＡのコーヒー」のクーポンを端末装置１に発行する。つまり、情報配信装置１０は、個人に対応付けられているメニューや店舗の中から、ユーザの状況にマッチングするメニューを特定する。

次に、情報配信装置１０は、レストランＡに移動したユーザの端末装置１から位置情報を取得するとともに、当該位置情報に対応する環境情報を取得する。ここでは、情報配信装置１０は、位置情報や環境情報から、ユーザの状況「雨」を特定する。さらに、情報配信装置１０は、当該端末装置１が利用しているＳＮＳサーバ６にアクセスし、チェックイン機能等を用いて端末装置１のユーザが「１人」であることを特定する。この結果、最終的に、情報配信装置１０は、ユーザの状況を「雨、１人」と特定する。

この場合、情報配信装置１０は、ユーザの状況「雨、１人」にマッチングするメニューが存在しないことから、端末装置１へクーポンを発行しない。

その後、情報配信装置１０は、レストランＡに滞在するユーザの端末装置１から位置情報を取得するとともに、当該位置情報に対応する環境情報を取得する。ここでは、情報配信装置１０は、位置情報や環境情報から、ユーザの状況「雨、遊び」を特定する。さらに、情報配信装置１０は、当該端末装置１が利用しているＳＮＳサーバ６にアクセスし、チェックイン機能等を用いて端末装置１のユーザが「１人」から「グループ」に変更されたことを特定する。この結果、最終的に、情報配信装置１０は、ユーザの状況を「雨、遊び、グループ」と特定する。

この場合、情報配信装置１０は、ユーザの状況「雨、遊び、グループ」にマッチングする店舗として「カラオケ」を特定し、「カラオケの基本料割引」のクーポンを端末装置１に発行する。つまり、情報配信装置１０は、最初個人に対応付けられているメニューや店舗の中からマッチング処理を実行していたが、グループに変更されたことを検出すると、個人ではなくグループに対応付けられているメニューや店舗の中からマッチング処理を実行する。

ここで、個人とグループとでマッチングが異なる具体例を説明する。図９は、マッチング処理の例１を説明する図である。図９に示すように、情報配信装置１０は、各店舗の各メニューの属性の１つとして「個人」か「グループ」かを記憶する。そして、情報配信装置１０は、ユーザの状況に「１人」が含まれる場合、属性として「個人」を含むメニューを用いてマッチング処理を実行する。同様に、情報配信装置１０は、ユーザの状況に「グループ」が含まれる場合、属性として「グループ」を含むメニューを用いてマッチング処理を実行する。

図９の場合、情報配信装置１０は、ユーザ状況が「１人、雨」である場合には、属性として「個人」を有する「レストランＡ」と「マッサージ」とをマッチング対象として選択して、上述した属性のマッチング処理を実行する。一方、情報配信装置１０は、ユーザ状況が「グループ、雨、遊び」である場合には、属性として「グループ」を有する「カラオケ」をマッチング対象として選択して、上述した属性のマッチング処理を実行する。

図１０は、マッチング処理の例２を説明する図である。図１０に示すように、情報配信装置１０は、各メニューの属性ごとに、個人とグループのそれぞれの場合の「重み」を対応付けて記憶する。例えば、メニュー「コーヒー」の属性「雨」は、個人の場合には重みが「１．５」となり、グループの場合には重みが「０．５」となる。これは、個人とグループとでは、メニューの選択率が異なることから、個人向けのメニューとグループ向けのメニューとを区別するためです。

また、図１０では、属性ごとに重みを対応付ける例を図示したが、これに限定されるものではない。例えば、メニューごとに重み付けをしてもよく、店舗ごとに重み付けをしてもよい。なお、重みを用いたマッチング処理は、第１の実施形態で説明したスコア値の算出方法等を用いることができるので、詳細な説明は省略する。

このように、第３の実施形態によれば、情報配信装置１０は、個人かグループかに適したマッチング対象を選択することができるので、個人の場合には個人に適したクーポン、グループの場合にはグループに適したクーポンを発行することができる。このため、個人かグループかを区別しない場合に比べて、ユーザの使用意欲を向上させるクーポンをユーザに発行できるので、クーポンの使用率を向上させることができる。

また、情報配信装置１０は、ユーザの行動人数が変更された場合でも、マッチング対象を動的に変更して、ユーザの状況に追従することができ、ユーザの状況を的確に反映させた有用なクーポンの配信できる。また、情報配信装置１０は、ユーザの行動人数が個人からグループに変更された場合でも、個人に対応するクーポンを配信し続けるなどの不要な処理を抑制できる。なお、第３の実施形態は、個人からグループへ変更された例を説明したが、グループから個人へ変更された場合でも、同様の手法で処理することができる。

（第４の実施形態）
上述した情報配信装置１０は、上記第１の実施形態から第３の実施形態以外にも様々な形態で実施することができる。例えば、上記実施形態では、店舗のメニューを例にして説明したが、これ以外にも、例えばマッサージなどユーザに提供するサービスであっても同様に処理することができる。例えば、情報配信装置１０は、ユーザが家に長時間滞在していることを特定すると、インターネットオークションへの出品割引などのクーポンを発行することもできる。

また、第２の実施形態では、情報配信装置１０は、属性の１つとして関連するメニューを記憶する例を説明したが、これに限定されるものではない。具体的には、情報配信装置１０は、発行されたクーポンが実際に使用されたか否かにって、関連度（重み）が変わるようにしてもよい。例えば、情報配信装置１０は、クーポンが実際に使用された場合には重みを２倍にしてスコア値を計算することもできる。

また、実施形態に記載した「部」は、「手段」や「section、module、unit」や「回路」などに読み替えることができる。例えば、メニュー受付部は、メニュー受付手段やメニュー受付回路に読み替えることができる。また、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれ、各実施形態を組み合わせることもできる。

１ 端末装置
３ 電車
４ 天気サーバ
５ 店舗
６ ＳＮＳサーバ
１０ 情報配信装置
１１ 通信部
１２ 記憶部
１３ ユーザ情報ＤＢ
１４ メニューＤＢ
１５ 制御部
１６ メニュー受付部
１７ 位置情報取得部
１８ 環境取得部
１９ 状況特定部
２０ マッチング実行部
２１ クーポン発行部

Claims (7)

1. ユーザに提供される各商品の属性を記憶する記憶手段と、
   前記ユーザが所有する通信装置から前記ユーザの位置情報を取得する取得手段と、
   前記取得手段によって取得されたユーザの位置情報を少なくとも用いて、前記ユーザの状況を特定する状況特定手段と、
   前記状況特定手段によって特定されたユーザの状況を前記属性として有する前記商品を前記記憶手段から特定する情報特定手段と、
   前記情報特定手段によって特定された商品を前記通信装置に配信する配信手段と
   を有し、
   前記状況特定手段は、前記配信手段によって商品が前記通信装置に配信されてから所定時間経過後も前記ユーザの位置情報に変化がないか否かを特定し、
   前記情報特定手段は、前記状況特定手段によって前記所定時間経過後も前記ユーザの位置情報に変化がないと特定された場合、前記所定時間経過後に前記取得手段が取得した前記ユーザの位置情報から特定された前記ユーザの状況と、前記配信手段によって配信済みの前記商品に関連する関連情報とを、前記属性として有する前記商品を前記記憶手段から特定することを特徴とする情報配信装置。
2. 前記状況特定手段は、前記ユーザの行動人数が個人か、または、グループかをさらに特定し、
   前記情報特定手段は、前記状況特定手段によって特定された行動人数に対応する前記商品の中から、前記ユーザの状況を前記属性として有する前記商品を前記記憶手段から特定することを特徴とする請求項１に記載の情報配信装置。
3. 前記情報特定手段は、前記状況特定手段によって特定された行動人数が前回特定された行動人数から変化した場合に、変化後の行動人数に対応する前記商品の中から、前記ユーザの状況を前記属性として有する前記商品を前記記憶手段から特定することを特徴とする請求項２に記載の情報配信装置。
4. 前記状況特定手段は、前記ユーザの位置情報を用いて、前記ユーザの移動距離および移動方法を特定して、前記ユーザが移動で消費した消費カロリーを算出し、
   前記情報特定手段は、前記状況特定手段によって算出された消費カロリーを前記属性として有する前記商品を前記記憶手段から特定することを特徴とする請求項１から３のいずれか一つに記載の情報配信装置。
5. 前記配信手段は、前記商品に利用できるクーポンを前記ユーザの通信装置に配信し、
   前記配信手段によってクーポンが配信された場合、または、前記配信されたクーポンが前記ユーザによって利用された場合に、前記サービスの提供元に課金する課金手段をさらに有することを特徴とする請求項１から４のいずれか一つに記載の情報配信装置。
6. 情報配信装置が実行する情報配信方法であって、
   ユーザが所有する通信装置からユーザの位置情報を取得する取得工程と、
   前記取得工程によって取得されたユーザの位置情報を少なくとも用いて、前記ユーザの状況を特定する状況特定工程と、
   ユーザに提供される各商品の属性を記憶する記憶手段を参照して、前記状況特定工程によって特定されたユーザの状況を前記属性として有する前記商品を特定する情報特定工程と、
   前記情報特定工程によって特定された商品を前記通信装置に配信する配信工程と
   を含み、
   前記状況特定工程は、前記配信工程によって商品が前記通信装置に配信されてから所定時間経過後も前記ユーザの位置情報に変化がないか否かを特定し、
   前記情報特定工程は、前記状況特定工程によって前記所定時間経過後も前記ユーザの位置情報に変化がないと特定された場合、前記所定時間経過後に前記取得工程が取得した前記ユーザの位置情報から特定された前記ユーザの状況と、前記配信工程によって配信済みの前記商品に関連する関連情報とを、前記属性として有する前記商品を前記記憶手段から特定することを特徴とする情報配信方法。
7. ユーザが所有する通信装置からユーザの位置情報を取得する取得手順と、
   前記取得手順によって取得されたユーザの位置情報を少なくとも用いて、前記ユーザの状況を特定する状況特定手順と、
   ユーザに提供される各商品の属性を記憶する記憶手段を参照して、前記状況特定手順によって特定されたユーザの状況を前記属性として有する前記商品を特定する情報特定手順と、
   前記情報特定手順によって特定された商品を前記通信装置に配信する配信手順と
   をコンピュータに実行させ、
   前記状況特定手順は、前記配信手順によって商品が前記通信装置に配信されてから所定時間経過後も前記ユーザの位置情報に変化がないか否かを特定し、
   前記情報特定手順は、前記状況特定手順によって前記所定時間経過後も前記ユーザの位置情報に変化がないと特定された場合、前記所定時間経過後に前記取得手順が取得した前記ユーザの位置情報から特定された前記ユーザの状況と、前記配信手順によって配信済みの前記商品に関連する関連情報とを、前記属性として有する前記商品を前記記憶手段から特定することを特徴とする情報配信プログラム。
   

Images