JP6945400B2 - 情報配信システム、情報配信装置、情報配信用プログラム、情報提供装置および情報提供用プログラム - Google Patents

Description

本発明は、情報配信システム、情報配信装置、情報配信用プログラム、情報提供装置および情報提供用プログラムに関し、特に、雨具を提供する店舗に関する情報を通知可能な情報配信システムおよび情報配信装置、この情報配信装置のコンピュータに実行される情報配信用プログラム、また、雨具を提供する店舗に関する情報を提供可能な情報提供装置、この情報提供装置のコンピュータに実行される情報提供用プログラムに用いて好適なものである。

一般に、店舗を訪れる顧客の数は、天気に左右されることが多い。例えば、雨の日には、繁華街にある店であっても、通常の日の半数程度に顧客数が減ってしまうこともある。そのため、雨等の特定の天気の日に、メニューの値段を割り引く等の特定のサービスを提供することにより、顧客の減少を最小限に抑えようとする試みが多くの店舗で行われている。

近年では、店舗の広告やクーポン等をスマートフォン等の携帯端末に配信するサービスが増えている。このような配信サービスを利用すれば、大量の顧客に有益な情報をリアルタイムに届けることができるというメリットがある。従来、対象エリアの対象時刻の気象情報の中に雨などの特定の天気が現れるときに、特定の天気に関する特典情報を含むメールを配信するようにしたシステムも知られている（例えば、特許文献１参照）。

また、雨が降ってきたときに店舗を訪れた人に、傘を貸し出すサービスも知られている。雨が降っているとき、傘を持っていない人は、このようなサービスを利用して、傘を借りることができ、また、店舗は、販売機会を増やすことができ、双方にとってメリットがある。

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

特許文献１に記載のシステムでは、例えば、ユーザが指定したエリアで、ユーザが指定したメール配信時刻の気象情報の中に雨天が含まれている場合に、「雨の日に限り全品半額」といった雨天に関する特典情報を含むメールを配信する。この特許文献１に記載のシステムに、上述した傘の貸し出しに関するサービスを応用して、ユーザが指定したメール配信時刻の気象情報の中に雨天が含まれている場合に、上述した傘を貸し出すサービスを行っている店舗を紹介する情報を含むメールを配信することが可能である。しかしながら、この場合、ユーザが傘を所持しているか否かにかかわらず、メール配信時刻に雨が降っていれば、一律に、同じ内容のメールがユーザに対して必ず配信されてしまい、ユーザの傘の提供に対するニーズに的確に応じていないケースが生じることが想定される。

本発明は、このような問題を解決するために成されたものであり、雨具を提供する店舗に関する情報を通知するシステムにおいて、ユーザの傘の提供に対するニーズに応じた態様で、雨具を提供する店舗に関する情報をユーザに通知できるようにすることを目的とする。

上記した課題を解決するために、本発明では、情報配信システムの情報配信サーバは、ユーザに由来する地域の天気の推移を取得し、天気の推移に基づいて、ユーザが雨具を所持していない可能性の高さを判定し、ユーザが雨具を所持していない可能性の高さに応じた態様で、雨具を提供する店舗に関する情報の通知に関する処理を実行する。

天気の推移と、ユーザが雨具を備えていない可能性の高さとは無関係なものではなく、雨具を要しない天気から雨具を要する天気へと推移している場合にユーザが雨具を備えていない可能性が高くなる等、所定の関係がある。これを踏まえ、上記のように構成した本発明によれば、天気の推移に基づいて、ユーザが雨具を備えていない可能性の高さが適切に判定された上で、当該可能性の高さに応じた態様で、雨具を提供する店舗に関する情報の通知に関する処理が実行される。このため、ユーザが雨具を備えていない可能性の高さ、つまりユーザの傘に対するニーズを考慮した適切な態様で、情報の通知に関する処理を行うことが可能となる。

本発明の第１実施形態に係る情報配信システムの構成例を示す図である。 本発明の第１実施形態に係る情報配信サーバの機能構成例を示すブロック図である。 本発明の第１実施形態に係るユーザ情報入力画面の一例を示す図である。 本発明の第１実施形態に係る各種データベースが有する１件のレコードの内容の一例を示す図である。 ユーザ端末のロック画面に表示されるメッセージの一例を示す図である ユーザ端末に表示される画面の一例を示す図である。 本発明の第１実施形態に係る情報配信サーバの処理の一例を示すフローチャートである。 本発明の第１実施形態に係る情報配信サーバの処理の一例を示すフローチャートである。 本発明の第１実施形態の変形例に係るユーザ情報入力画面の一例を示す図である。 本発明の第２実施形態に係るユーザ端末の機能構成例を示すブロック図である。

＜第１実施形態＞
以下、本発明の第１実施形態を図面に基づいて説明する。図１は、本実施形態に係る情報配信システム１の構成例を示す図である。図１に示すように、情報配信システム１は、情報配信サーバ２（特許請求の範囲の「情報配信装置」に相当）と、複数のユーザ端末３とを備えている。情報配信サーバ２およびユーザ端末３は、それぞれ、インターネット、電話網、その他の通信網を含んで構成されたネットワークＮにアクセス可能である。

ネットワークＮには、天気情報公開サーバ４が接続されている。天気情報公開サーバ４は、予め区分された地域ごとに、現時点から相当の期間（例えば２４時間）の範囲について、所定の時間帯ごと（例えば、「００：００」を起点として１時間ごと）の予報天気を公開する。天気情報公開サーバ４は、公開する予報天気を、予め定められた時刻（例えば、「００：００」を起点として２時間ごと）が到来するたびに、随時、更新する。

さらに、天気情報公開サーバ４は、予め区分された地域のそれぞれについて、現時点を含み、現時点から相当の期間（例えば２４時間）を遡った範囲について、所定の時間帯ごと（例えば、「００：００」を起点として１時間ごと）の実際の天気を公開する。本実施形態では、雨具を要する天気として「雨」があり、雨具を要しない天気として「晴」があるものとする。ただし、天気として「雨」および「晴」があるとするのは、実施形態を明確にするため、あくまで説明の便宜を考慮したものであり、例えば、雨具を要する天気に「雪」や、「ひょう」、「みぞれ」等を含む構成でもよく、雨具を要しない天気に「曇」を含む構成でもよい。すなわち、雨具を要する天気、要しない天気は、雨具の必要性に応じて適切に設定される。

ユーザ端末３は、ユーザが所有する端末である。本実施形態では、ユーザ端末３は、板状の筐体の前面の広い領域にタッチパネル３ａが設けられたタブレット端末（例えば、スマートフォンや、タブレット型コンピュータ）であるものとする。ただし、ユーザ端末３は、後述する各種処理が実行可能な装置であればよく、例えば、ノート型コンピュータや、ウェアラブル端末（例えば、腕時計型のウェアラブル端末）をユーザ端末３として用いることができる。

情報配信サーバ２は、雨が降っているときに来店した顧客に対して傘を提供するサービスを行っている店舗（以下、「雨具提供店舗」という）に関する情報を、ユーザ端末３に通知する、というサービスを提供するサーバ装置である。傘を提供するとは、傘を貸し出したり、傘を無料で受け渡すことを意味する。例えば、雨が降っている状況で、勤務先の会社を退社した会社員や、大学を下校する大学生が傘を持っていない場合、雨具提供店舗に行くことにより、傘を利用することができ、また、雨具提供店舗では、販売機会を増やすことができ、双方にとってメリットがある。以下、情報配信サーバ２の構成、機能および処理について詳述する。

図２は、情報配信サーバ２の機能構成例を示すブロック図である。情報配信サーバ２は、ネットワークＮに接続されたサーバ装置である。図１および図２では、情報配信サーバ２を１つのブロックにより表しているが、これは情報配信サーバ２が単一の装置により構成されることを意味するするものではない。情報配信サーバ２は、複数の装置により構成されてもよく、所定のシステムの一部であってもよい。

図２に示すように、情報配信サーバ２は、機能構成として、通信部１０、ユーザ情報登録部１１、通知曜日決定部１２、通知タイミング決定部１３、天気取得タイミング決定部１４、店舗情報登録部１５、天気推移取得部１６、不所持可能性判定部１７および情報通知部１８を備えている。また、情報配信サーバ２は、記憶媒体として、ユーザ情報記憶部２０、店舗情報記憶部２１、天気推移情報記憶部２２および不所持可能性情報記憶部２３を備えている。上記各機能ブロック１０〜１８は、ハードウェア、ＤＳＰ（Digital Signal Processor）、ソフトウェアの何れによっても構成することが可能である。例えばソフトウェアによって構成する場合、上記各機能ブロック１０〜１８は、実際にはコンピュータのＣＰＵ、ＲＡＭ、ＲＯＭなどを備えて構成され、ＲＡＭやＲＯＭ、ハードディスクまたは半導体メモリ等の記録媒体に記憶されたプログラムが動作することによって実現される。以上のことは、後述する他の機能ブロックについても同様である。

上記各機能ブロック１０〜１８の機能は、上記プログラムを例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。上記プログラムを記録する記録媒体としては、ＣＤ−ＲＯＭ以外に、フレキシブルディスク、ハードディスク、磁気テープ、光ディスク、光磁気ディスク、ＤＶＤ、不揮発性メモリカード等を用いることができる。また、上記プログラムをインターネット等のネットワークを介してコンピュータにダウンロードすることによっても実現できる。以上のことは、後述する他の機能ブロックについても同様である。

通信部１０は、所定の通信規格に従って、ネットワークＮにアクセスし、ネットワークＮと接続する機器（ユーザ端末３および天気情報公開サーバ４を含む）と通信する。

ユーザ情報記憶部２０は、ユーザ情報データベース２０ａを記憶する。ユーザ情報データベース２０ａの内容については後述する。

ユーザ情報登録部１１は、雨具提供店舗に関する情報の通知を希望するユーザについて、ユーザの登録を行う。以下、ユーザ情報登録部１１の処理について詳述する。

雨具提供店舗に関する情報の通知を希望するユーザは、事前に、ユーザ端末３に専用のアプリケーション（以下、「専用アプリケーション」という）をインストールする。ユーザ端末３にインストールされた専用アプリケーションが初めて起動されると、ユーザ端末３は、専用アプリケーションの機能により、情報配信サーバ２の所定のＵＲＬにアクセスする。情報配信サーバ２のユーザ情報登録部１１は、当該所定のＵＲＬへのアクセスに応じて、ユーザ情報入力画面ＵＩ３の表示に係る描画データ（例えば、ＨＴＭＬデータ）を生成し、ユーザ端末３に送信する。ユーザ端末３は、専用アプリケーションの機能により、描画データに基づいて、ユーザ情報入力画面ＵＩ３をタッチパネル３ａに表示する。

図３は、ユーザ情報入力画面ＵＩ３の一例を示す図である。図３に示すように、ユーザ情報入力画面ＵＩ３は、ユーザの属性を入力する属性入力欄Ｒ３ａを有する。ユーザの属性とは、社会におけるユーザの所属や、身分であり、例えば、会社員や、大学生、主婦等である。属性入力欄Ｒ３ａに入力可能な属性として、複数の属性が予め用意されている。属性入力欄Ｒ３ａは、プルダウンメニューを有しており、プルダウンメニューには、選択可能な属性が選択項目として一覧表示される。本実施形態では、ユーザが選択可能な属性として、「会社員」、「大学生」、「主婦」が用意されているものとする。ただし、これら属性は、説明の便宜を考慮して限定したものである。実際には、他の属性を用意してもよく、また、より細かく分類された属性を用意してもよい。一例として、営業職や、エンジニア等、会社員をさらに、職種に応じて分類してもよい。ユーザは、プルダウンメニューに一覧表示された属性の候補から、自身の属性を選択することによって、属性入力欄Ｒ３ａへの入力を行う。

図３に示すように、ユーザ情報入力画面ＵＩ３は、対象地域を入力する対象地域入力欄Ｒ３ｂを有する。対象地域とは、ユーザが、一日の初めに自宅から出た後に、定期的に、または、頻繁に通う施設（以下、「対象施設」という）の位置が属する地域である。対象施設では、ユーザが家を出るとき傘を持参しなかったことに起因して、ユーザが傘を所持していない状況で屋内から屋外へ移動する必要が生じる場合がある。例えば、ユーザが会社員である場合、勤務先の会社（対象施設）の位置が属する地域が対象地域に相当し、また、ユーザが大学生である場合、通学する学校（対象施設）の位置が属する地位が対象地域に相当する。対象地域は、特許請求の範囲の「ユーザに由来する地域」、「所定の地域」に相当する。

本実施形態では、対象地域入力欄Ｒ３ｂに入力可能な対象地域として、天気情報公開サーバ４が予報天気を公開する地域のそれぞれが用意されている。対象地域入力欄Ｒ３ｂは、プルダウンメニューを有しており、プルダウンメニューには、選択可能な対象地域の候補が選択項目として一覧表示される。ユーザは、プルダウンメニューに一覧表示された対象地域の候補から、所望の対象地域を選択することによって、属性入力欄Ｒ３ａへの入力を行う。

図３に示すように、ユーザ情報入力画面ＵＩ３は、通知方法選択欄Ｓ３を有する。本実施形態では、雨具提供店舗に関する情報の通知方法として、「プッシュ通知」、「メール配信」、「プッシュ通知およびメール配信」の３つの方法が用意されている。周知のとおり、プッシュ通知は、アプリケーション（本例の場合は、専用アプリケーション）が起動しているか否かにかかわらず、メッセージを送信する機能であり、ユーザ端末３に対してプッシュ通知によりメッセージが送信されると、ユーザの設定に応じて、ロック画面へ情報が表示されたり、アイコンにバッジが表示されたりする。ユーザは、通知方法選択欄Ｓ３のラジオボタンを用いて、いずれか１つの通知方法を選択する。なお、通知方法として、「メール配信」または「プッシュ通知およびメール配信」を選択した場合、ユーザは、メールアドレス入力欄Ｒ３ｃに、メールアドレスを入力する。また、通知方法として、「プッシュ通知」または「プッシュ通知およびメール配信」が選択された場合、ユーザにプッシュ通知の許可を求めるダイアログが表示され、適切にプッシュ通知についてのユーザの許可が得られた上で、所定のサーバによりプッシュ通知で使用するデバイス識別情報が発行され、専用アプリケーションに通知される。

図３に示すように、ユーザ情報入力画面ＵＩ３は確定ボタンＢ３を有する。確定ボタンＢ３は、ユーザ情報入力画面ＵＩ３への入力を確定する際に操作されるボタンである。ユーザは、ユーザ情報入力画面ＵＩ３への入力を完了した後、確定ボタンＢ３を操作する。

確定ボタンＢ３が操作されると、ユーザ端末３は、専用アプリケーションの機能により、ユーザ情報入力画面ＵＩ３に入力された情報を含むユーザ情報を情報配信サーバ２に送信する。ユーザ情報は、ユーザの属性を示す属性情報、対象地域を示す対象地域情報、ユーザが選択した通知方法を示す通知方法情報、ユーザのメールアドレス（ただし、通知方法にメール配信を含まない場合はヌル値）、および、プッシュ通知関連情報（ただし、通知方法にプッシュ通知を含まない場合はヌル値）を含む情報である。プッシュ通知関連情報は、デバイス識別情報等の、情報配信サーバ２がユーザ端末３に対してプッシュ通知を行うために必要な情報である。

情報配信サーバ２のユーザ情報登録部１１は、ユーザ情報を受信し、ユーザ情報記憶部２０が記憶するユーザ情報データベース２０ａに１件のレコードを登録する。詳述すると、ユーザ情報登録部１１は、一のユーザ情報の受信に応じて、固有のユーザＩＤを生成する。そして、生成したユーザＩＤと、当該一のユーザ情報と、通知曜日情報と、通知タイミング情報と、天気取得タイミング情報とを含むレコードを、ユーザ情報データベース２０ａに新たに登録する。レコードの登録時は、通知曜日情報、通知タイミング情報および天気取得タイミング情報は、ヌル値である。これら情報については後述する。図４（Ａ）は、ユーザ情報データベース２０ａの１件のレコードの内容を示している。ユーザ情報登録部１１がユーザ情報データベース２０ａにレコードを登録することが、ユーザの登録に相当する。一のユーザに係るレコードのユーザ情報データベース２０ａへの登録が完了すると（＝一のユーザの登録が完了すると）、当該一のユーザが、雨具提供店舗に関する情報の通知の対象となる。なお、ユーザは、所定の手段で、登録されたレコードの内容の変更、レコードの削除を行うことができる。

なお、ユーザ情報登録部１１は、以上のようにしてユーザの属性を取得する機能ブロックであり、特許請求の範囲の「属性取得部」に相当する。本実施形態では、属性取得部たるユーザ情報登録部１１は、ユーザによりユーザ情報入力画面ＵＩ３に入力された属性を取得する。ただし、ユーザ情報登録部１１が、属性を取得する方法は、本実施形態で例示した方法に限らない。例えば、ユーザが、ソーシャル・ネットワーキング・サービスを利用している場合は、ユーザ情報登録部１１が、プライバシーに関する規定が的確に順守された上で、ユーザが投稿等したコメント、メッセージを分析し、ユーザの属性を推定し、取得する構成でもよい。

通知曜日決定部１２は、ユーザ情報登録部１１によって、ユーザ情報データベース２０ａに新たにレコードが登録された場合に、新たに登録されたレコードの通知曜日情報の値を更新する。一のユーザに係る通知曜日情報は、当該一のユーザについて、通知関連処理を実行する曜日（以下、「通知曜日」という）を示す情報である。詳細は後述するが、通知関連処理では、雨具提供店舗に関する情報の通知を行うか否かを判定され、行うと判定された場合に、当該情報の通知が行われる。従って、一の曜日に通知関連処理が行われない場合は、当該一の曜日には、雨具提供店舗に関する情報の通知が行われない。

通知曜日決定部１２の処理について詳述すると、ユーザの属性ごとに、ユーザが、雨具提供店舗に関する情報の通知を受けることを希望する曜日には傾向がある。例えば、会社員は、月曜日から金曜日に会社に出社する一方、土曜日および日曜日は会社に出社しないことが多いため、会社員は、月曜日から金曜日は、雨具提供店舗に関する情報の通知を受けることを希望するが、土曜日および日曜日は、当該情報の通知を受けることを希望しない傾向がある。以上を踏まえ、事前に、ユーザが選択可能な属性ごとに、雨具提供店舗に関する情報の通知を受けることを希望する曜日の傾向が調査され、調査結果に基づいて、ユーザが選択可能な属性ごとに、通知曜日が定められている。そして、ユーザが選択可能な属性ごとに、属性を示す情報と対応付けて、通知曜日を示す情報が登録されたテーブルが事前に記憶されている。本実施形態では、通知曜日は、属性：「会社員」は月〜金曜日であり、属性：「大学生」は月〜金曜日であり、属性：「主婦」は月〜日曜日である。

通知曜日決定部１２は、新たにレコードが登録された場合、当該レコードの属性情報を取得し、当該テーブルにおいて取得した属性情報が示す属性と対応付けられた通知曜日を示す情報を取得する。通知曜日決定部１２は、取得した通知曜日を示す情報に基づいて、当該レコードの通知曜日情報の値を更新する。

通知タイミング決定部１３は、ユーザ情報登録部１１によって、ユーザ情報データベース２０ａに新たにレコードが登録された場合に、新たに登録されたレコードの通知タイミング情報の値を更新する。一のユーザに係る通知タイミング情報は、当該一のユーザについて、通知曜日において通知関連処理を実行するタイミング（以下、「通知タイミング」という）を示す情報である。従って、通知関連処理において雨具提供店舗に関する情報を通知すると判定された場合、通知タイミングで当該情報の通知が行われることになる。なお、本実施形態では、通知タイミングは、「００：００」を始まりとする一日の中の、特定の時刻によって表される。

通知タイミング決定部１３の処理について詳述すると、ユーザの属性ごとに、ユーザが、雨具提供店舗に関する情報の通知を受けることを希望するタイミングには傾向がある。例えば、会社員は、１８：００位に業務が終了し、帰宅可能となることが多いため、会社員は、１８：００に近いタイミングで、雨具提供店舗に関する情報の通知を受けることを希望する傾向がある。また例えば、大学生は、１７：００位に、学校での授業を終えることが多いため、大学生は、１７：００に近いタイミングで、雨具提供店舗に関する情報の通知を受けることを希望する傾向がある。以上を踏まえ、事前に、ユーザが選択可能な属性ごとに、雨具提供店舗に関する情報の通知を受けることを希望するタイミングの傾向が調査され、調査結果に基づいて、ユーザが選択可能な属性ごとに、通知タイミングが定められている。そして、ユーザが選択可能な属性ごとに、属性を示す情報と対応付けて、通知タイミングを示す情報が登録されたテーブルが事前に記憶されている。本実施形態では、属性：「会社員」の通知タイミングは「１８：００」であり、属性：「大学生」の通知タイミングは「１７：００」であり、属性：「主婦」の通知タイミングは「１１：００」である。

通知タイミング決定部１３は、新たにレコードが登録された場合、当該レコードの属性情報を取得し、当該テーブルにおいて取得した属性情報が示す属性と対応付けられた通知タイミングを示す情報を取得する。通知タイミング決定部１３は、取得した通知タイミングを示す情報に基づいて、当該レコードの通知タイミング情報の値を更新する。

天気取得タイミング決定部１４は、ユーザ情報登録部１１によって、ユーザ情報データベース２０ａに新たにレコードが登録された場合に、新たに登録されたレコードの天気取得タイミング情報の値を更新する。一のユーザに係る天気取得タイミング情報は、当該一のユーザについて、通知曜日において、後述する天気推移取得部１６が、通知タイミングにおける対象地域の予報天気を取得するタイミング（以下、「天気取得タイミング」という）を示す情報である。本実施形態では、天気取得タイミングは、以下のようなタイミングとされる。

天気取得タイミングは、通知タイミングよりも前の複数のタイミングとされる。本実施形態では、天気取得タイミングは、初回タイミングと、中間タイミングと、最終タイミングとの３つのタイミングを含む。最終タイミングは、通知タイミングよりも前のタイミングであって、通知タイミングにできるだけ近いタイミングとされる。なお、最終タイミングは、通知タイミングと略同一のタイミングであってもよい。また、中間タイミングは、最終タイミングから、所定時間、遡ったタイミングとされ、初回タイミングは、中間タイミングから、所定時間、遡ったタイミングとされる。例えば、通知タイミングが「１８：００」の場合において、初回タイミングは「１０：００」とされ、中間タイミングは「１３：００」とされ、最終タイミングは「１７：００」とされる。

天気取得タイミング決定部１４の処理について詳述すると、ユーザが選択可能な属性ごとに、属性を示す情報と対応付けて、天気取得タイミングを示す情報（初回タイミング、中間タイミングおよび最終タイミングのそれぞれを示す情報）が登録されたテーブルが事前に記憶されている。天気取得タイミング決定部１４は、ユーザ情報データベース２０ａに新たにレコードが登録された場合、当該レコードの属性情報を取得し、当該テーブルにおいて取得した属性情報が示す属性と対応付けられた天気取得タイミングを示す情報を取得する。天気取得タイミング決定部１４は、取得した天気取得タイミングを示す情報に基づいて、当該レコードの天気取得タイミング情報の値を更新する。

店舗情報記憶部２１は、店舗情報データベース２１ａを記憶する。店舗情報データベース２１ａの内容については後述する。

店舗情報登録部１５は、雨具提供店舗の登録を行う。以下、店舗情報登録部１５の処理について詳述する。

ここで、情報配信サーバ２によって、雨具提供店舗に関する情報の配信に関するサービスを提供する会社（以下、「運営会社」という）は、所定のウェブサイトを開設している。当該所定のウェブサイトでは、当該サービスが紹介されるほか、当該サービスを利用することを希望する雨具提供店舗の担当者が、雨具提供店舗の登録を行うために必要な情報を入力するためのウェブページが提供されている。当該ウェブページには、店名情報、店舗住所情報、提供条件情報、返却必要有無情報およびホームページアドレス情報を入力する入力欄が設けられている。店名情報は、雨具提供店舗の店名を示す情報である。店舗住所情報は、雨具提供店舗の住所を示す情報である。提供条件情報とは、雨具提供店舗により傘が提供されるための条件である。例えば、条件としては、「店舗を利用すること」、「○円以上の支払いがあること」等がある。返却必要有無情報とは、ユーザに傘を提供した場合に、傘の返却が必要か否かを示す情報である。ホームページアドレス情報とは、雨具提供店舗を紹介するホームページがある場合に、そのホームページのアドレスを示す情報である。このようなホームページが無い場合は、ホームページアドレス情報は、ヌル値である。雨具提供店舗の担当者は、当該ウェブページに各情報（以下、「店舗情報」という）を入力し、入力を確定する。入力が確定すると、ウェブページのスクリプトの機能により、店舗情報が情報配信サーバ２に送信される。

店舗情報登録部１５は、店舗情報を受信し、店舗情報記憶部２１が記憶する店舗情報データベース２１ａに１件のレコードを登録する。詳述すると、店舗情報登録部１５は、一の店舗情報の受信に応じて、固有の店舗ＩＤを生成する。そして、生成した店舗ＩＤと、当該一の店舗情報とを含むレコードを、店舗情報データベース２１ａに新たに登録する。図４（Ｂ）は、店舗情報データベース２１ａが有する１件のレコードの内容を示す図である。店舗情報登録部１５が店舗情報データベース２１ａにレコードを登録することが、雨具提供店舗の登録に相当する。なお、雨具提供店舗の担当者は、所定の手段で、登録されたレコードの内容の変更、レコードの削除を行うことができる。

天気推移情報記憶部２２は、天気推移情報データベース２２ａを記憶する。天気推移情報データベース２２ａは、登録が行われたユーザごとにレコードを有するデータベースである。図４（Ｃ）は、天気推移情報データベース２２ａが有する１件のレコードの内容を示す図である。図４（Ｃ）に示すように、天気推移情報データベース２２ａのレコードは、ユーザＩＤと、初回天気情報と、中間天気情報と、最終天気情報とを有する。初回天気情報、中間天気情報および最終天気情報については後述する。

天気推移取得部１６は、ユーザごとに、「通知タイミングにおける対象地域の予報天気」を、天気取得タイミング（初回タイミング、中間タイミングおよび最終タイミングのそれぞれ）で取得する。以下、天気推移取得部１６の処理について詳述する。

まず、天気推移取得部１６は、毎日、「００：００」となった時点で、天気推移情報記憶部２２が記憶する天気推移情報データベース２２ａの各レコードの初回天気情報、中間天気情報および最終天気情報の値をヌル値とする。そして、天気推移取得部１６は、ユーザごとに、以下の処理を実行する。以下、一のユーザを処理対象として天気推移取得部１６が実行する処理について説明する。以下では、「００：００」を起点とする一日を「本日」という。また、以下の天気推移取得部１６の説明において、処理対象の一のユーザを「処理対象ユーザ」という。

天気推移取得部１６は、ユーザ情報記憶部２０が記憶するユーザ情報データベース２０ａのレコードのうち、処理対象ユーザに対応するレコードを参照し、通知曜日情報を取得する。次いで、天気推移取得部１６は、本日の曜日が、通知曜日情報が示す通知曜日であるか否かを判定する。本日の曜日が通知曜日ではない場合、天気推移取得部１６は、本日は、処理対象ユーザについて、以下で説明する初回天気情報、中間天気情報および最終天気情報の値の更新を行わない。

一方、本日の曜日が、通知曜日情報が示す通知曜日の場合、天気推移取得部１６は、ユーザ情報データベース２０ａに係る処理対象ユーザに対応するレコードを参照し、対象地域情報と、通知タイミング情報とを取得する。以下、取得した対象地域情報が示す対象地域を「特定対象地域」といい、取得した通知タイミング情報が示す通知タイミングを「特定通知タイミング」という。

、
次いで、天気推移取得部１６は、ユーザ情報データベース２０ａに係る処理対象ユーザに対応するレコードを参照し、天気取得タイミング情報を取得する。次いで、天気推移取得部１６は、天気取得タイミング情報が示す初回タイミングを認識し、初回タイミングが到来したか否かを監視する。初回タイミングが到来した場合、天気推移取得部１６は、天気情報公開サーバ４にアクセスし、特定通知タイミングにおける特定対象地域の予報天気を示す情報を取得する。例えば、初回タイミングが「１０：００」、特定通知タイミングが「１８：００」、特定対象地域が「Ｘ地域」の場合、天気推移取得部１６は、現在の時刻が「１０：００」となったときに、「Ｘ地域」の「１８：００」の予報天気として、天気情報公開サーバ４により公開された情報を取得する。なお、天気情報公開サーバ４から各種情報を取得するためのＷｅｂＡＰＩが公開されており、天気推移取得部１６は、ＷｅｂＡＰＩを利用して、当該情報を取得する。

天気推移取得部１６は、特定通知タイミングにおける特定対象地域の予報天気を示す情報を取得した後、取得した当該情報に基づいて、天気推移情報記憶部２２が記憶する天気推移情報データベース２２ａのレコードのうち、処理対象ユーザに対応するレコードの初回天気情報の値を更新する。

初回天気情報の値を更新した後、天気推移取得部１６は、取得した天気取得タイミング情報が示す中間タイミングを認識し、中間タイミングが到来したか否かを監視する。中間タイミングが到来した場合、天気推移取得部１６は、天気情報公開サーバ４にアクセスして特定通知タイミングにおける特定対象地域の予報天気を示す情報を取得し、取得した当該情報に基づいて、天気推移情報データベース２２ａに係る処理対象ユーザに対応するレコードの中間天気情報の値を更新する。中間天気情報の値を更新した後、天気推移取得部１６は、取得した天気取得タイミング情報が示す最終タイミングを認識し、最終タイミングが到来したか否かを監視する。最終タイミングが到来した場合、天気推移取得部１６は、天気情報公開サーバ４にアクセスして特定通知タイミングにおける特定対象地域の予報天気を示す情報を取得し、取得した当該情報に基づいて、天気推移情報データベース２２ａに係る処理対象ユーザに対応するレコードの最終天気情報の値を更新する。

天気推移取得部１６により以上の処理が行われる結果、各ユーザについて、本日の曜日が通知曜日の場合は、通知タイミングよりも前に、初回天気情報、中間天気情報および最終天気情報の値が、天気情報公開サーバ４により公開された予報天気に基づいて更新された状態となる。

不所持可能性情報記憶部２３は、不所持可能性情報データベース２３ａを記憶する。不所持可能性情報データベース２３ａは、登録が行われたユーザごとにレコードを有するデータベースである。図４（Ｄ）は、不所持可能性情報データベース２３ａが有する１件のレコードの内容を示す図である。図４（Ｄ）に示すように、天気推移情報データベース２２ａのレコードは、ユーザＩＤと、不所持可能性情報とを有する。不所持可能性情報については後述する。

不所持可能性判定部１７は、ユーザごとに、通知タイミングの時点でユーザが傘を所持していない可能性の高さ（以下、「不所持可能性」という）を判定する。以下、不所持可能性判定部１７の処理について詳述する。

不所持可能性判定部１７は、天気推移取得部１６により、一のユーザについての最終天気情報が更新されたときに、当該一のユーザを処理対象として、不所持可能性を判定し、不所持可能性情報を更新する。以下、一のユーザを処理対象として不所持可能性判定部１７が実行する処理について説明する。以下の不所持可能性判定部１７の説明において、処理対象の一のユーザを「処理対象ユーザ」という。

不所持可能性判定部１７は、天気推移取得部１６によって、処理対象ユーザに対応するレコードの最終天気情報が更新された場合、当該レコードの初回天気情報、中間天気情報および最終天気情報を取得する。次いで、不所持可能性判定部１７は、これら情報に基づいて、予報天気が、雨具を要しない天気から、雨具を要する天気へと推移している場合、不所持可能性が高いと判定し、それ以外の場合は、不所持可能性が低いと判定する。特に、本実施形態に係る不所持可能性判定部１７は、天気取得タイミングのうち最終タイミング（最後のタイミング）で予報天気が初めて雨具を要する天気となっている場合、ユーザが雨具を所持していない可能性が高いと判定し、それ以外の場合、ユーザが雨具を所持していない可能性が低いと判定する。

具体的には、本実施形態に係る不所持可能性判定部１７は、初回天気情報が示す予報天気が「晴」であり、中間天気情報が示す予報天気が「晴」であり、最終天気情報が示す予報天気が「雨」の場合、不所持可能性が高いと判定する一方、それ以外の場合、不所持可能性が低いと判定する。つまり、不所持可能性判定部１７は、通知タイミングにおける対象地域の予報天気が、「晴」→「晴」→「雨」と推移している場合は、不所持可能性が高いと判定する一方、それ以外の場合は、不所持可能性が低いと判定する。これは以下の理由による。

すなわち、通知タイミングにおける対象地域の予報天気が、「晴」→「晴」→「雨」と推移している場合は、対象地域において、通知タイミングの時点で雨が降っており、かつ、その雨が突然降りだした雨であるとみなすことができる。一方、上記の推移以外の推移の場合は、通知タイミングの時点で晴れているか、または、雨が降っている場合であっても、突然降り出した雨ではないものとみなすことができる。例えば、通知タイミングにおける対象地域の予報天気が、「雨」→「雨」→「雨」または「晴」→「雨」→「雨」と推移している場合は、通知タイミングより前の早い段階から継続して降り続く雨とみなすことができ、また、「雨」→「晴」→「雨」と推移している場合は、断続的に雨が降ったり晴れたりしている状態であるとみなすことができる。そして、突然の雨の場合は、他の場合と比較して、処理対象ユーザが傘を用意する余裕や機会が無く、処理対象ユーザが、通知タイミングの時点で傘を所持していない可能性が高い。以上を踏まえ、不所持可能性判定部１７は、通知タイミングにおける対象地域の予報天気が、「晴」→「晴」→「雨」と推移している場合は、不所持可能性が高いと判定する一方、それ以外の場合は、不所持可能性が低いと判定する。

不所持可能性判定部１７は、処理対象ユーザについての不所持可能性を判定した後、不所持可能性情報記憶部２３が記憶する不所持可能性情報データベース２３ａのレコードのうち、処理対象ユーザに対応するレコードの不所持可能性情報の値を更新する。不所持可能性情報は、値として、可能性が高いことを示す値と、可能性が低いことを示す値とのいずれかの値をとる。不所持可能性判定部１７は、不所持可能性が高いと判定した場合は、不所持可能性情報の値を可能性が高いことを示す値へと更新し、不所持可能性が低いと判定した場合は、不所持可能性情報の値を可能性が低いことを示す値へと更新する。

不所持可能性判定部１７により以上の処理が行われる結果、各ユーザについて、本日の曜日が通知曜日の場合は、通知タイミングよりも前に、不所持可能性情報の値が更新された状態となる。

情報通知部１８は、ユーザごとに、以下の処理を実行する。以下、一のユーザを処理対象として情報通知部１８が実行する処理について説明する。以下の情報通知部１８の説明において、処理対象の一のユーザを「処理対象ユーザ」という。

情報通知部１８は、「００：００」となったときに、ユーザ情報記憶部２０が記憶するユーザ情報データベース２０ａのレコードのうち、処理対象ユーザに対応するレコードを参照し、通知曜日情報を取得する。次いで、情報通知部１８は、本日の曜日が、通知曜日情報が示す通知曜日であるか否かを判定する。本日の曜日が通知曜日ではない場合、情報通知部１８は、本日は、処理対象ユーザについて、通知関連処理を実行しない。この結果、本日は、処理対象ユーザには、雨具提供店舗に関する情報の通知が行われない。

一方、本日の曜日が、通知曜日情報が示す通知曜日の場合、情報通知部１８は、ユーザ情報データベース２０ａに係る処理対象ユーザに対応するレコードを参照して通知タイミング情報を取得し、通知タイミング情報が示す通知タイミングを認識する。次いで、情報通知部１８は、通知タイミングが到来したか否かを監視する。通知タイミングが到来した場合、情報通知部１８は、通知関連処理を実行する。

通知関連処理において、まず、情報通知部１８は、天気推移情報記憶部２２が記憶する天気推移情報データベース２２ａのレコードのうち、処理対象ユーザに対応するレコードを参照し、最終天気情報を取得する。次いで、情報通知部１８は、最終天気情報が示す予報天気が「雨」か否かを判定する。「雨」ではない場合、情報通知部１８は、雨具提供店舗に関する情報を通知しないと決定する。上述したように、最終天気情報が示す予報天気は、通知タイミングに近い最終タイミングで公開された、通知タイミングにおける対象地域の予報天気である。従って、最終天気情報が示す予報天気は、通知タイミングにおける対象地域の実際の天気とみなすことができる。そして、対象地域の実際の天気が「雨」ではない場合は、雨具提供店舗に関する情報をユーザに通知する必要がないため、この場合は、当該情報の通知が行われない。

一方、最終天気情報が示す予報天気が「雨」の場合、通知タイミングにおける対象地域の実際の天気が「雨」であるとみなすことができる。情報通知部１８は、最終天気情報が示す予報天気が「雨」の場合、ユーザ情報データベース２０ａに係る処理対象ユーザに対応するレコードを参照して通知方法情報を取得し、通知方法を認識する。さらに、情報通知部１８は、不所持可能性情報記憶部２３が記憶する不所持可能性情報データベース２３ａのレコードのうち、処理対象ユーザに対応するレコードを参照して不所持可能性情報を取得し、不所持可能性を認識する。

そして、情報通知部１８は、ユーザが指定した通知方法により、不所持可能性が高い場合と低い場合とで異なる内容の情報を通知する。なお、プッシュ通知について、情報通知部１８は、処理対象ユーザのプッシュ通知関連情報に基づいて、所定のサーバに対して必要な情報を送信して、適切にプッシュ通知を行う。また、メール配信について、情報通知部１８は、処理対象ユーザのメールアドレスに基づいて、メールシステムを利用して、適切にメール配信を行う。

図５（Ａ）は、プッシュ通知により情報を通知する場合であって、不所持可能性が高い場合に、ロック画面に表示されるメッセージの一例を示す図である。また、図５（Ｂ）は、プッシュ通知により情報を通知する場合であって、不所持可能性が低い場合に、ロック画面に表示されるメッセージの一例を示す図である。図５（Ａ）のメッセージでは、ユーザに対して、突然の雨が降り出したことが明示されると共に、傘を忘れていないどうかが問いかけられ、傘を提供する店舗が近くにあることが紹介される。一方、図５（Ｂ）のメッセージでは、現時点で雨が降っていることが明示されると共に、傘を提供する店舗が近くにあることが紹介される。

図５（Ａ）のメッセージと、図５（Ｂ）のメッセージとの比較で明らかなとおり、不所持可能性が高い場合、メッセージとして、雨具提供店舗への来店をより強く促す内容の情報が通知される。これにより以下の効果を奏する。すなわち、
不所持可能性が高い場合、つまり、通知タイミングの時点で処理対象ユーザが傘を所持していない可能性が高い場合、処理対象ユーザが、傘の提供を希望している可能性が高い。この場合、雨具提供店舗への来店をより強く促す内容の情報を通知することにより、ユーザの心情により合致した内容のメッセージをユーザに伝えることが可能となる。また、不所持可能性が低い場合、つまり、通知タイミングの時点で処理対象ユーザが傘を所持していない可能性が低い場合、処理対象ユーザが、傘の提供を希望していない可能性が高い。この場合、雨具提供店舗への来店をより強く促す内容の情報ではなく、現状を認識させるだけの穏やかな内容の情報を通知することにより、ユーザの心情により合致した内容のメッセージをユーザに伝えることが可能となる。すなわち、上記構成によれば、ユーザの傘の提供に対するニーズに応じた態様で、雨具を提供する店舗に関する情報をユーザに通知することができる。

図６（Ａ）は、図５（Ａ）または図５（Ｂ）のプッシュ通知に応じて、ユーザが専用アプリケーションを起動した場合に、ユーザ端末３のタッチパネル３ａに表示される画面の一例を示す図である。図６（Ａ）に示すように、プッシュ通知に応じて専用アプリケーションが起動すると、専用アプリケーションの機能により、ユーザ端末３の位置（＝処理対象ユーザの位置）を中心とした所定スケールの地図が表示される。地図には、雨具提供店舗の位置を示す店舗マークＭ６Ａが表示される。処理対象ユーザは、図６（Ａ）で例示した画面を参照することにより、自身の位置を中心として、どの辺りに雨具提供店舗が存在しているのかを的確に認識できる。

なお、地図の表示は、専用アプリケーションが、ＷｅｂＡＰＩを用いて、地図に関する情報を提供する所定のサーバから地図の表示に必要なデータを取得することによって行われる。また、店舗マークＭ６Ａの表示は、専用アプリケーションと情報通知部１８との協働により行われる。簡単に説明すると、専用アプリケーションは、ユーザ端末３のＯＳの機能を利用して、ユーザ端末３の位置を示す情報を取得し、情報通知部１８に送信する。情報通知部１８は、店舗情報記憶部２１が記憶する店舗情報データベース２１ａの各レコードの店舗住所情報に基づいて、ユーザ端末３の位置を中心として所定の範囲内に存在する雨具提供店舗を特定する。なお、情報通知部１８は、住所を地図上の位置に変換する機能を有する。情報通知部１８は、特定した雨具提供店舗のそれぞれについて、雨具提供店舗の地図上の位置を示す情報を店舗ＩＤと対応付けて専用アプリケーションに送信する。専用アプリケーションは、雨具提供店舗の地図上の位置を示す情報に基づいて、店舗マークＭ６Ａを地図上に表示する。

図６（Ｂ）は、図６（Ａ）の画面に表示された店舗マークＭ６Ａの１つが処理対象ユーザによりタッチ操作された場合に表示される画面の一例を示す図である。図６（Ｂ）に示すように、店舗マークＭ６Ａがタッチ操作されると、地図上に、雨具提供店舗を紹介する店舗紹介情報Ｊ６Ｂがポップアップにより表示される。図６（Ｂ）に示すように、紹介情報Ｊ６Ｂは、店名情報、店舗住所情報、提供条件情報、返却必要有無情報、および、ＨＰアドレス情報を含む。処理対象ユーザは、図６（Ｂ）で例示した画面を参照することにより、雨具提供店舗の詳細な情報を確認することができ、その雨具提供店舗を利用するか否かを的確に判断できる。

なお、紹介情報Ｊ６Ｂの表示は、専用アプリケーションと情報通知部１８との協働により行われる。簡単に説明すると、専用アプリケーションは、店舗マークＭ６Ａがタッチ操作された場合、店舗マークＭ６Ａの店舗ＩＤを情報通知部１８に送信する。情報通知部１８は、店舗情報データベース２１ａのレコードのうち、店舗ＩＤに対応するレコードを特定し、店舗情報（紹介情報Ｊ６Ｂに含まれる情報を含む情報）を取得し、専用アプリケーションに送信する。専用アプリケーションは、店舗情報を受信し、受信した店舗情報に基づいて紹介情報Ｊ６Ｂを表示する。

なお、図５、図６を用いて、情報通知部１８がプッシュ通知により通知する情報の内容を例を挙げて説明した。一方、情報通知部１８がメール配信により雨具提供店舗に関する情報の通知を行う場合、例えば、以下の内容の情報が通知される。すなわち、メール本文の冒頭に、不所持可能性が高い場合は、図５（Ａ）で例示したメッセージと同様の内容のメッセージが記述される一方、不所持可能性が低い場合は、図５（Ｂ）で例示したメッセージと同様の内容のメッセージが記述される。また、メール本文には、専用アプリケーションを起動することによって、雨具提供店舗の位置や、雨具提供店舗の詳細を確認できる旨の文章が記述される。

ここで、雨具提供店舗に関するプッシュ通知や、メール配信は、通知タイミングで行われる。上述したように、通知タイミングは、ユーザの属性に応じて適切に定められたものである。このため、ユーザの属性に鑑みて、ユーザにとって傘の提供が必要な状況が発生し得る適切なタイミングで、雨具提供店舗に関するプッシュ通知や、メール配信が行われることになり、ユーザの満足度を向上できる。

図７は、本実施形態に係る情報配信サーバ２の処理の一例を示すフローチャートである。図７のフローチャートは、一のユーザについて、情報配信サーバ２が実行する処理の一例を示している。以下の図７のフローチャートを用いた説明では、処理対象の一のユーザを「処理対象ユーザ」という。

図７に示すように、情報配信サーバ２の天気推移取得部１６は、天気の推移を取得する処理を実行する（ステップＳＡ１）。図８（Ａ）は、ステップＳＡ１の処理の詳細を示すフローチャートである。図８（Ａ）のフローチャートで示すように、処理対象ユーザに係る通知曜日情報に基づいて、本日の曜日が通知曜日であるか否かを判定する（ステップＳＢ１）。本日の曜日が通知曜日では無い場合ステップＳＢ１：ＮＯ）、天気推移取得部１６は、処理を終了する。この場合、初回天気情報、中間天気情報および最終天気情報の値の更新、および、図７のフローチャートのステップＳＡ２の処理は行われない。

本日の曜日が通知曜日の場合（ステップＳＢ１：ＹＥＳ）、天気推移取得部１６は、処理対象ユーザに係る対象地域情報、通知タイミング情報および天気取得タイミング情報を取得する（ステップＳＢ２）。次いで、天気推移取得部１６は、ステップＳＢ２で取得した天気取得タイミング情報に基づいて、初回タイミングが到来したか否かを監視する（ステップＳＢ３）。初回タイミングが到来した場合（ステップＳＢ３：ＹＥＳ）、天気推移取得部１６は、天気情報公開サーバ４にアクセスし、処理対象ユーザに係る通知タイミングにおける、処理対象ユーザに係る対象地域の予報天気を示す情報を取得し、初回天気情報の値を更新する（ステップＳＢ４）。

次いで、天気推移取得部１６は、ステップＳＢ２で取得した天気取得タイミング情報に基づいて、中間タイミングが到来したか否かを監視する（ステップＳＢ５）。中間タイミングが到来した場合（ステップＳＢ５：ＹＥＳ）、天気推移取得部１６は、天気情報公開サーバ４にアクセスし、処理対象ユーザに係る通知タイミングにおける、処理対象ユーザに係る対象地域の予報天気を示す情報を取得し、中間天気情報の値を更新する（ステップＳＢ６）。次いで、天気推移取得部１６は、ステップＳＢ２で取得した天気取得タイミング情報に基づいて、最終タイミングが到来したか否かを監視する（ステップＳＢ７）。最終タイミングが到来した場合（ステップＳＢ７：ＹＥＳ）、天気推移取得部１６は、天気情報公開サーバ４にアクセスし、処理対象ユーザに係る通知タイミングにおける、処理対象ユーザに係る対象地域の予報天気を示す情報を取得し、最終天気情報の値を更新する（ステップＳＢ８）。

図７のフローチャートに示すように、天気推移取得部１６によって最終天気情報が更新されたことをトリガーとして、不所持可能性判定部１７は、不所持可能性を判定する（ステップＳＡ２）。図８（Ｂ）のフローチャートは、ステップＳＡ２の処理の詳細を示すフローチャートである。図８（Ｂ）のフローチャートに示すように、不所持可能性判定部１７は、処理対象ユーザに係る初回天気情報、中間天気情報および最終天気情報を取得する（ステップＳＣ１）。次いで、不所持可能性判定部１７は、ステップＳＣ１で取得した情報に基づいて、処理対象ユーザについて、通知タイミングにおける対象地域の予報天気が、「晴」→「晴」→「雨」と推移しているか否かを判定する（ステップＳＣ２）。

上記推移の場合（ステップＳＣ２：ＹＥＳ）、不所持可能性判定部１７は、不所持可能性が高いと判定する（ステップＳＣ３）。一方、上記推移ではない場合（ステップＳＣ２：ＮＯ）、不所持可能性判定部１７は、不所持可能性が低いと判定する（ステップＳＣ４）。ステップＳＣ３またはステップＳＣ４の処理を実行した後、不所持可能性判定部１７は、判定結果に基づいて、処理対象ユーザに係る不所持可能性情報の値を更新する（ステップＳＣ５）。

図７のフローチャートに示すように、ステップＳＡ２の処理に応じて、情報通知部１８は、雨具提供店舗に関する情報の通知に関する処理を実行する（ステップＳＡ３）。図８（Ｃ）のフローチャートは、ステップＳＡ３の処理の詳細を示すフローチャートである。図８（Ｃ）のフローチャートに示すように、処理対象ユーザに係る通知曜日情報を取得し、本日の曜日が、通知曜日情報が示す通知曜日であるか否かを判定する（ステップＳＤ１）。本日の曜日が通知曜日ではない場合（ステップＳＤ１：ＮＯ）、情報通知部１８は、処理対象ユーザについて、ステップＳＤ２以下の処理を実行しない。この結果、本日は、処理対象ユーザには、雨具提供店舗に関する情報の通知が行われない。

本日の曜日が通知曜日の場合、通知タイミング情報を取得し、通知タイミングが到来したか否かを監視する（ステップＳＤ２）。通知タイミングが到来した場合（ステップＳＤ２：ＹＥＳ）、情報通知部１８は、処理対象ユーザに係る最終天気情報を取得し、最終天気情報が示す予報天気が「雨」か否かを判定する（ステップＳＤ３）。「雨」ではない場合（ステップＳＤ３：ＮＯ）、情報通知部１８は、雨具提供店舗に関する情報を通知せず、処理を終了する。「雨」の場合（ステップＳＤ３：ＹＥＳ）、情報通知部１８は、処理対象ユーザに係る通知方法情報を取得し、通知方法を認識する（ステップＳＤ４）。さらに、情報通知部１８は、情報通知部１８は、処理対象ユーザに係る不所持可能性情報を取得し、不所持可能性を認識する（ステップＳＤ５）。

次いで、情報通知部１８は、ステップＳＤ４で認識した通知方法により、雨具提供店舗に関する情報を通知する（ステップＳＤ６）。上述したように、情報通知部１８は、ステップＳＤ５で認識した不所持可能性に基づいて、不所持可能性が高い場合、雨具提供店舗への来店をより強く促す内容の情報を通知する。このことの効果は上述したとおりである。

以上詳しく説明したように、本実施形態に係る情報配信システム１において、情報配信サーバ２は、対象地域の天気の推移（予報天気の推移）を取得し、天気の推移に基づいて、ユーザが雨具を所持していない可能性の高さを判定し、ユーザが雨具を所持していない可能性の高さに応じた態様で、雨具提供店舗に関する情報の通知に関する処理を実行する。この構成によれば、天気の推移に基づいて、ユーザが雨具を備えていない可能性の高さが適切に判定された上で、当該可能性の高さに応じた態様で、雨具提供店舗に関する情報の通知に関する処理が実行される。このため、ユーザが雨具を備えていない可能性の高さ、つまりユーザの傘に対するニーズを考慮した適切な態様で、報知情報の通知に関する処理を行うことが可能となる。

＜第１実施形態の第１変形例＞
次に、第１実施形態の変形例について説明する。上述した第１実施形態では、不所持可能性判定部１７は、通知タイミングにおける対象地域の予報天気が「晴」→「晴」→「雨」と推移している場合は、不所持可能性が高いと判定する一方、それ以外の場合は、不所持可能性が低いと判定した。この点に関し、本変形例に係る情報配信サーバ２は、以下の処理を実行する。以下、一のユーザを処理対象として本変形例に係る情報配信サーバ２が実行する処理について説明する。以下の本変形例の説明では、処理対象の一のユーザを「処理対象ユーザ」という。

天気推移取得部１６は、処理対象ユーザに係る天気取得タイミングの各タイミングで、通知タイミングにおける対象地域の予報天気を取得するほか、さらに、各タイミングで、各タイミングにおける対象地域の実際の天気を取得する。例えば、通知タイミングが「１８：００」、初回タイミングが「１０：００」、中間タイミングが「１３：００」、最終タイミングが「１７：００」であり、対象地域が「Ｘ地域」であるとする。この場合、天気推移取得部１６は、予報天気のほかに、「１０：００」におけるＸ地域の実際の天気、「１３：００」におけるＸ地域の実際の天気、および、「１７：００」におけるＸ地域の実際の天気を取得する。天気推移取得部１６は、各タイミングの実際の天気を示す情報を、ユーザＩＤと対応付けて記憶する。

そして、不所持可能性判定部１７は、処理対象ユーザについての不所持可能性の判定に際し、予報天気の推移が「晴」→「晴」→「雨」ではない場合であっても、実際の天気の推移が「晴」→「晴」→「雨」の場合は、不所持可能性が高いと判定する。これは、以下の理由による。すなわち、実際の天気の推移が「晴」→「晴」→「雨」の場合は、突然の雨が実際に降ったということであり、この場合も、処理対象ユーザが傘を所持していない可能性が高いからである。本変形例の構成によれば、実際の天気の推移を踏まえ、より的確に不所持可能性を判定できる。

＜第１実施形態の第２変形例＞
次に、第１実施形態の第２変形例について説明する。上述した第１実施形態では、不所持可能性判定部１７は、通知タイミングにおける対象地域の予報天気が「晴」→「晴」→「雨」と推移している場合は、不所持可能性が高いと判定した。この点に関し、「晴」→「雨」→「雨」と推移している場合も、不所持可能性が高いと判定する構成でもよい。つまり、不所持可能性判定部１７が、雨具を要しない天気から、雨具を要する天気へと推移している場合、不所為可能性が高いと判定する構成でもよい。雨具を要しない天気から、雨具を要する天気へと推移している場合、天気の変化が突然ではないとしても、このような推移をしていない場合と比較して、ユーザが傘を用意する余裕や機会が無く、ユーザが、通知タイミングの時点で傘を所持していない可能性が高いからである。本変形例は、他の変形例に適用できることは勿論である。

＜第１実施形態の第３変形例＞
上述した第１実施形態では、天気推移取得部１６は、ユーザごとに、「通知タイミングにおける対象地域の予報天気」を、天気取得タイミング（初回タイミング、中間タイミングおよび最終タイミングのそれぞれ）で取得した。一方、本変形例に係る天気推移取得部１６は、天気取得タイミングの各タイミングにおいて、ユーザが実際に存在する位置が属する地域の実際の天気を取得する。以下、一のユーザを処理対象として、本変形例に係る天気推移取得部１６が実行する処理について説明する。以下の天気推移取得部１６の説明において、処理対象の一のユーザを「処理対象ユーザ」という。

ユーザ端末３は、本日が通知曜日の場合、専用アプリケーションの機能により、天気取得タイミングの各タイミングに至ったときに、ユーザＩＤと対応付けて、ユーザ端末３の位置を示す情報を、情報配信サーバ２に送信する。情報配信サーバ２の天気推移取得部１６は、天気取得タイミングの各タイミングで、ユーザ端末３の位置を示す情報を受信し、ユーザ端末３の位置が属する地域を特定する。ここで特定された地域は、天気取得タイミングの各タイミングの時点で、ユーザが実際に存在している地域である。天気推移取得部１６は、天気取得タイミングの各タイミングで、天気情報公開サーバ４にアクセスし、各タイミングにおける特定した地域の実際の天気を示す情報を取得する。天気推移取得部１６は、取得した情報に基づいて、天気推移情報データベース２２ａの処理対象ユーザに対応するレコードの初回天気情報、中間天気情報、最終天気情報を更新する。

天気推移取得部１６により以上の処理が行われる結果、各ユーザについて、初回天気情報は、初回タイミングのときにユーザがいた地域の実際の天気を示す情報となり、中間天気情報は、中間タイミングのときにユーザがいた地域の実際の天気を示す情報となり、最終天気情報は、最終タイミングのときにユーザがいた地域の実際の天気を示す情報となる。本変形例では、不所持可能性判定部１７は、ユーザが実際にいた位置における実際の天気の推移に基づいて、不所持可能性を判定する。このため、不所持可能性判定部１７は、通知タイミングにおいてユーザが実際にいる位置で雨が実際に降っている場合に、その雨がユーザにとって突然の雨であるのかを反映して的確に不所持可能性を判定できる。なお、情報通知部１８は、第１実施形態で説明した方法で、不所持可能性に応じた態様で、通知関連処理を実行する。

なお、本変形例では、天気推移取得部１６は、天気取得タイミングの各タイミングにおいて、ユーザが実際に存在する位置が属する地域の実際の天気を取得した。この点に関し、天気推移取得部１６が、天気取得タイミングの各タイミングにおいて、「対象地域」の実際の天気を取得し、各タイミングにおける対象地域の実際の天気に基づいて、初回天気情報、中間天気情報または最終天気情報を更新する構成でもよい。この構成によれば、不所持可能性判定部１７は、対象地域における実際の天気の推移に基づいて、不所持可能性を判定するため、通知タイミングにおいて雨が実際に降っている場合に、その雨が対象地域において突然降り出した雨であるのかを反映して的確に不所持可能性を判定できる。

＜第１実施形態の第４変形例＞
次に、第１実施形態の第４変形例について説明する。本変形例に係る情報配信サーバ２は、第１タイミングで自宅地域の実際の天気を取得し、第２タイミングで対象地域の実際の天気を取得する。そして、情報配信サーバ２は、第１タイミングにおける自宅地域の実際の天気および第２タイミングにおける対象地域の実際の天気の推移に基づいて不所持可能性を判定する。自宅地域とは、ユーザの自宅の位置が属する地域である。第１タイミングとは、ユーザが、対象施設に行く目的をもって自宅から出る大体の時刻のことである。第２タイミングとは、ユーザが、対象施設を退出する大体の時刻のことである。

詳述すると、ユーザ情報登録部１１は、例えば、図９に示すユーザ情報入力画面ＵＩ９をユーザ端末に表示させ、当該画面に対する入力に基づいて、自宅地域、対象地域、第１タイミングおよび第２タイミングを取得する。なお、本変形例では、通知曜日についてもユーザが指定する。

本変形例では、天気推移情報データベース２２ａの１件のレコードは、ユーザＩＤと、第１実際天気情報と、第２実際天気情報とを有する。これら情報については後述する。

天気推移取得部１６は、ユーザごとに、本日の曜日が通知曜日の場合は、第１タイミングで自宅地域の実際の天気を取得すると共に、第２タイミングで対象地域の実際の天気を取得し、第１実際天気情報および第２実際天気情報の値を更新する。つまり、第１実際天気情報は、自宅出発時刻における自宅地域の実際の天気を示す情報であり、第２実際天気情報は、施設退出時刻における対象地域の実際の天気を示す情報である。

不所持可能性判定部１７は、以下の処理を実行する。以下、一のユーザを処理対象として不所持可能性判定部１７が実行する処理について説明する。以下の不所持可能性判定部１７の説明において、処理対象の一のユーザを「処理対象ユーザ」という。不所持可能性判定部１７は、天気推移取得部１６によって、処理対象ユーザに対応するレコードの第２実際天気情報が更新された場合、当該レコードの第１実際天気情報および第２実際天気情報を取得する。次いで、不所持可能性判定部１７は、これら情報に基づいて、天気が、雨具を要しない天気から、雨具を要する天気へと推移している場合、不所持可能性が高いと判定し、それ以外の場合は、不所持可能性が低いと判定する。

具体的には、本実施形態に係る不所持可能性判定部１７は、第１実際天気情報が示す天気が「晴」であり、第２実際天気情報が示す天気が「雨」の場合、不所持可能性が高いと判定する一方、それ以外の場合、不所持可能性が低いと判定する。これは、以下の理由による。すなわち、第１実際天気情報が示す天気が「晴」であり、第２実際天気情報が示す天気が「雨」の場合、以下の状況であるものと想定される。すなわち、処理対象ユーザが自宅を出るときは天気が「晴」であり、処理対象ユーザが対象施設（会社員にとっての会社や、大学生にとっての学校）を出るときは天気が「雨」という状況であることが想定される。この場合、処理対象ユーザが自宅を出るときは天気が「晴」であったため、その時点で、処理対象ユーザにとって傘が必要なく、従って、処理対象ユーザが自宅を出て対象施設に向かうときに傘を持参していない可能性が他の場合と比較して高い。一方、上記以外の場合は、第２タイミングの時点で晴れているか、または、第２タイミングの時点で雨が降っている場合であっても、処理対象ユーザが自宅を出るときにも雨が降っており、処理対象ユーザが自宅を出て対象施設に向かうときに傘を持参している可能性が高い。以上を踏まえ、不所持可能性判定部１７は、第１実際天気情報が示す天気が「晴」であり、第２実際天気情報が示す天気が「雨」の場合、不所持可能性が高いと判定する一方、それ以外の場合、不所持可能性が低いと判定する。

不所持可能性判定部１７は、処理対象ユーザについての不所持可能性を判定した後、不所持可能性情報記憶部２３が記憶する不所持可能性情報データベース２３ａのレコードのうち、処理対象ユーザに対応するレコードの不所持可能性情報の値を更新する。不所持可能性判定部１７により以上の処理が行われる結果、各ユーザについて、本日の曜日が通知曜日の場合は、通知タイミングよりも前に、不所持可能性情報の値が更新された状態となる。

なお、情報通知部１８は、第１実施形態で説明した方法で、不所持可能性に応じた態様で、通知関連処理を実行する。

本変形例であっても、第１実施形態と同様、天気の推移に基づいてユーザが雨具を備えていない可能性の高さが適切に判定された上で、当該可能性の高さに応じた態様で、通知関連処理が実行される。これにより、ユーザの傘の提供に対するニーズを考慮した適切な態様で、通知関連処理を行うことが可能となる。特に、本変形例によれば、ユーザが自宅を出るときに、天気が「晴」の場合、ユーザにとって傘が必要なく、雨が降っている場合と比較して、ユーザが傘を持参していない可能性が高いことを踏まえて、適切に、不所持可能性を判定できる。

なお、本変形例において、不所持可能性判定部１７は、第１実際天気情報が示す天気が「晴」であり、第２実際天気情報が示す天気が「雨」の場合、不所持可能性が高いと判定する一方、それ以外の場合、不所持可能性が低いと判定した。この点に関し、情報配信サーバ２が、以下の処理を実行してもよい。すなわち、天気推移取得部１６は、第１タイミングで、自宅地域の実際の天気を取得するほか、さらに、この第１タイミングで、第２タイミングにおける対象地域の予報天気を取得する。例えば、第１タイミングが「１０：００」、第２タイミングが「１８：００」であり、対象地域が「Ｘ地域」であるとする。この場合、天気推移取得部１６は、第１タイミングの「１０：００」で、「１８：００」におけるＸ地域の予報天気を取得する。天気推移取得部１６は、取得した予報天気を示す情報を、ユーザＩＤと対応付けて記憶する。

そして、不所持可能性判定部１７は、処理対象ユーザについての不所持可能性の判定に際し、第１実際天気情報が示す天気が「晴」であり、第２実際天気情報が示す天気が「雨」の場合であっても、第１タイミングで取得した、第２タイミング（＝通知タイミング）における対象地域の予報天気が「雨」の場合は、不所持可能性が低いと判定する。これは、以下の理由による。すなわち、ユーザは、自宅を出るときに、テレビ、インターネット、ラジオ等の手段で、天気予報を視聴等することが少なからずある。そして、上記の場合は、ユーザが自宅を出るときに行われた天気予報において、ユーザが今から行こうとしている対象施設が存在する対象地域について、施設退出時刻に雨が降っていると予報されていることになる。この場合、自宅をでるときに実際に晴れていたとしても、ユーザは傘を持参して対象施設に向かうことが想定される。以上が理由である。

また、本変形例では、天気推移取得部１６は、天気の推移として、第１タイミングで自宅地域の実際の天気を取得し、第２タイミングで対象地域の実際の天気を取得した。この点に関し、天気推移取得部１６が、第１タイミングで、自宅地域に代えて「対象地域」の実際の天気を取得する構成でもよい。この構成であっても、不所持可能性判定部１７により判定される不所持可能性の値は、第２実施形態で判定される不所持可能性の値と、ほとんどの場合、変わらないものと考えられる。これは以下の理由による。すなわち、対象施設は、ユーザが定期的にまたは頻繁に通うような施設であり、ユーザの自宅と対象施設とは同時間帯における天気が極端に異なるほどには離間していないものと想定されるからである。

また、本変形例では、天気推移取得部１６は、第１タイミングで、ユーザが入力した自宅地域の実際の天気を取得し、第２タイミングで、ユーザが入力した対象地域の実際の天気を取得した。この点に関し、天気推移取得部１６が、第１タイミングで、ユーザの位置が属する地域の実際の天気を取得し、第２タイミングで、ユーザの位置が属する地域の実際の天気を取得する構成でもよい。本変形例の構成によれば、不所持可能性判定部１７は、ユーザが実際に存在していた地域の天気の推移に基づいて、不所持可能性を判定することになり、より的確に不所持可能性を判定できる。

＜第２実施形態＞
次に、第２実施形態について説明する。本実施形態では、ユーザ端末３Ｂ（特許請求の範囲の「情報提供装置」に相当）が、不所持可能性の判定を行って、雨具提供店舗に関する情報をプッシュ通知により提供する。図１０は、本実施形態に係るユーザ端末３Ｂの機能構成例を示すブロック図である。図１０に示すように、ユーザ端末３Ｂは、機能構成として、通信部３０、ユーザ情報登録部３１、通知曜日決定部３２、通知タイミング決定部３３、天気取得タイミング決定部３４、天気推移取得部３５、不所持可能性判定部３６、情報提供部３７を備えている。本実施形態では、これら機能ブロックの機能は、専用アプリケーションおよび専用アプリケーションに付随するプログラム（ＯＳの機能を利用するためのＡＰＩ等）が、ＣＰＵその他のハードウェアにより実行されることによって実現される。また、ユーザ端末３Ｂは、記憶媒体として、ユーザ情報記憶部４０、天気推移情報記憶部４１および不所持可能性情報記憶部４２を備えている。

本実施形態に係る機能ブロック３０〜３７は、第１実施形態に係る機能ブロック１１〜１４、１６〜１８のそれぞれと同様の機能を有し、また、本実施形態に係る記憶媒体４０〜４２は、第１実施形態に係る記憶媒体２０、２２、２３のそれぞれと同様の情報を記憶する。ただし、ユーザ情報記憶部４０は、ユーザに関する情報として、第１実施形態のユーザ情報データベース２０ａの１件のレコードが有する情報（図４（Ａ）参照）のうち、通知方法情報およびメールアドレス情報を有さない情報を記憶する。また、本実施形態では、雨具提供店舗に関する情報の提供は、プッシュ通知によって行われる。

本実施形態においても、不所持可能性に応じた態様で、通知関連処理が実行されるため、ユーザの傘の提供に対するニーズに応じた態様で、雨具を提供する店舗に関する情報をユーザに提供することができる。なお、情報提供部３７は、プッシュ通知以外の方法で、雨具を提供する店舗に関する情報を提供してもよい。また、天気の推移の取得に関する処理、不所持可能性を判定する処理、情報を提供する処理に、上述した第１実施形態の各変形例の技術を応用できることは勿論である。

以上、本発明の各実施形態について説明した。ただし、上記各実施形態は、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその要旨、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。

例えば、上述した第１実施形態では、情報通知部１８は、通知関連処理において、不所持可能性が高い場合と、低い場合とで、情報の内容を変更した上で、雨具提供店舗に関する情報を通知した。この点について、情報通知部１８が、不所持可能性が高い場合には、雨具提供店舗に関する情報を通知する一方、不所持可能性が低い場合には、雨具提供店舗に関する情報を通知しない構成でもよい。この構成によれば、ユーザが傘を所持している可能性が高い場合には、通知タイミングで雨が降っている場合であっても、ユーザに対して情報が通知されないことになり、傘を所持しているのにもかかわらず、傘を提供する店舗の紹介が行われることによってユーザが煩わしさを感じる、といった事態が発生することを抑制できる。以上のことは、他の実施形態についても同様である。

また、第１実施形態において、ユーザ情報入力画面ＵＩ３によってユーザが入力する情報は、第１実施形態で例示した情報に限られない。例えば、年齢や性別を入力可能とし、雨具提供店舗に関する情報の通知に際し、情報配信サーバ２が、ユーザの年齢や性別に応じた店舗を紹介する構成でもよい。また、対象地域について、対象施設の最寄駅や、対象施設の住所等を入力する構成でもよい。以上のことは、他の実施形態についても同様である。

また、上述した第１実施形態において、不所持可能性判定部１７は、通知タイミングにおける対象地域の予報天気が、「晴」→「晴」→「雨」と推移している場合は、不所持可能性が高いと判定した。この点に関し、異なる態様の予報天気の推移の場合にも、不所持可能性が高いと判定する構成でもよい。例えば、不所持可能性判定部１７が、４つ以上の予報天気の推移に基づいて、特定の態様の推移をしている場合に、不所持可能性が高いと判定する構成でもよい。また、第１実施形態において、不所持可能性判定部１７が、２つの予報天気の推移に基づいて、不所持可能性を判定する構成でもよい。以上のことは、他の実施形態についても同様である。

また、上述した第１実施形態において、情報配信サーバ２の機能の一部をユーザ端末３が有し、情報配信サーバ２の処理として説明した処理のいずれか（全てであってもよい）を、情報配信サーバ２とユーザ端末３とが協働して実行する構成でもよい。この場合、情報配信サーバ２およびユーザ端末３が協働して、特許請求の範囲の「情報配信装置」として機能する。

１ 情報配信システム
２ 情報配信サーバ（情報配信装置）
３ ユーザ端末（情報配信装置）
３Ｂ ユーザ端末（情報提供装置）
１１、３１ ユーザ情報登録部（属性取得部）
１３、３２ 通知タイミング決定部
１６、３５ 天気推移取得部
１７、３６ 不所持可能性判定部
１８ 情報通知部
３７ 情報提供部

Claims (18)

1. 情報配信サーバと、ユーザが使用するユーザ端末とを備え、天気に応じて上記情報配信サーバから上記ユーザ端末に対して情報の通知を行うようにした情報配信システムであって、
   上記情報配信サーバは、
   ユーザに由来する地域の天気の推移を取得する天気推移取得部と、
   上記天気推移取得部により取得された天気の推移に基づいて、ユーザが雨具を所持していない可能性の高さを判定する不所持可能性判定部と、
   通知タイミングで、上記不所持可能性判定部により判定されたユーザが雨具を所持していない可能性の高さに応じた態様で、雨具を提供する店舗に関する情報の通知に関する処理を実行する情報通知部と、
   を備えたことを特徴とする情報配信システム。
2. 上記天気推移取得部は、
   上記ユーザに由来する地域の天気の推移として、上記通知タイミングにおける所定の地域の予報天気を、上記通知タイミングよりも前の複数のタイミングで取得する
   ことを特徴とする請求項１に記載の情報配信システム。
3. 上記不所持可能性判定部は、
   上記天気推移取得部により複数のタイミングで取得された予報天気が、雨具を要しない天気から、雨具を要する天気へと推移している場合、ユーザが雨具を所持していない可能性が高いと判定し、それ以外の場合、ユーザが雨具を所持していない可能性が低いと判定する
   ことを特徴とする請求項２に記載の情報配信システム。
4. 上記複数のタイミングは、３回以上のタイミングであり、
   上記不所持可能性判定部は、
   上記天気推移取得部により複数のタイミングで取得された予報天気が、雨具を要しない天気から、雨具を要する天気へと推移しており、上記複数のタイミングのうち最後のタイミングで予報天気が初めて雨具を要する天気となっている場合、ユーザが雨具を所持していない可能性が高いと判定し、それ以外の場合、ユーザが雨具を所持していない可能性が低いと判定する
   ことを特徴とする請求項３に記載の情報配信システム。
5. 上記天気推移取得部は、
   所定の地域における実際の天気を、上記通知タイミングよりも前の複数のタイミングで取得し、
   上記不所持可能性判定部は、
   上記天気推移取得部により複数のタイミングで取得された予報天気が、雨具を要しない天気から、雨具を要する天気へと推移していない場合であっても、
   上記天気推移取得部により複数のタイミングで取得された実際の天気が、雨具を要しない天気から、雨具を要する天気へと推移している場合は、ユーザが雨具を所持していない可能性が高いと判定する
   ことを特徴とする請求項３または４に記載の情報配信システム。
6. 上記天気推移取得部は、
   上記ユーザに由来する地域の天気の推移として、上記通知タイミングよりも前の複数のタイミングで、各タイミングにおいてユーザの位置が属する地域の実際の天気を取得する
   ことを特徴とする請求項１に記載の情報配信システム。
7. 上記天気推移取得部は、
   上記ユーザに由来する地域の天気の推移として、上記通知タイミングよりも前の複数のタイミングで、各タイミングにおける所定の地域の実際の天気を取得する
   ことを特徴とする請求項１に記載の情報配信システム。
8. 上記不所持可能性判定部は、
   上記天気推移取得部により複数のタイミングで取得された実際の天気が、雨具を要しない天気から、雨具を要する天気へと推移している場合、ユーザが雨具を所持していない可能性が高いと判定し、それ以外の場合、ユーザが雨具を所持していない可能性が低いと判定する
   ことを特徴とする請求項６または７に記載の情報配信システム。
9. 上記複数のタイミングは、３回以上のタイミングであり、
   上記不所持可能性判定部は、
   上記天気推移取得部により複数のタイミングで取得された実際の天気が、雨具を要しない天気から、雨具を要する天気へと推移しており、上記複数のタイミングのうち最後のタイミングで実際の天気が初めて雨具を要する天気となっている場合、ユーザが雨具を所持していない可能性が高いと判定し、それ以外の場合、ユーザが雨具を所持していない可能性が低いと判定する
   ことを特徴とする請求項８に記載の情報配信システム。
10. 上記天気推移取得部は、
    上記複数のタイミングのうち最初のタイミングで公開された、通知タイミングにおける所定の地域の予報天気を取得し、
    上記不所持可能性判定部は、
    上記天気推移取得部により複数のタイミングで取得された実際の天気が、雨具を要しない天気から、雨具を要する天気へと推移している場合であっても、上記天気推移取得部により取得された予報天気が雨具を要する天気の場合は、ユーザが雨具を所持していない可能性が低いと判定する
    ことを特徴とする請求項８または９に記載の情報配信システム。
11. 上記情報通知部は、
    上記不所持可能性判定部によりユーザが雨具を所持していない可能性が高いと判定された場合と、それ以外の場合とで、情報の内容を変更した上で、雨具を提供する店舗に関する情報を通知することを特徴とする請求項１〜１０の何れか１項に記載の情報配信システム。
12. 上記情報通知部は、
    上記不所持可能性判定部によりユーザが雨具を所持していない可能性が高いと判定された場合、それ以外の場合と比較して、雨具を提供する店舗への来店をより強く促す内容の情報を通知することを特徴とする請求項１１に記載の情報配信システム。
13. 上記情報通知部は、
    上記不所持可能性判定部によりユーザが雨具を所持していない可能性が高いと判定された場合、雨具を提供する店舗に関する情報を通知し、それ以外の場合、雨具を提供する店舗に関する情報を通知しないことを特徴とする請求項１〜１０の何れか１項に記載の情報配信システム。
14. 上記情報配信サーバは、
    ユーザの属性を示す属性情報を取得する属性取得部と、
    ユーザの属性に応じて、上記通知タイミングを決定する通知タイミング決定部と、
    を更に備えることを特徴とする請求項１〜１３の何れか１項に記載の情報配信システム。
15. 天気に応じて、ユーザが使用するユーザ端末に対して情報の通知を行う情報配信装置であって、
    上記ユーザに由来する地域の天気の推移を取得する天気推移取得部と、
    上記天気推移取得部により取得された天気の推移に基づいて、ユーザが雨具を所持していない可能性の高さを判定する不所持可能性判定部と、
    通知タイミングで、上記不所持可能性判定部により判定されたユーザが雨具を所持していない可能性の高さに応じた態様で、雨具を提供する店舗に関する情報の通知に関する処理を実行する情報通知部と、
    を備えたことを特徴とする情報配信装置。
16. 天気に応じて、ユーザが使用するユーザ端末に対して情報の通知を行う情報配信装置を制御するコンピュータにより実行される情報配信用プログラムであって、
    上記コンピュータを、
    ユーザに由来する地域の天気の推移を取得する天気推移取得部と、
    上記天気推移取得部により取得された天気の推移に基づいて、ユーザが雨具を所持していない可能性の高さを判定する不所持可能性判定部と、
    通知タイミングで、上記不所持可能性判定部により判定されたユーザが雨具を所持していない可能性の高さに応じた態様で、雨具を提供する店舗に関する情報の通知に関する処理を実行する情報通知部と、
    として機能させることを特徴とする情報配信用プログラム。
17. 天気に応じて情報の提供を行う情報提供装置であって、
    ユーザに由来する地域の天気の推移を取得する天気推移取得部と、
    上記天気推移取得部により取得された天気の推移に基づいて、ユーザが雨具を所持していない可能性の高さを判定する不所持可能性判定部と、
    通知タイミングで、上記不所持可能性判定部により判定されたユーザが雨具を所持していない可能性の高さに応じた態様で、雨具を提供する店舗に関する情報の提供に関する処理を実行する情報提供部と、
    を備えたことを特徴とする情報提供装置。
18. 天気に応じて情報の提供を行う情報提供装置を制御するコンピュータにより実行される情報提供用プログラムであって、
    上記コンピュータを、
    ユーザに由来する地域の天気の推移を取得する天気推移取得部と、
    上記天気推移取得部により取得された天気の推移に基づいて、ユーザが雨具を所持していない可能性の高さを判定する不所持可能性判定部と、
    通知タイミングで、上記不所持可能性判定部により判定されたユーザが雨具を所持していない可能性の高さに応じた態様で、雨具を提供する店舗に関する情報の提供に関する処理を実行する情報提供部と、
    として機能させることを特徴とする情報提供用プログラム。

Images