ホーム > 特許ランキング > 株式会社ＮＴＴドコモ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-09
(45)【発行日】2024-08-20
(54)【発明の名称】情報処理システム
(51)【国際特許分類】
G06Q 10/02 20120101AFI20240813BHJP
G06Q 30/015 20230101ALI20240813BHJP
G06Q 30/0207 20230101ALI20240813BHJP
G07G 1/12 20060101ALI20240813BHJP
G07G 1/14 20060101ALN20240813BHJP
【ＦＩ】
G06Q10/02
G06Q30/015
G06Q30/0207
G07G1/12 361C
G07G1/12 321M
G07G1/12 341B
G07G1/14
【請求項の数】
7
(21)【出願番号】P 2020191800
(22)【出願日】2020-11-18
(65)【公開番号】P2022080621
(43)【公開日】2022-05-30
【審査請求日】2023-08-15
(73)【特許権者】
【識別番号】392026693
【氏名又は名称】株式会社ＮＴＴドコモ
(74)【代理人】
【識別番号】100088155
【弁理士】
【氏名又は名称】長谷川 芳樹
(74)【代理人】
【識別番号】100113435
【弁理士】
【氏名又は名称】黒木 義樹
(74)【代理人】
【識別番号】100121980
【弁理士】
【氏名又は名称】沖山 隆
(74)【代理人】
【識別番号】100128107
【弁理士】
【氏名又は名称】深石 賢治
(74)【代理人】
【識別番号】100183438
【弁理士】
【氏名又は名称】内藤 泰史
(72)【発明者】
【氏名】山口 哲哉
(72)【発明者】
【氏名】鈴木 喬
【審査官】貝塚 涼
(56)【参考文献】
【文献】特開平０８－０１６６５８（ＪＰ，Ａ）
【文献】特開２００７－０５８８００（ＪＰ，Ａ）
【文献】特開２０１７－１８２４１０（ＪＰ，Ａ）
【文献】特開２０１９－０７９２１１（ＪＰ，Ａ）
【文献】特開２０１３－１４３０２７（ＪＰ，Ａ）
【文献】特開２０１８－０２８８１８（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ － ９９／００
Ｇ０７Ｇ １／１２
Ｇ０７Ｇ １／１４
(57)【特許請求の範囲】
【請求項1】
複数の店舗を含んで構成されるコミュニティの各店舗からの呼び込み情報に応じて、当該コミュニティを利用する複数のユーザが来店に向けて起こしたアクションを示すユーザアクション情報と、前記複数の店舗のうちキャンセル待ちが発生している一又は複数のキャンセル待ち店舗及び予約が可能な一又は複数の予約可能店舗を示す店舗情報と、前記キャンセル待ち店舗を予約している複数のキャンセル待ち店舗ユーザを示すキャンセル待ち店舗ユーザ情報と、を取得する取得部と、前記ユーザアクション情報に基づき、前記複数のキャンセル待ち店舗ユーザ毎に、来店に向けたアクションを起こしたアクション対象店舗を特定し、前記アクション対象店舗への来店回数が多いほど、前記コミュニティにおけるこだわり度が高くなるように、該こだわり度を推定する推定部と、
前記複数のキャンセル待ち店舗ユーザについて、前記こだわり度が低いほど、いずれかの前記予約可能店舗への予約変更の案内を受ける対象ユーザに選定されやすくなるように、一又は複数の前記対象ユーザを選定し、前記対象ユーザに対していずれかの前記予約可能店舗への予約変更を案内する案内メッセージを生成する制御部と、
前記案内メッセージを、前記対象ユーザによる閲覧のために出力する出力部と、を備える、情報処理システム。
【請求項2】
前記複数の店舗それぞれについて、将来の各日時における、予約可能席の有無を示す予約可能席情報、及び、予約している予約ユーザを示す予約ユーザ情報を特定する第１処理と、前記複数の店舗のうち、前記予約可能席情報において前記予約可能席が無い店舗を前記キャンセル待ち店舗として特定すると共に前記予約可能席が有る店舗を前記予約可能店舗として特定し、前記予約ユーザ情報において前記キャンセル待ち店舗の前記予約ユーザとして示されている複数のユーザを前記キャンセル待ち店舗ユーザとして特定する第２処理と、を実行する特定部を更に備え、
前記取得部は、前記特定部が特定した前記キャンセル待ち店舗及び前記予約可能店舗に基づき前記店舗情報を取得し、前記特定部が特定した複数の前記キャンセル待ち店舗ユーザに基づき前記キャンセル待ち店舗ユーザ情報を取得する、請求項１に記載の情報処理システム。
【請求項3】
前記制御部は、前記対象ユーザの前記アクション対象店舗であって且つ前記予約可能店舗である推奨店舗を特定し、前記対象ユーザに対して、前記推奨店舗への予約変更を案内する前記案内メッセージを生成する、請求項１又は２に記載の情報処理システム。
【請求項4】
前記制御部は、前記複数のキャンセル待ち店舗ユーザについて、前記アクション対象店舗の数が多いほど、前記対象ユーザに選定されやすくなるように、前記対象ユーザを選定する、請求項３に記載の情報処理システム。
【請求項5】
前記制御部は、前記対象ユーザに対して、前記キャンセル待ち店舗から前記予約可能店舗に移動した場合にインセンティブを付与する旨の情報を含んだ前記案内メッセージを生成する、請求項３又は４に記載の情報処理システム。
【請求項6】
店舗の利用に係るインセンティブを前記ユーザに付与するインセンティブ付与部を更に備え、前記取得部は、現時点から予め定められた期間遡った時点までの対象期間について、呼び込み情報の配信が行われた前記複数のユーザに含まれるユーザ毎に、
前記複数の店舗それぞれへの来店回数と、
前記複数の店舗それぞれについての、前記呼び込み情報の配信とともにユーザに付与された、インセンティブの利用回数である店舗インセンティブ利用回数と、
前記複数の店舗全体への来店回数と、
前記複数の店舗全体についての、前記インセンティブの利用回数である全体インセンティブ利用回数と、を更に取得し、
前記制御部は、
ユーザ毎に、前記複数の店舗に含まれる各店舗への前記来店回数に対する前記店舗インセンティブ利用回数の割合、及び前記複数の店舗全体への来店回数に対する前記全体インセンティブ利用回数の割合を算出し、
前記店舗インセンティブ利用回数の割合、及び前記全体インセンティブ利用回数の割合に基づき算出された第１対象値が所定の第１閾値以上であるユーザをインセンティブ必要ユーザとして選定し、前記第１対象値が前記第１閾値未満であるユーザをインセンティブ不要ユーザとして選定し、
前記インセンティブ付与部は、前記インセンティブ必要ユーザ、及び前記インセンティブ不要ユーザを示す情報に基づいて、前記インセンティブを前記ユーザに付与する、請求項１～５のいずれか一項に記載の情報処理システム。
【請求項7】
前記インセンティブは、店舗の利用に係る割引券であって、前記取得部は、前記対象期間について、ユーザ毎に、
前記複数の店舗のそれぞれについての、前記割引券の利用平均額である店舗利用平均額、及び前記割引券の付与平均額である店舗付与平均額と、
前記複数の店舗の全体についての、前記割引券の利用平均額である全体利用平均額及び前記割引券の付与平均額である全体付与平均額と、を更に取得し、
前記制御部は、
ユーザ毎に、前記複数の店舗に含まれる各店舗についての前記店舗付与平均額に対する前記店舗利用平均額の割合、及び前記全体付与平均額に対する前記全体利用平均額の割合を算出し、
前記複数の店舗に含まれる各店舗についての前記店舗付与平均額に対する前記店舗利用平均額の割合、及び前記全体付与平均額に対する前記全体利用平均額の割合に基づき算出された第２対象値が所定の第２閾値以上である前記インセンティブ必要ユーザを、高インセンティブ必要ユーザとして更に選定し、前記第２対象値が前記第２閾値未満である前記インセンティブ必要ユーザを、低インセンティブ許容ユーザとして更に選定する、請求項６に記載の情報処理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理システムに関する。
【背景技術】
【0002】
複数の店舗に対して、売り上げに関するマーケティングを行う技術が知られている。特許文献１には、各店舗の売上データを収集し、店舗別の売上及び地域別の売上に関する集計を解析し、解析した結果を店舗端末に送信するサービス代行サーバが記載されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２００２－２８８７４５号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ここで、例えば、複数の店舗で構成されるコミュニティにおいて、当該コミュニティ全体の売上を向上させることが望まれる場合がある。しかしながら、コミュニティ内において、ユーザを受け入れきれないほど混雑する店舗がある一方で空いている店舗がある等、複数の店舗間で混雑度の偏りが発生すると、コミュニティ全体としての売り上げが伸びづらくなってしまう。
【0005】
本発明は上記実情に鑑みてなされたものであり、コミュニティ全体の売り上げの最適化に適したマーケティングを行うことができる情報処理システムに関する。
【課題を解決するための手段】
【0006】
本発明の一態様に係る情報処理システムは、複数の店舗を含んで構成されるコミュニティの各店舗からの呼び込み情報に応じて、当該コミュニティを利用する複数のユーザが来店に向けて起こしたアクションを示すユーザアクション情報と、複数の店舗のうちキャンセル待ちが発生している一又は複数のキャンセル待ち店舗及び予約が可能な一又は複数の予約可能店舗を示す店舗情報と、キャンセル待ち店舗を予約している複数のキャンセル待ち店舗ユーザを示すキャンセル待ち店舗ユーザ情報と、を取得する取得部と、ユーザアクション情報に基づき、複数のキャンセル待ち店舗ユーザそれぞれの、コミュニティにおけるこだわり度を推定する推定部と、複数のキャンセル待ち店舗ユーザについて、こだわり度が低いほど、いずれかの予約可能店舗への予約変更の案内を受ける対象ユーザに選定されやすくなるように、一又は複数の対象ユーザを選定し、対象ユーザに対していずれかの予約可能店舗への予約変更を案内する案内メッセージを生成する制御部と、案内メッセージを、対象ユーザによる閲覧のために出力する出力部と、を備える。
【0007】
本発明の一態様に係る情報処理システムでは、ユーザアクション情報に基づき、複数のキャンセル待ち店舗ユーザそれぞれの、コミュニティにおけるこだわり度が推定される。ユーザアクション情報は、複数の店舗を含んで構成されるコミュニティの各店舗からの呼び込み情報に応じてユーザが来店に向けて起こしたアクションを示す。そして、本情報処理システムでは、複数のキャンセル待ち店舗ユーザについて、こだわり度が低いほどいずれかの予約可能店舗への予約変更の案内を受ける対象ユーザに選定されやすくなるように、一又は複数の対象ユーザが選定され、いずれかの予約可能店舗への予約の変更を案内する案内メッセージが生成され、当該案内メッセージが、上記対象ユーザによる閲覧のために出力される。
【0008】
このように、店舗からの呼び込み情報に応じてユーザが来店に向けて実際に起こしたアクション（予約等）が考慮されて、各ユーザについてコミュニティにおけるこだわり度が推定されることにより、コミュニティに対するユーザのこだわり度を高精度に推定することができる。そして、高精度に推定されたこだわり度が低い（すなわち、店舗に対するこだわりが低い）ユーザほど、予約変更の案内を受け付ける対象ユーザに選定されやすくすることにより、キャンセル待ち店舗ユーザに対する予約可能店舗への予約の変更が効果的に（高確率で）促される。その結果、混雑によりユーザを受け入れきれないキャンセル待ち店舗から、ユーザの受け入れが可能な予約可能店舗へのユーザの移動の可能性を高めることができるので、コミュニティ全体の混雑度の平準化を図ることができる。これにより、例えば、キャンセル待ちとなっておりそのままでは売上に寄与しなかったユーザが、予約可能店舗の売り上げに寄与することとなり、コミュニティ全体としての売上を向上させることができる。以上のように、本発明の一態様に係る情報処理システムによれば、コミュニティ全体の売り上げの最適化に適したマーケティングを行うことができる。
【発明の効果】
【0009】
本発明によれば、コミュニティ全体の売り上げの最適化に適したマーケティングを行うことができる。
【図面の簡単な説明】
【0010】
【図1】本実施形態に係る情報処理システムの機能構成を示すブロック図である。
【図2】本実施形態に係る案内情報の一例を示す図である。
【図3】本実施形態に係る予約可能席情報の一例を示す図である。
【図4】本実施形態に係るユーザの基礎情報の一例を示す図である。
【図5】本実施形態に係る来店ＦＢ情報の一例を示す図である。
【図6】本実施形態に係る割引券情報の一例を示す図である。
【図7】本実施形態に係る管理用呼び込み情報の一例を示す図である。
【図8】本実施形態に係る店舗予約情報の一例を示す図である。
【図9】本実施形態に係るキャンセル待ち予約情報の一例を示す図である。
【図10】本実施形態に係る呼び込み結果・ＦＢ情報の一例を示す図である。
【図11】店舗ステータス情報の一例を示す図である。
【図12】本実施形態に係る情報処理システムが行う管理処理から平準化処理までの一連の流れを示すフローチャートである。
【図13】本実施形態に係る情報処理システムが行うインセンティブ決定処理を示すフローチャートである。
【図14】本実施形態に係る情報処理システムに含まれる通信端末、店舗管理端末、及びコミュニティサーバのハードウェア構成を示す図である。
【発明を実施するための形態】
【0011】
以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。図面の説明において、同一又は同等の要素には同一符号を用い、重複する説明を省略する。
【0012】
【0013】
情報処理システム１は、コミュニティを利用する複数のユーザＵと、コミュニティに含まれる複数の店舗との間の情報のやり取りを管理し、コミュニティに含まれる複数の店舗の売上に関するマーケティングを行うシステムである。コミュニティは、一の地域において複数の店舗を含んで構成されている。コミュニティの例としては、商店街、駅前の繁華街、及びショッピングモールが挙げられる。複数の店舗の例としては、飲食店が挙げられる。以下、商店街をコミュニティとし、商店街に含まれる飲食店を複数の店舗とし、商店街に含まれる飲食店を利用する複数のユーザを上述した複数のユーザＵとして説明する。また、以下、コミュニティに含まれる複数の店舗のそれぞれを、単に「店舗」という場合がある。
【0014】
情報処理システム１は、以下の３つの処理を行う。まず、情報処理システム１は、複数の店舗から複数のユーザＵに向けて配信される呼び込みメッセージ及び割引券と、複数のユーザＵから受け付ける複数の店舗の予約情報とを管理する管理処理を行う。また、情報処理システム１は、コミュニティ内（具体的には、複数の店舗間）で混雑度の偏りが生じる場合には、複数の店舗の混雑度が平準化されるように、複数のユーザＵの中から選定された対象ユーザに対して、コミュニティ内での店舗間の予約の移動を案内する平準化処理を行う。さらに、情報処理システム１は、各ユーザＵに与える割引券の額の度合い（インセンティブの度合い）を決定するインセンティブ決定処理を行う。なお、情報処理システム１が行う処理は上記に限られず、他の処理を行ってもよい。
【0015】
各通信端末１０は、コミュニティを利用するユーザＵが携帯している端末である。各店舗管理端末２０は、店舗ごとに設置され、店舗の管理に係る種々の情報を処理する端末である。コミュニティサーバ３０は、複数のユーザＵと複数の店舗との間の情報のやり取りを管理するサーバである。情報処理システム１では、各通信端末１０とコミュニティサーバ３０とが、各通信端末１０と各店舗管理端末２０とが、また、各店舗管理端末２０とコミュニティサーバ３０とが、相互に通信可能に構成されている。以下、情報処理システム１では、各通信端末１０が互いに同様の機能を有し、また、各店舗管理端末２０が互いに同様の機能を有しているとし、一の通信端末１０、及び一の店舗管理端末２０に着目して説明を行う。
【0016】
情報処理システム１では、コミュニティサーバ３０が、複数の通信端末１０及び複数の店舗管理端末２０から取得した種々の情報（詳細は後述）に基づき、上述した管理処理、平準化処理、及びインセンティブ決定処理を行う。ここで、平準化処理について簡単に説明する。コミュニティサーバ３０は、まず、コミュニティ内においてキャンセル待ちが発生しているキャンセル待ち店舗、及びキャンセル待ち店舗を予約しているキャンセル待ち店舗ユーザを特定する。そして、コミュニティサーバ３０は、キャンセル待ち店舗ユーザの中から選定した対象ユーザが有する通信端末１０に対して、予約が可能である予約可能店舗への予約変更を促す案内メッセージを出力する。これにより、案内メッセージを受信した対象ユーザに予約可能店舗への予約変更を促すことができる結果、コミュニティ内における混雑度の平準化を図ることができる。
【0017】
通信端末１０は、例えば、無線通信を行うよう構成された端末である。通信端末１０は、例えば、スマートフォン、タブレット型端末、ＰＣ、及びウェアラブル型の通信機器等である。通信端末１０は、コミュニティサーバ３０から受信した種々の情報を通信端末１０が有する画面（図示せず）に表示し、表示された情報に対するユーザＵの回答、及び予約のリクエスト等の情報をユーザＵから入力受付する。
【0018】
通信端末１０がコミュニティサーバ３０から受信する情報には、複数の店舗についての、呼び込みメッセージ（呼び込み情報）、割引券を示す情報、及び予約に対するアンケートが含まれる。例えば、通信端末１０は、ユーザＵが一の店舗の呼び込みメッセージを受信した場合、ユーザＵから、当該店舗の予約に関する登録用予約情報を、画面を介して入力受付する。なお、登録用予約情報には、当該店舗を予約するユーザ（予約ユーザ）Ｕを示すユーザ情報（予約ユーザ情報）、当該ユーザＵが当該店舗を予約している日時を示す予約日時情報、及び予約人数等の情報が含まれている。
【0019】
また、例えば、通信端末１０は、予約に対するアンケートとして、呼び込みアンケート、及び来店アンケートを画面に表示する。呼び込みアンケートは、受信した呼び込みメッセージに対するアンケートである。来店アンケートは、ユーザＵが予約後に実際に来店した店舗に対するアンケートである。そして、通信端末１０は、呼び込みアンケートに対するユーザＵの呼び込みフィードバック情報（以下、「呼び込みＦＢ情報」という）と、来店アンケートに対するユーザＵの来店フィードバック情報（以下、「来店ＦＢ情報」という）とを、ユーザＵから入力受付する。呼び込みＦＢ情報及び来店ＦＢ情報の詳細については後述する。
【0020】
また、通信端末１０は、ユーザＵの基礎情報の入力情報を画面に表示し、表示された入力情報に対するユーザＵの回答（基礎情報）をユーザＵから入力受付する。さらに、通信端末１０は、呼び込みメッセージに対するユーザＵのアクションを示すアクション情報を入力受付する。当該アクションの例としては、画面上において一の店舗の呼び込みメッセージを開封すること、及び画面を介して呼び込みメッセージに含まれるリンクを選択することにより当該店舗の予約状況を確認することが挙げられる。
【0021】
通信端末１０は、入力受付した登録用予約情報、呼び込みＦＢ情報、来店ＦＢ情報、基礎情報、及びアクション情報を、コミュニティサーバ３０に出力する。出力された各情報は、コミュニティサーバ３０による管理処理、平準化処理、及びインセンティブ決定処理に用いられる。
【0022】
店舗管理端末２０は、店舗の運営に係る種々の情報を管理する端末である。店舗管理端末２０は、各店舗に設置されており、案内情報、予約可能席情報、登録用呼び込み情報、及び登録用割引券情報を入力受付し、管理する。案内情報は、店舗に来店したユーザＵ、及びユーザＵを案内した席に関する情報である。予約可能席情報は、店舗の予約可能席に係る情報である。登録用呼び込み情報及び登録用割引券情報の詳細については後述する。店舗管理端末２０は、種々の情報を表示する画面を有する。店舗管理端末２０は、案内情報、予約可能席情報、登録用呼び込み情報、及び登録用割引券情報を、定期的にコミュニティサーバ３０に出力する。なお、店舗管理端末２０は、取得の度に各情報をコミュニティサーバ３０に出力してもよい。
【0023】
店舗管理端末２０は、機能的な構成要素として、入力受付部２１と、管理部２２と、出力部２３とを有している。
【0024】
入力受付部２１は、案内情報、予約可能席情報、登録用呼び込み情報、及び登録用割引券情報の入力を受け付ける。案内情報、予約可能席情報、登録用呼び込み情報、及び登録用割引券情報は、例えば、店舗の従業員によって入力される。なお、これらの情報の一部は、自動的に入力されるものであってもよい。
【0025】
図２は、案内情報の一例を示す図である。図２に示される例では、入力受付部２１は、整理券番号、予約フラグ、来店日時、来店人数、予約番号、及び割引券情報を含む案内情報を入力受付する。整理券番号は、ユーザＵが来店した際に配布された番号である。なお、整理券番号は、ユーザＵに配布されずに、自動で付与される番号であってもよい。予約フラグは、ユーザＵが予め店舗への来店の予約をしたか否かを示す情報である。予約番号は、ユーザＵが行った来店予約を一意に識別可能な番号である（詳細は後述）。割引券番号は、ユーザＵが店舗にて利用する割引券に関する情報である（詳細は後述）。なお、予約フラグ、予約人数、予約番号等の案内情報の一部は、店舗に来店したユーザＵが店舗管理端末２０の画面を操作することによっても入力されてもよいし、通信端末１０を介してユーザＵによって入力されてもよい。
【0026】
予約可能席情報は、各店舗において予約が可能な席に関する情報である。図３は、予約可能席情報の一例を示す図である。図３に示される例では、入力受付部２１は、店舗を示す情報、予約可能日時、席番号、及び予約可能人数を含む予約可能席情報を入力受付する。席番号は、予約可能日時に予約可能な店舗の席を一意に識別可能な情報である。このように、予約可能席情報は、店舗における予約可能席の有無を示す情報である。
【0027】
登録用割引券情報は、店舗がユーザＵに配信する割引券に関する情報である。入力受付部２１は、例えば、店舗を示す情報、割引券番号、割引券の割引額、一又は複数の割引付与条件、及びユーザ情報を含む登録用割引券情報を入力受付する。登録用割引券情報の詳細については後述する。
【0028】
登録用呼び込み情報は、ユーザＵに呼び込みメッセージを配信するための情報である。入力受付部２１は、例えば、店舗を示す情報、配信日時、呼び込みメッセージ、配信対象条件、人数、割引券番号、及び予約番号を含む登録用呼び込み情報を入力受付する。呼び込みメッセージは、ユーザＵに対して店舗への来店を促すメッセージである。登録用呼び込み情報の詳細については後述する。
【0029】
入力受付部２１は、入力受付した案内情報、予約可能席情報、登録用割引券情報、及び登録用呼び込み情報を管理部２２に出力する。管理部２２は、入力された各情報を管理し、管理した情報を出力部２３に出力する。出力部２３は、管理部２２から取得した各情報をコミュニティサーバ３０に出力する。
【0030】
コミュニティサーバ３０は、上述した管理処理、平準化処理、及びインセンティブ決定処理を行う。コミュニティサーバ３０は、管理処理として、複数の店舗の予約情報、割引券情報、及び管理用呼び込み情報の管理と、複数のユーザＵへの呼び込みメッセージ及び割引券の配信とを行う。また、コミュニティサーバ３０は、インセンティブ決定処理として、各ユーザＵに与える割引券の額の度合い（インセンティブの度合い）を決定する。
【0031】
コミュニティサーバ３０は、平準化処理として、管理処理から得た種々の情報から、キャンセル待ち店舗、予約可能店舗、及びキャンセル待ち店舗ユーザを特定する。キャンセル待ち店舗ユーザは、キャンセル待ち店舗を予約しているユーザＵである。そして、コミュニティサーバ３０は、キャンセル待ち店舗ユーザの中から選定した対象ユーザに対して予約可能店舗への移動を促す案内メッセージを生成し、生成した案内メッセージを対象ユーザの閲覧のために出力する。コミュニティサーバ３０は、機能的な構成要素として、第１取得部３１と、記憶部３２と、管理部（特定部、インセンティブ付与部）３３と、第２取得部（取得部）３４と、推定部３５と、制御部３６と、出力部３７とを有している。
【0032】
第１取得部３１は、通信端末１０から、登録用予約情報、呼び込みＦＢ情報、来店ＦＢ情報、ユーザＵの基礎情報、及びアクション情報を取得し、店舗管理端末２０から、案内情報、予約可能席情報、登録用割引券情報、及び登録用呼び込み情報を取得する。第１取得部３１は、取得した登録用予約情報、呼び込みＦＢ情報、来店ＦＢ情報、基礎情報、アクション情報、案内情報、予約可能席情報、登録用割引券情報、登録用呼び込み情報、基礎情報、及び来店ＦＢ情報を、記憶部３２に出力する。
【0033】
記憶部３２は、各機能部から入力（格納）された各情報を記憶している。記憶部３２は、上記各情報をデータ３００として記憶している。なお、記憶部３２は、コミュニティサーバ３０の外部の構成であってもよい。すなわち、データ３００は、コミュニティサーバ３０の外部のサーバに記憶されたデータであってもよい。
【0034】
図４は、第１取得部３１から入力されるユーザＵの基礎情報の一例を示す図である。基礎情報は、ユーザＵのユーザ識別番号と、ユーザＵが有する通信端末１０の端末識別番号と、ユーザＵの性別と、ユーザＵの年齢と、ユーザＵの居住地情報と、ユーザＵのお気に入り店舗を示す情報と、ユーザＵのコミュニティの利用頻度とを含んでいる。なお、上述した基礎情報は、上記各情報に限られず、ユーザＵに関する他の情報を含んでいてもよい。
【0035】
図５は、第１取得部３１から入力される来店ＦＢ情報の一例を示す図である。来店ＦＢ情報は、ユーザＵのユーザ識別番号と、ユーザＵが予約した店舗を示す情報と、ユーザＵによる店舗の来店日と、ＦＢ１（満足度）情報と、ＦＢ２（理由）情報とを含んでいる。ＦＢ１（満足度）情報、及びＦＢ２（理由）情報は、来店ＦＢ情報に含まれるアンケートの回答内容を示す。具体的には、ＦＢ１（満足度）情報は、ユーザＵが来店した店舗に対する満足度を示す。ＦＢ２（理由）情報は、ＦＢ１（満足度）の理由を示す。なお、上述した来店ＦＢ情報は、上記各情報に限られず、例えば他の内容を示すＦＢ情報を含んでいてもよい。
【0036】
管理部３３は、第１取得部３１によって取得されて記憶部３２に記憶されている各情報に基づき、複数の店舗の店舗予約情報、キャンセル待ち予約情報、割引券情報、管理用呼び込み情報、及び呼び込み結果・ＦＢ情報を生成する。そして、管理部３３は、生成した各情報を管理し、複数のユーザＵへの呼び込みメッセージ及び割引券の配信を行う。なお、生成した各情報を管理するとは、例えば、生成した各情報を記憶部３２に格納（出力）することにより管理するものであってもよい。
【0037】
まず、割引券情報に関する処理について説明する。管理部３３は、記憶部３２に記憶されている登録用割引券情報の内容についてコミュニティで定められたルール違反及び矛盾等の問題がないと判断した場合、登録用割引券情報に基づき、割引券情報を生成する。ルール違反の例としては、割引登録情報に含まれる割引額が、予め定められた額を超えた場合が挙げられる。管理部３３は、生成した割引券情報を記憶部３２に出力する。
【0038】
図６は、割引券情報の一例を示す図である。図６に示される例では、管理部３３は、店舗を示す情報、割引券番号、割引券の割引額、割引付与条件１～４、及びユーザ情報を含む割引券情報を生成する。割引券番号は、割引券を一意に識別可能な情報である。割引付与条件１～４のそれぞれは、店舗が割引券を付与する対象のユーザＵを選定する際の条件を示す。当該条件の例としては、予約の必要性の有無、及び来店の時間帯が挙げられる。ユーザ情報の詳細については後述する。なお、本実施形態では、割引券情報に含まれる各情報は、店舗管理端末２０から取得された登録用割引券情報と一致する。しかしながら、割引券情報は、上記各情報に限られず、割引券に関する他の情報を含んでいてもよい。
【0039】
次に、管理用呼び込み情報に関する処理について説明する。管理部３３は、記憶部３２に記憶されている登録用呼び込み情報について、コミュニティで定められたルール違反及び矛盾等の問題がないか否かを判定する。ルール違反の例としては、登録用呼び込み情報の配信のタイミングが、予め定められた一日の配信の回数の上限を超えた場合が挙げられる。
【0040】
管理部３３は、登録用呼び込み情報に問題がないと判定した場合、ユーザ情報に基づき、複数のユーザＵのうち登録用呼び込み情報に含まれる各配信条件を満たす配信対象ユーザを選定する。そして、管理部３３は、登録用呼び込み情報に含まれる配信日時に、配信対象ユーザの通信端末１０に呼び込みメッセージを配信する。管理部３３は、登録用呼び込み情報に割引券番号が含まれている場合、当該割引券番号に対応する割引券情報を呼び込みメッセージとともに配信する。割引券は、ユーザＵに付与される、店舗の利用に係るインセンティブである。そして、管理部３３は、登録用呼び込み情報に含まれる各情報に、予約番号と、呼び込み番号とを更に含んだ管理用呼び込み情報を生成し、生成した管理用呼び込み情報を記憶部３２に出力する。
【0041】
図７は、管理用呼び込み情報の一例を示す図である。図７に示される例では、管理部３３は、店舗を示す情報、配信日時、呼び込みメッセージ、配信対象条件、人数、割引券番号、予約番号、及び呼び込み番号を含む管理用呼び込み情報を生成する。配信日時は、呼び込みメッセージを配信する予定の日時である。配信対象条件は、呼び込みメッセージの配信対象ユーザを選定するための条件である。配信対象条件の例としては、ユーザＵの居住地、ユーザの性別、及びユーザＵの年代が挙げられる。人数は、呼び込みメッセージを配信する人数の上限を示す。予約番号は、ユーザＵが呼び込みメッセージの配信によって店舗を予約した場合（詳細は後述）にユーザＵに付与される予約番号である。呼び込み番号は、一の管理用呼び込み情報を一意に識別可能な情報である。一例として、配信対象条件が「Ｔ市に在住」である場合、管理部３３は、各ユーザＵの基礎情報に含まれる居住地を参照し、Ｔ市に在住のユーザＵの中から配信対象ユーザを選定して呼び込み配信を行う。なお、上述した管理用呼び込み情報は、上記各情報に限られず、呼び込み配信に関する他の情報を含んでいてもよい。
【0042】
次に、店舗予約情報及びキャンセル待ち予約情報に関する処理について説明する。管理部３３は、ユーザＵからのリクエストに応じて、記憶部３２に記憶されている登録用予約情報及び予約可能席情報を参照して、ユーザがリクエストする店舗において、ユーザＵの予約人数及びユーザＵの予約希望日時に対して予約可能な席があるか否かを特定する。そして、管理部３３は、当該店舗に予約可能な席がある場合、通信端末１０の画面にその旨を表示させる。また、管理部３３は、店舗において予約可能な席がない場合、通信端末１０の画面に当該店舗がキャンセル待ちの状態である旨を表示させる。なお、本実施形態では、ユーザＵからのリクエストは、例えば、ユーザＵが受け取った呼び込みメッセージに記載されたリンクをユーザＵが選択する等、呼び込みメッセージを介して行われるものとして説明する。なお、ユーザＵからのリクエストは、呼び込み配信を介さずに、例えば通信端末１０にインストールされたアプリケーションを介する等、他の方法によって行われてもよい。
【0043】
そして、管理部３３は、通信端末１０を介して、ユーザＵから、店舗の予約及びキャンセル待ち予約を受け付け、店舗の予約及びキャンセル待ち予約を確定する。このとき、管理部３３は、ユーザＵの予約が、予め定められたコミュニティルールの予約可能数（１日１席等）の範囲内であるか、予約金の事前支払いが可能か否か等、予め定められたルールに適しているかを判定し、適していないと判定した場合、当該予約を拒否してもよい。管理部３３は、確定した予約に基づき店舗予約情報を生成し、確定したキャンセル予約に基づきキャンセル待ち予約情報を生成する。
【0044】
図８は、店舗予約情報の一例を示す図である。図８に示される例では、管理部３３は、ユーザ識別番号、予約した店舗を示す情報、予約日時情報、席番号、予約人数、割引券番号、及び予約番号を含む店舗予約情報を生成する。ユーザ識別番号は、店舗毎の、複数のユーザＵのうち店舗を予約しているユーザＵ（予約ユーザ）を示す情報である。予約日時情報は、ユーザＵが予約している将来の日時を示す情報である。席番号は、予約した店舗における予約席を一意に識別可能な番号である。割引券は、ユーザＵが受け取った呼び込み配信に含まれる割引券であって、割引券番号は、ユーザＵが予約時に使用した当該割引券の番号を示す。管理部３３は、生成した店舗予約情報を記憶部３２に出力する。
【0045】
図９は、キャンセル待ち予約情報の一例を示す図である。図９に示される例では、管理部３３は、ユーザ識別番号、予約した店舗を示す情報、予約日時情報、予約人数、割引券番号、及びキャンセル待ち予約番号を含むキャンセル待ち予約情報を取得する。キャンセル待ち予約番号は、ユーザＵがキャンセル待ち店舗を予約した場合にユーザＵに付与される予約番号である。なお、上述した店舗予約情報及びキャンセル待ち予約情報のそれぞれは、上記各情報に限られず、呼び込み配信に関する他の情報を含んでいてもよい。管理部３３は、生成したキャンセル待ち予約情報を記憶部３２に出力する。
【0046】
次に、呼び込み結果・ＦＢ情報に関する処理について説明する。管理部３３は、記憶部３２に記憶されている、店舗予約情報、呼び込みＦＢ情報、案内情報、割引券情報、及びアクション情報等に基づき、呼び込み結果・ＦＢ情報を生成する。呼び込み結果・ＦＢ情報は、ユーザＵが受信した複数の店舗の呼び込みメッセージに応じてユーザＵが来店に向けて起こしたアクションを示す情報である。管理部３３は、生成した呼び込み結果・ＦＢ情報を記憶部３２に出力する。
【0047】
図１０は、呼び込み結果・ＦＢ情報の一例を示す図である。図１０に示される例では、管理部３３は、ユーザ識別番号と、ユーザＵが予約した店舗を示す情報と、呼び込み番号と、付与割引券番号と、ＦＢ１（魅力）情報と、ＦＢ２（理由）情報と、メッセージ開封情報と、予約状況確認情報と、予約の有無情報と、来店の有無情報と、割引券利用有無情報とを含む呼び込み結果・ＦＢ情報を生成する。付与割引券番号は、呼び込み配信時に付与された割引券の番号を示す。ＦＢ１（魅力）情報及びＦＢ２（理由）は、呼び込みＦＢ情報に含まれるアンケートの内容を示す。具体的には、ＦＢ１（魅力）情報は、ユーザＵが来店した店舗に対する魅力を示す。ＦＢ２（理由）は、ＦＢ１（魅力）の理由を示す。割引券利用有無情報は、ユーザＵによる来店時の割引券の利用の有無を示す。
【0048】
メッセージ開封情報は、通信端末１０を介して、呼び込み配信された呼び込みメッセージがユーザＵによって開封されたか否かの情報を示す。予約状況確認情報は、ユーザＵが店舗の予約状況を確認したか否かの情報を示す。管理部３３は、例えば、アクション情報に、通信端末１０の画面を介して呼び込みメッセージに含まれるリンクが選択されたアクションが含まれている場合、「実施」と判定する。予約の有無情報は、ユーザＵが呼び込みメッセージの配信により予約を行ったか否かを示す。来店の有無情報は、ユーザＵが店舗に来店したか否かの情報を示す。管理部３３は、例えば、案内情報に含まれる予約番号と、店舗予約情報に含まれる予約番号を照合することによって、上述した割引券の利用の有無、予約の有無、及び来店の有無を判定する。呼び込み結果・ＦＢ情報は、後述する平準化処理等に用いられる。なお、上記各情報の判定方法は特に限られず、ユーザＵが通信端末１０を介して来店した旨をコミュニティサーバ３０に出力することにより判定されてもよい。また、上述した呼び込み結果・ＦＢ情報は、上記各情報に限られず、呼び込み配信に関する他の情報を含んでいてもよい。
【0049】
また、管理部３３は、記憶部３２に記憶されている予約可能席情報及び登録用予約情報（詳細には予約ユーザ情報）に基づき、複数の店舗それぞれについて、将来の各日時における、予約可能席の有無を示す予約可能席情報、及び、予約している予約ユーザを示す予約ユーザ情報を特定する。当該予約可能席情報及び予約ユーザ情報の特定は、管理部３３によって実行される第１処理である。上述したように、予約可能席情報（図３参照）には、各店舗における各時間帯について予約可能な席の情報が示されている。また、上述したように、登録用予約情報には、各店舗における予約ユーザ情報及び予約ユーザの予約日時が示されている。管理部３３は、予約可能席情報に基づいて、各店舗について、将来の各日時における予約可能席情報（予約可能席の有無）を特定する。また、管理部３３は、登録用予約情報の予約ユーザ情報及び予約ユーザの予約日時に基づいて、各店舗について、将来の各日時における予約ユーザ情報を特定する。
【0050】
管理部３３は、複数の店舗のうち、予約可能席情報において予約可能席が無い店舗をキャンセル待ち店舗として特定すると共に、予約可能席が有る店舗を予約可能店舗として特定する。管理部３３は、当該キャンセル待ち店舗及び予約可能店舗の特定を、将来の各日時（例えば、１時間単位で現時点から１週間～１か月分の各日時）について行う。そして、管理部３３は、予約ユーザ情報においてキャンセル待ち店舗の予約ユーザとして示されている複数のユーザをキャンセル待ち店舗ユーザとして特定する。当該キャンセル待ち店舗及び予約可能店舗の特定、並びに、キャンセル待ち店舗ユーザの特定は、管理部３３によって実行される第２処理である。キャンセル待ち店舗とは、複数の店舗のうちキャンセル待ちが発生している一又は複数（ここでは複数）の店舗である。予約可能店舗とは、複数の店舗のうち予約が可能な一又は複数（ここでは複数）の店舗である。キャンセル待ち店舗ユーザとは、キャンセル待ち店舗を予約している複数のユーザＵである。管理部３３は、特定したキャンセル待ち店舗及び予約可能店舗を示す店舗情報と、キャンセル待ち店舗ユーザを示すキャンセル待ち店舗ユーザ情報とを記憶部３２に出力する。
【0051】
なお、キャンセル待ち店舗、予約可能店舗、及びキャンセル待ち店舗ユーザの特定方法は、上記に限定されない。管理部３３は、記憶部３２に記憶されているキャンセル待ち予約情報（予約可能席情報及び予約ユーザ情報を考慮して生成された情報）を参照し、キャンセル待ち予約情報に含まれる一の「店舗」に示された店舗を、キャンセル待ち店舗として特定してもよい。管理部３３は、当該「店舗」に紐づけられた「ユーザ識別番号」に示されたユーザＵを、キャンセル待ち店舗ユーザとして特定してもよい。また、管理部３３は、記憶部３２に記憶されている店舗予約情報（予約可能席情報及び予約ユーザ情報を考慮して生成された情報）を参照し、キャンセル待ち予約情報に含まれる「店舗」及び「予約日時」と同じ「店舗」及び「予約日時」を含む店舗予約情報の「ユーザ識別番号」に示されたユーザＵも、キャンセル待ち店舗ユーザとして特定してもよい。
【0052】
管理部３３は、特定したキャンセル待ち店舗及び予約可能店舗を示す店舗情報と、キャンセル待ち店舗ユーザ情報とを第２取得部３４に出力する。
【0053】
また、管理部３３は、対象期間について、呼び込みメッセージの配信が行われたユーザＵ毎に、複数の店舗それぞれへの来店回数と、複数の店舗それぞれについての店舗割引券利用回数（店舗インセンティブ利用回数）と、複数の店舗全体への来店回数と、複数の店舗全体についての全体割引券利用回数（全体インセンティブ利用回数）とを更に特定する。対象期間は、現時点から予め定められた期間遡った時点までの期間であって、例えば、直近１ヶ月間である。管理部３３は、特定したユーザＵ毎の各情報を記憶部３２に出力する。
【0054】
店舗割引券利用回数は、各店舗についての、呼び込みメッセージの配信とともにユーザＵに付与された且つ店舗の利用に係る割引券の利用回数である。複数の店舗の全体の来店回数は、各店舗において対象期間の複数のユーザＵの来店回数を算出したとして、算出した来店回数のすべてを合計した場合の合計値である。全体割引券利用回数は、複数の店舗の全体についての、割引券の利用回数である。換言すれば、全体割引券利用回数は、まず、各店舗において対象期間の複数のユーザＵに利用された割引券の利用回数を算出したとして、算出した利用回数のすべてを合計した場合の合計値である。
【0055】
管理部３３は、例えば、呼び込み結果・ＦＢ情報を参照することにより、ユーザＵ毎の各店舗の来店回数、店舗割引券利用回数、複数の店舗の全体の来店回数、及び全体割引券利用回数を特定する。図１０に示される例では、管理部３３は、呼び込み結果・ＦＢ情報を参照し、ユーザ識別番号「１」のユーザＵについて、店舗Ａの来店回数を「２回」、店舗Ａの店舗割引券利用回数を「２回」、店舗Ｂの来店回数を「０回」、店舗Ｂの店舗割引券利用回数を「０回」と特定する。そして、管理部３３は、複数の店舗の全体（店舗Ａ，Ｂ）の来店回数を「２回」、及び全体割引券利用回数（店舗Ａ，Ｂの割引券利用回数の合計）を「２回」と特定する。なお、図１０に示される呼び込み結果・ＦＢ情報のユーザ識別番号「１」に関する情報は、一の対象期間内に取得されたものである。また、上記各情報の特定方法は特に限られず、管理部３３は、上記各情報を、案内情報に含まれる予約番号と、店舗予約情報に含まれる予約番号とを照合すること等によって特定してもよいし、ユーザＵが通信端末１０を介して入力した情報に基づき特定してもよい。管理部３３は、例えば、案内情報等に基づき、呼び込み配信によって付与された割引券以外の割引券の利用も考慮して上記各情報を特定してもよい。
【0056】
管理部３３は、上述した対象期間について、呼び込みメッセージの配信が行われたユーザＵ毎に、店舗利用平均額と、店舗付与平均額と、全体利用平均額と、全体付与平均額とを更に特定する。管理部３３は、特定したユーザＵ毎の各情報を記憶部３２に出力する。
【0057】
店舗利用平均額は、各店舗についての割引券の利用平均額である。店舗付与平均額は、各店舗についての、ユーザＵに付与された割引券の付与平均額である。全体利用平均額は、複数の店舗の全体についての割引券の利用平均額である。換言すれば、全体利用平均額は、対象期間内に各店舗において複数のユーザＵに利用された割引券の合計額を算出したとして、算出した合計額のすべてを合計した場合の合計値である。全体付与平均額は、複数の店舗の全体についての、割引券の付与平均額である。換言すれば、全体付与平均額は、対象期間内に各店舗において複数のユーザＵに付与された割引券の合計額を算出したとして、算出した合計額のすべてを合計した場合の合計値である。
【0058】
管理部３３は、例えば、割引券情報及び呼び込み結果・ＦＢ情報を参照することにより、ユーザＵ毎の店舗利用平均額、店舗付与平均額、全体利用平均額、及び全体付与平均額を特定する。
【0059】
図１０に示される例では、管理部３３は、割引券情報及び呼び込み結果・ＦＢ情報を参照し、ユーザ識別番号「１」のユーザＵについて、店舗Ａの店舗利用平均額及び店舗Ａの店舗付与平均額のそれぞれを、「ＸＸＸ円」と「ＲＲＲ円」とを加算した値を２で除算した額と特定し、店舗Ｂの店舗利用平均額を「０円」、及び店舗Ｂの店舗付与平均額を「ＱＱＱ円」と特定する。そして、管理部３３は、全体利用平均額（店舗Ａ，Ｂの割引券利用額の合計を２で除算した額）を、「ＸＸＸ円」と「ＲＲＲ円」とを加算した値を２で除算した額と特定し、全体付与平均額（店舗Ａ，Ｂの割引券付与額を３で除算した数）を「ＸＸＸ円」と「ＲＲＲ円」と「ＱＱＱ円」とを加算した値を３で除算した額と特定する。なお、上記各情報の特定方法は特に限られず、管理部３３は、上記各情報を、案内情報に含まれる予約番号と、店舗予約情報に含まれる予約番号と、管理用呼び込み情報に含まれる予約番号とを照合すること等によって特定してもよいし、ユーザＵが通信端末１０を介して入力した情報に基づき特定してもよい。管理部３３は、例えば、案内情報等に基づき、呼び込み配信によって付与された割引券以外の割引券の利用も考慮して上記各情報を特定してもよい。
【0060】
第２取得部３４は、記憶部３２から、呼び込み結果・ＦＢ情報、キャンセル待ち予約情報、及び店舗予約情報を取得する。これらの情報は、ユーザアクション情報である。ユーザアクション情報とは、複数の店舗を含んで構成されるコミュニティの各店舗からの呼び込みメッセージに応じて、当該コミュニティを利用する複数のユーザＵが来店に向けて起こしたアクションを示す情報である。なお、第２取得部３４は、ユーザアクション情報として、呼び込み結果・ＦＢ情報のみを取得してもよい。また、第２取得部３４は、管理部３３から、複数のキャンセル待ち店舗及び複数の予約可能店舗を示す店舗情報と、キャンセル待ち店舗を予約している複数のキャンセル待ち店舗ユーザを示すキャンセル待ち店舗ユーザ情報とを取得する。第２取得部３４は、呼び込み結果・ＦＢ情報、キャンセル待ち予約情報、及び店舗予約情報、及びキャンセル待ち店舗ユーザ情報を推定部３５に出力し、店舗情報及びキャンセル待ち店舗ユーザ情報を制御部３６に出力する。
【0061】
第２取得部３４は、対象期間について、呼び込みメッセージの配信が行われたユーザＵ毎に、各店舗の来店回数、店舗割引券利用回数、複数の店舗の全体の来店回数、全体割引券利用回数、店舗利用平均額、店舗付与平均額、全体利用平均額、及び全体付与平均額を記憶部３２から更に取得する。第２取得部３４は、取得した上記各情報を制御部３６に出力する。
【0062】
推定部３５は、第２取得部３４から取得した呼び込み結果・ＦＢ情報、キャンセル待ち予約情報、及び店舗予約情報に基づき、第２取得部３４から取得したキャンセル待ち店舗ユーザ情報に示された、複数のキャンセル待ち店舗ユーザのそれぞれの、コミュニティにおける嗜好度（こだわり度）を推定する。嗜好度が低いとはユーザＵのこだわり度が低いことを示しており、嗜好度が高いとはユーザＵのこだわり度が高いことを示している。本システムでは、店舗を予約しているユーザＵについて、嗜好度が低いユーザＵは店舗に対するこだわり度が低く予約変更等に比較的柔軟に対応するユーザＵであると判断し、嗜好度が高いユーザＵは店舗に対するこだわり度が高く予約変更等に比較的柔軟に対応しないユーザＵであると判断する。推定部３５は、上記嗜好度を推定する前段の処理として、呼び込み結果・ＦＢ情報及びキャンセル待ち予約情報に基づき、複数のキャンセル待ち店舗ユーザ毎に、来店に向けたアクションを起こしたアクション対象店舗を推定（特定）する。アクション対象店舗は、来店につながりやすいアクションをキャンセル待ち店舗ユーザが起こした店舗である。本実施形態では、アクション対象店舗として、第１アクション対象店舗、及び第２アクション対象店舗の２種類を推定する（詳細は後述）。上述した嗜好度は、複数の店舗に係る嗜好度であって、例えば、第１アクション対象店舗（アクション対象店舗）に対するこだわりの度合いを示す。すなわち、嗜好度の高さは、キャンセル待ち店舗ユーザが第１アクション対象店舗に行く可能性の高さを示す。推定部３５は、例えば１か月毎等、定期的に嗜好度を推定する。推定部３５は、推定された第１，２アクション対象店舗を示す情報及び嗜好度を、制御部３６に出力する。第１，２アクション対象店舗を示す情報及び嗜好度は、後述する平準化処理に用いられる。以下、基本的に、一のキャンセル待ち店舗ユーザについての上記各情報の推定に着目して説明する。
【0063】
まず、推定部３５は、例えば、呼び込み結果・ＦＢ情報を参照して、各キャンセル待ち店舗ユーザについて、第１，２アクション対象店舗を推定する。具体的には、推定部３５は、例えば対象期間（直近１ヶ月間）等、現時点から所定の時間遡った時点までの間において、予約の有無情報が「実施」であって且つ来店の有無情報が「来店」である店舗を第１アクション対象店舗であると推定し、予約状況確認情報が「開封」であって且つ来店の有無情報が「未来店」である店舗を、第２アクション対象店舗であると推定する。
【0064】
推定部３５は、呼び込み結果・ＦＢ情報を参照して、ＦＢ１（魅力）が所定の点数以上であって且つ来店の有無情報が「来店」である店舗を第２アクション対象店舗であると更に推定する。また、推定部３５は、キャンセル待ち予約情報に含まれる予約店舗を第１アクション対象店舗であると更に推定する。以上のように、推定部３５は、キャンセル待ち店舗ユーザ毎の第１，２アクション対象店舗を推定する。なお、第１，２アクション対象店舗候補の推定方法は、上記方法に限られず、例えば、推定部３５は、呼び込み結果・ＦＢ情報を参照して、対象期間において、呼び込み回数＝Ｘに対して予約の回数＝１である店舗を第１アクション対象店舗であるとし、呼び込み回数＝Ｙ（Ｙ＞Ｘ）に対して予約の回数＝１である店舗を第２アクション対象店舗であると推定してもよい。
【0065】
続いて、推定部３５は、キャンセル待ち店舗ユーザ毎の嗜好度を推定する。推定部３５は、例えば、以下のようにキャンセル待ち店舗ユーザ毎の嗜好度を算出する。まず、推定部３５は、下記式（１）で示される値Ｎ１、及び下記式（２）で示される値Ｎ２を算出する。
値Ｎ１＝（第１アクション対象店舗の数）÷（第１，２アクション対象店舗の合計数）…（１）
値Ｎ２＝（第１アクション対象店舗の来店回数）÷（第２アクション対象店舗の来店回数＋第１，２アクション対象店舗以外の店舗の来店回数）・・（２）
値Ｎ１＝（第１アクション対象店舗の数）÷（第１，２アクション対象店舗の合計数）…（１）
値Ｎ２＝（第１アクション対象店舗の来店回数）÷（第２アクション対象店舗の来店回数＋第１，２アクション対象店舗以外の店舗の来店回数）・・（２）
【0066】
推定部３５は、例えば、第２取得部３４から取得した店舗予約情報を参照して、対象期間における第１，２アクション対象店舗の来店回数、及び第１，２アクション対象店舗以外の店舗の来店回数を特定する。
【0067】
続いて、推定部３５は、値Ｎ１，Ｎ２に基づき、下記式（３）で示される嗜好度を算出する。
嗜好度＝値Ｎ１×値Ｎ２×１００…（３）
嗜好度＝値Ｎ１×値Ｎ２×１００…（３）
【0068】
以上のように、推定部３５は、キャンセル待ち店舗ユーザ毎の嗜好度を推定する。嗜好度の推定方法については、上記方法に限られず、例えば、推定部３５は、値Ｎ１及び値Ｎ２のそれぞれに重み付けをしてから嗜好度を算出してもよい。また、例えば、推定部３５は、値Ｎ１及び値Ｎ２のそれぞれの大きさに応じてランクを付与し、付与したランク同士と１００とを乗算して嗜好度を算出してもよい。推定部３５は、推定したキャンセル待ち店舗ユーザ毎の第１，２アクション対象店舗を示す情報、及び嗜好度を制御部３６に出力する。制御部３６は、上記各情報を含む店舗ステータス情報を生成し、生成した店舗ステータス情報を記憶部３２に出力する。
【0069】
図１１は、店舗ステータス情報の一例を示す図である。店舗ステータス情報は、ユーザ識別番号と、データ更新日と、第１アクション対象店舗情報と、第２アクション対象店舗情報と、嗜好度と、ユーザ情報とを含んでいる。ユーザ情報の詳細については後述する。
【0070】
制御部３６は、平準化処理、及びインセンティブ決定処理を行う。まず、制御部３６は、平準化処理として、複数のキャンセル待ち店舗ユーザについて、嗜好度が低いほどいずれかの予約可能店舗への予約変更の案内を受ける対象ユーザに選定されやすくなるように、一又は複数の対象ユーザを選定し、対象ユーザに対して案内メッセージを生成する。案内メッセージは、予約可能店舗への予約変更を案内するメッセージである。このとき、制御部３６は、複数のキャンセル待ち店舗ユーザについて、第１アクション対象店舗（アクション対象店舗）の数が多いほど、対象ユーザに選定されやすくなるように、対象ユーザを選定する。
【0071】
ここで、制御部３６による対象ユーザの選定方法の一例について説明する。まず、制御部３６は、キャンセル待ち店舗ユーザを、嗜好度が低い順に並べ替える。制御部３６は、嗜好度が同じ複数のキャンセル待ち店舗ユーザが存在する場合、当該複数のキャンセル待ち店舗ユーザを、第１アクション対象店舗の数が多い順に並べ替える。そして、制御部３６は、キャンセル待ちをしているユーザＵの数に応じて、対象ユーザを選定する。例えば、制御部３６は、キャンセル待ちをしているユーザＵの数が１人である場合、並び替え後の先頭のキャンセル待ち店舗ユーザを対象ユーザとして選定する。
【0072】
図１１に示される店舗ステータス情報の例では、制御部３６は、まず、各キャンセル待ち店舗ユーザの嗜好度を参照して、各キャンセル待ち店舗ユーザを、ユーザ識別番号「８」→「５，６」→「７」の順に並べ替える。そして、制御部３６は、同じ嗜好度を有するユーザ識別番号「５」のユーザＵの第１アクション対象店舗の数と、ユーザ識別番号「６」のユーザＵの第１アクション対象店舗の数とを比較し、「６」→「５」の順に並べ替える。また、図１１に示される例では、キャンセル待ちをしているユーザＵの数が１人である。したがって、制御部３６は、先頭からユーザ識別番号「８」→「６」→「５」→「７」の順に並べ替えられたユーザＵのうち、ユーザ識別番号「８」のユーザＵを対象ユーザとして選定する。なお、対象ユーザの数は上記例に限られず、例えば、制御部３６は、ユーザ識別番号「８」のユーザＵに加えて、ユーザ識別番号「８」の次である「６」のユーザＵも対象ユーザとして選定してもよいし、キャンセル待ちをしているユーザＵを除いたキャンセル待ち店舗ユーザの中から対象ユーザを選定してもよい。
【0073】
制御部３６は、選定した対象ユーザに対して送信するための案内メッセージを生成する。本実施形態では、制御部３６は、推奨店舗を特定し、対象ユーザに、案内メッセージとして、推奨店舗への予約変更を案内するメッセ―ジを生成する。推奨店舗は、例えば、複数の店舗のうち、対象ユーザの第２アクション対象店舗（アクション対象店舗）であって且つ予約可能店舗に該当する店舗である。なお、推奨店舗は、上記例に限られず、例えば、対象ユーザの過去の来店回数が最も多い店舗且つ予約可能店舗であってもよい。なお、制御部３６は、推奨店舗が存在しない場合、予約可能店舗のいずれかの予約変更を案内する案内メッセージを生成する。また、本実施形態では、制御部３６は、対象ユーザに対して、キャンセル待ち店舗から予約可能店舗に移動した場合に割引券（インセンティブ）を付与する旨の情報を含んだ案内メッセ―ジを生成する。制御部３６は、生成した案内メッセージを出力部３７に出力する。
【0074】
次に、制御部３６が行うインセンティブ決定処理について説明する。制御部３６は、まず、第２取得部３４から取得した各店舗の来店回数及び店舗割引券利用回数に基づき、ユーザＵ毎に、下記式（３）で示される値Ｎ３（店舗の来店回数に対する店舗割引券利用回数の割合）を算出する。
値Ｎ３＝（店舗割引券利用回数÷店舗の来店回数）×１００…（３）
値Ｎ３＝（店舗割引券利用回数÷店舗の来店回数）×１００…（３）
【0075】
制御部３６は、第２取得部３４から取得した複数の店舗の全体の来店回数及び全体割引券利用回数に基づき、ユーザＵ毎に、下記式（４）で示される値Ｎ４（複数の店舗の全体の来店回数に対する全体割引券利用回数の割合）を算出する。
値Ｎ４＝（全体割引券利用回数÷複数の店舗の全体の来店回数）×１００…（４）
値Ｎ４＝（全体割引券利用回数÷複数の店舗の全体の来店回数）×１００…（４）
【0076】
そして、制御部３６は、値Ｎ３及び値Ｎ４に基づき算出された第１対象値（対象値）が所定の第１閾値以上であるユーザＵを、インセンティブ必要ユーザとして選定し、第１対象値が第１閾値未満のユーザＵを、インセンティブ不要ユーザとして選定する。一例として、第１対象値は、値Ｎ３及び値Ｎ４の平均値であって、第１閾値は、５０％である。第１対象値及び第１閾値は上記例に限られない。
【0077】
また、制御部３６は、来店ＦＢ情報、及び呼び込み結果・ＦＢ情報を参照し、来店ＦＢ情報に含まれるＦＢ１（満足度）が所定値よりも低く且つＦＢ２（理由）が「割引額に不満」であるユーザＵ、及び呼び込み結果・ＦＢ情報に含まれるＦＢ１（魅力）が低く且つＦＢ２（理由）が「割引額に不満」が記載されているユーザＵを、インセンティブ必要ユーザとして選定してもよい。また、制御部３６は、来店ＦＢ情報に含まれるＦＢ１（満足度）が所定値よりも高く且つＦＢ２（理由）が「メニュー、お店の雰囲気」であるユーザＵ、及び呼び込み結果・ＦＢ情報に含まれるＦＢ１（魅力）が高く且つＦＢ２（理由）が「メニュー、お店の雰囲気」であるユーザＵを、インセンティブ不要ユーザとして選定してもよい。
【0078】
次に、制御部３６は、第２取得部３４から取得した店舗利用平均額、及び店舗付与平均額に基づき、ユーザＵ毎に、下記式（５）で示される値Ｎ５（店舗付与平均額に対する店舗利用平均額の割合）を算出する。
値Ｎ５＝（店舗利用平均額÷店舗付与平均額）×１００…（５）
値Ｎ５＝（店舗利用平均額÷店舗付与平均額）×１００…（５）
【0079】
制御部３６は、第２取得部３４から取得した全体利用平均額及び全体付与平均額に基づき、ユーザＵ毎に、下記式（６）で示される値Ｎ６（全体付与平均額に対する前記全体利用平均額の割合）を算出する。
値Ｎ６＝（全体利用平均額÷全体付与平均額）×１００…（６）
値Ｎ６＝（全体利用平均額÷全体付与平均額）×１００…（６）
【0080】
そして、制御部３６は、値Ｎ５及び値Ｎ６に基づき算出された第２対象値が、第２閾値以上のインセンティブ必要ユーザを、高インセンティブ必要ユーザとして選定し、第２対象値が第２閾値未満のインセンティブ必要ユーザを、低インセンティブ許容ユーザとして更に選定する。一例として、第２対象値は、値Ｎ５及び値Ｎ６の平均値であって、第２閾値は、１００％である。第２対象値及び第２閾値は上記例に限られない。以上のように、制御部３６は、値Ｎ５及び値Ｎ６が高いほど高くなるように、インセンティブ必要ユーザに対する割引券の割引の度合いを決定する。
【0081】
制御部３６は、高インセンティブ必要ユーザ、低インセンティブ許容ユーザ、及びインセンティブ不要ユーザを示すユーザ情報（情報）を、管理部３３に出力する。管理部３３は、制御部３６から受け取ったユーザ情報に基づいて、割引券をユーザＵに配信する。具体的には、例えば、管理部３３は、割引券情報を参照し、各ユーザＵの基礎情報と、制御部３６から受け取ったユーザ情報とに対応する割引券情報が示す割引券を、ユーザＵに配信する。なお、例えば、管理部３３は、ユーザ情報を参照して、高インセンティブ必要ユーザ及び低インセンティブ許容ユーザにのみ、割引券を付与して呼び込み配信を行ってもよい。また、管理部３３は、ユーザ情報を参照して、高インセンティブ必要ユーザ及び低インセンティブ許容ユーザには割引券を付与して呼び込み配信を行い、インセンティブ不要ユーザには割引券を付与せずに呼び込み配信を行ってもよい。このようなユーザのカテゴリに応じた呼び込み配信の使い分けは、例えば、管理部３３によって決定されてもよいし、また例えば、店舗管理端末２０から受け取る登録用割引券情報に含まれる、使い分けを示す情報に基づいて決定されてもよい。
【0082】
制御部３６は、高インセンティブ必要ユーザ、低インセンティブ許容ユーザ、及びインセンティブ不要ユーザの選定に関する処理を、例えば１か月間等、所定の間隔ごとに行う。また、制御部３６は、各ユーザへの割引券の割引の度合いを提案する提案情報を、ユーザ情報とともに生成してもよい。例えば、制御部３６は、低インセンティブ許容ユーザに対する割引券の割引額を、５回の割引券の付与回数のうち、４回は高インセンティブ必要ユーザに対する割引額よりも低く設定し、１回は高インセンティブ必要ユーザと同じ割引額に設定する旨の提案情報を生成する。制御部３６は、生成した提案情報を出力部３７に出力してもよい。
【0083】
また、制御部３６は、上記３つの種類のユーザに加え、第１確認ユーザ及び第２確認ユーザを更に選定してもよい。第１確認ユーザは、高インセンティブ必要ユーザのカテゴリに変更される可能性が高い低インセンティブ許容ユーザである。第２確認ユーザは、低インセンティブ許容ユーザのカテゴリに変更される可能性が高いインセンティブ不要ユーザである。制御部３６は、例えば、各低インセンティブ許容ユーザについて、当月の第２対象値と先月の第２対象値との差が所定の第３閾値以上である低インセンティブ許容ユーザを第１確認ユーザとして選定する。また、制御部３６は、各インセンティブ不要ユーザについて、当月の第２対象値と先月の第２対象値との差が所定の第４閾値以上であるインセンティブ不要ユーザを第２確認ユーザとして選定する。制御部３６は、例えば、第１確認ユーザ及び第２確認ユーザに対する割引券の割引額を、５回の割引券の付与回数のうち、３回は高インセンティブ必要ユーザに対する割引額よりも低く設定し、２回は高インセンティブ必要ユーザと同じ割引額に設定する旨の提案情報を生成する。
【0084】
出力部３７は、制御部３６から取得した案内メッセージを、対象ユーザによる閲覧のために、対象ユーザが有する通信端末１０に出力する。また、出力部３７は、制御部３６から取得した提案情報を、店舗による閲覧のために、店舗管理端末２０に出力してもよい。
【0085】
【0086】
図１２に示されるように、情報処理システム１では、コミュニティサーバ３０において、通信端末１０から、登録用予約情報、呼び込みＦＢ情報、来店ＦＢ情報、ユーザＵの基礎情報、及びアクション情報が取得され、店舗管理端末２０から、案内情報、予約可能席情報、登録用割引券情報、及び登録用呼び込み情報が取得され、データ３００として記憶部３２に記憶される（ステップＳ１１）。
【0087】
続いて、コミュニティサーバ３０において、ステップＳ１１で取得された登録用予約情報、呼び込みＦＢ情報、案内情報、予約可能席情報、登録用割引券情報、及び登録用呼び込み情報に基づき、複数の店舗の店舗予約情報、キャンセル待ち予約情報、割引券情報、管理用呼び込み情報、及び呼び込み結果・ＦＢ情報が生成される（ステップＳ１２）。続いて、コミュニティサーバ３０において、ステップＳ１２で生成された各情報が管理され、複数のユーザＵへの呼び込みメッセージ及び割引券の配信が行われる（ステップＳ１３）。
【0088】
続いて、コミュニティサーバ３０において、ステップＳ１２で生成された割引券情報、管理用呼び込み情報、店舗予約情報、キャンセル待ち予約情報、及び呼び込み結果・ＦＢ情報がデータ３００として記憶される（ステップＳ１４）。
【0089】
続いて、コミュニティサーバ３０において、キャンセル待ち店舗、予約可能店舗、及びキャンセル待ち店舗ユーザが特定（取得）される（ステップＳ１５）。
【0090】
続いて、コミュニティサーバ３０において、呼び込み結果・ＦＢ情報及びキャンセル待ち予約情報に基づき、キャンセル待ち店舗ユーザ毎に、アクション対象店舗、及びコミュニティにおける嗜好度が推定される（ステップＳ１６）。
【0091】
続いて、コミュニティサーバ３０において、ステップＳ１６で推定された嗜好度に応じて、複数のキャンセル待ち店舗ユーザの中から、予約可能店舗へと予約を変更しやすい対象ユーザが選定され（ステップＳ１７）、対象ユーザに対して案内メッセージが生成され、生成された案内メッセージが対象ユーザの閲覧のために出力される（ステップＳ１８）。これにより、案内メッセージが通信端末１０によって取得されると、通信端末１０が有する画面上に案内メッセージが表示される。
【0092】
【0093】
まず、情報処理システム１では、コミュニティサーバ３０において、対象期間について、ユーザＵ毎に、各店舗の来店回数、店舗割引券利用回数、複数の店舗の全体の来店回数、全体割引券利用回数、店舗利用平均額、店舗付与平均額、全体利用平均額、及び全体付与平均額が特定（取得）される（ステップＳ２１）。
【0094】
続いて、コミュニティサーバ３０において、ステップＳ２１で取得された各店舗の来店回数及び店舗割引券利用回数に基づき、ユーザＵ毎に、値Ｎ３が算出され、ステップＳ２１で取得された複数の店舗の全体の来店回数及び全体割引券利用回数に基づき、値Ｎ４が算出される（ステップＳ２２）。
【0095】
続いて、コミュニティサーバ３０において、ステップＳ２２で算出された値Ｎ３及び値Ｎ４に基づき算出された第１対象値が所定の第１閾値以上であるユーザＵがインセンティブ必要ユーザとして選定され、第１対象値が第１閾値未満のユーザＵがインセンティブ不要ユーザとして選定される（ステップＳ２３）。
【0096】
続いて、コミュニティサーバ３０において、ステップＳ２１で取得された店舗利用平均額、及び店舗付与平均額に基づき、ユーザＵ毎に、値Ｎ５が算出され、ステップＳ２１で取得された全体利用平均額及び全体付与平均額に基づき、値Ｎ６が算出される（ステップＳ２４）。
【0097】
続いて、コミュニティサーバ３０において、ステップＳ２４で算出された値Ｎ５及び値Ｎ６に基づき算出された第２対象値が第２閾値以上のインセンティブ必要ユーザが、高インセンティブ必要ユーザとして選定され、第２対象値が第２閾値未満のインセンティブ必要ユーザが、低インセンティブ許容ユーザとして選定される（ステップＳ２５）。その後、コミュニティサーバ３０において、高インセンティブ必要ユーザ、低インセンティブ許容ユーザ、及びインセンティブ不要ユーザを示すユーザ情報、及びユーザＵの基礎情報に基づいて、割引券がユーザＵに配信される。
【0098】
次に、本実施形態に係る情報処理システム１の作用効果について説明する。
【0099】
情報処理システム１では、ユーザアクション情報（呼び込み結果・ＦＢ情報、キャンセル待ち予約情報、及び店舗予約情報）に基づき、複数のキャンセル待ち店舗ユーザそれぞれの、コミュニティにおける嗜好度が推定される。ユーザアクション情報は、複数の店舗を含んで構成されるコミュニティの各店舗からの呼び込みメッセージ（呼び込み情報）に応じてユーザＵが来店に向けて起こしたアクションを示す。そして、情報処理システム１では、複数のキャンセル待ち店舗ユーザについて、嗜好度が低いほどいずれかの予約可能店舗への予約変更の案内を受ける対象ユーザに選定されやすくなるように、一又は複数の対象ユーザが選定され、いずれかの予約可能店舗への予約の変更を案内する案内メッセージが生成され、当該案内メッセージが、上記対象ユーザによる閲覧のために出力される。
【0100】
このように、店舗からの呼び込みメッセージに応じてユーザＵが来店に向けて実際に起こしたアクション（予約等）が考慮されて、各ユーザＵについてコミュニティにおける嗜好度（こだわり度）が推定されることにより、コミュニティに対するユーザＵの嗜好度を高精度に推定することができる。そして、高精度に推定された嗜好度が低い（すなわち、店舗に対するこだわりが低い）ユーザＵほど、予約変更の案内を受け付ける対象ユーザに選定されやすくすることにより、キャンセル待ち店舗ユーザに対する予約可能店舗への予約の変更が効果的に（高確率で）促される。その結果、混雑によりユーザＵを受け入れきれないキャンセル待ち店舗から、ユーザＵの受け入れが可能な予約可能店舗へのユーザの移動の可能性を高めることができるので、コミュニティ全体の混雑度の平準化を図ることができる。これにより、例えば、キャンセル待ちとなっておりそのままでは売上に寄与しなかったユーザＵが、予約可能店舗の売り上げに寄与することとなり、コミュニティ全体としての売上を向上させることができる。以上のように、本実施形態に係る情報処理システム１によれば、コミュニティ全体の売り上げの最適化に適したマーケティングを行うことができる。
【0101】
管理部３３は、複数の店舗それぞれについて、将来の各日時における、予約可能席の有無を示す予約可能席情報、及び、予約している予約ユーザを示す予約ユーザ情報を特定する処理（第１処理）と、複数の店舗のうち、予約可能席情報において予約可能席が無い店舗をキャンセル待ち店舗として特定すると共に予約可能席が有る店舗を予約可能店舗として特定し、予約ユーザ情報においてキャンセル待ち店舗の予約ユーザとして示されている複数のユーザＵをキャンセル待ち店舗ユーザとして特定する処理（第２処理）と、を実行し、第２取得部３４は、管理部３３が特定したキャンセル待ち店舗及び予約可能店舗に基づき店舗情報を取得し、管理部３３が特定した複数のキャンセル待ち店舗ユーザに基づきキャンセル待ち店舗ユーザ情報を取得する。このような構成によれば、複数の店舗のそれぞれについて将来の各日時における予約の状況が把握可能な予約可能席情報と、各ユーザＵが複数の店舗のいずれを予約しているかを把握可能な予約ユーザ情報が用いられるため、適切且つ容易に、キャンセル待ち店舗、予約可能店舗、及びキャンセル待ち店舗ユーザを特定することができる。
【0102】
推定部３５は、ユーザアクション情報に基づき、複数のキャンセル待ち店舗ユーザ毎に、来店に向けたアクションを起こしたアクション対象店舗を特定し、制御部３６は、対象ユーザのアクション対象店舗であって且つ予約可能店舗である推奨店舗を特定し、対象ユーザに対して、推奨店舗への予約変更を案内する案内メッセ―ジを生成する。この構成によれば、対象ユーザが好んでいる店舗への予約変更を対象ユーザに案内するため、対象ユーザが予約店舗に予約変更する可能性を高めることができる。
【0103】
制御部３６は、複数のキャンセル待ち店舗ユーザについて、アクション対象店舗の数が多いほど、対象ユーザに選定されやすくなるように、対象ユーザを選定する。
【0104】
一般的に、来店につながりやすいアクションをユーザＵが起こした対象の店舗（アクション対象店舗）は、ユーザＵの好みの店舗といえ、コミュニティ内で好みの店舗の数が多いユーザＵほど、一の店舗に対するこだわりは少ないといえる。この情報処理システム１によれば、第１アクション対象店舗の数が多いユーザＵほど対象ユーザとして選ばれやすくなるため、キャンセル待ち店舗を予約している複数のユーザＵの中でも、こだわりが弱い（すなわち、同一のコミュニティ内の他の店舗へ予約変更しやすい）ユーザＵを対象ユーザとして選定することができる。
【0105】
制御部３６は、対象ユーザに対して、キャンセル待ち店舗から予約可能店舗に移動した場合にインセンティブを付与する旨の情報を含んだ案内メッセ―ジを生成する。この構成により、対象ユーザが予約可能店舗に予約変更する可能性をより一層高めることができる。
【0106】
管理部３３は、割引券（店舗の利用に係るインセンティブ）をユーザＵに配信（付与）し、第２取得部３４は、現時点から予め定められた期間遡った時点までの対象期間について、呼び込みメッセージの配信が行われたユーザＵ毎に、複数の店舗それぞれへの来店回数と、複数の店舗それぞれについての店舗インセンティブ利用回数と、複数の店舗全体への来店回数と、複数の店舗全体についての全体インセンティブ利用回数と、を更に取得し、制御部３６は、ユーザＵ毎に、複数の店舗に含まれる各店舗への来店回数に対する店舗インセンティブ利用回数の割合、及び複数の店舗全体への来店回数に対する全体インセンティブ利用回数の割合を算出し、店舗インセンティブ利用回数の割合、及び全体インセンティブ利用回数の割合に基づき算出された第１対象値が第１閾値以上であるユーザＵをインセンティブ必要ユーザとして選定し、第１対象値が第１閾値未満であるユーザＵをインセンティブ不要ユーザとして選定し、管理部３３は、インセンティブ必要ユーザ、及びインセンティブ不要ユーザを示すユーザ情報に基づいて、割引券をユーザＵに配信（付与）する。
【0107】
この構成により、例えば、複数のユーザＵのそれぞれに対して割引券を付与するか否かの指標を自動的に決定することができるため、複数の店舗がマーケティングを行う負担を軽減することができる。
【0108】
第２取得部３４は、対象期間について、ユーザＵ毎に、複数の店舗のそれぞれについての、店舗利用平均額、及び店舗付与平均額と、複数の店舗の全体についての、全体利用平均額及び全体付与平均額と、を更に取得し、制御部３６は、ユーザＵ毎に、各店舗についての店舗付与平均額に対する店舗利用平均額の割合、及び全体付与平均額に対する全体利用平均額の割合を算出し、各店舗についての店舗付与平均額に対する店舗利用平均額の割合、及び全体付与平均額に対する全体利用平均額の割合に基づき算出された第２対象値が第２閾値以上であるインセンティブ必要ユーザを、高インセンティブ必要ユーザとして更に選定し、第２対象値が第２閾値未満であるインセンティブ必要ユーザを、低インセンティブ許容ユーザとして更に選定する。
【0109】
一般的に、割引券を多用しているユーザＵが店舗に来店する理由は、割引券が付与されているためである可能性が高い。この情報処理システム１によれば、コミュニティ内の各店舗及びコミュニティ全体のそれぞれにおける割引券の利用の割合が考慮されて、割引券の割引の度合いを適切に決定できる結果、コミュニティ内の複数の店舗のマーケティング負担を軽減することができる。具体的には、例えば、割引券を理由に店舗に来店するユーザＵに対しては割引率が高い割引券を付与し、他の理由により店舗に来店するユーザＵに対しては割引率が低い割引券又は割引券を付与しない旨が情報処理システム１により自動的に決定されてユーザＵに割引券が配信されるので、適正な割引券を各ユーザＵに付与することができる。
【0110】
次に、情報処理システム１に含まれた通信端末１０、店舗管理端末２０、及びコミュニティサーバ３０のハードウェア構成について、図１４を参照して説明する。上述の通信端末１０、店舗管理端末２０、及びコミュニティサーバ３０は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。
【0111】
なお、以下の説明では、「装置」という文言は、回路、デバイス、及びユニット等に読み替えることができる。通信端末１０、店舗管理端末２０、及びコミュニティサーバ３０のハードウェア構成は、図に示された各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【0112】
通信端末１０、店舗管理端末２０、及びコミュニティサーバ３０における各機能は、プロセッサ１００１及びメモリ１００２等のハードウェア上に所定のソフトウェア（プログラム）を読み込ませることによって、プロセッサ１００１が演算を行い、通信装置１００４による通信を制御したり、メモリ１００２及びストレージ１００３におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現される。
【0113】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、及びレジスタ等を含む中央処理装置（ＣＰＵ：Central Processing Unit）によって構成されてもよい。例えば、上述の通信端末１０、店舗管理端末２０、及びコミュニティサーバ３０の各機能は、プロセッサ１００１によって実現されてもよい。
【0114】
また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール、及びデータ等を、ストレージ１００３及び通信装置１００４の少なくとも一方からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態において説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、通信端末１０、店舗管理端末２０、及びコミュニティサーバ３０の各機能は、メモリ１００２に格納され、プロセッサ１００１において動作する制御プログラムによって実現されてもよい。上述の各種処理は、１つのプロセッサ１００１によって実行される旨を説明してきたが、２以上のプロセッサ１００１によって同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップによって実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されてもよい。
【0115】
メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＲＡＭ（Random Access Memory）等の少なくとも１つによって構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）等と呼ばれてもよい。メモリ１００２は、本開示の一実施形態に係る提案方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュール等を保存できる。
【0116】
ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ－ＲＯＭ（Compact Disc ＲＯＭ）等の光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ－ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップ等の少なくとも１つによって構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及びストレージ１００３の少なくとも一方を含むデータベース、サーバ、その他の適切な媒体であってもよい。
【0117】
通信装置１００４は、有線ネットワーク及び無線ネットワークの少なくとも一方を介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュール等ともいう。通信装置１００４は、例えば周波数分割複信（ＦＤＤ：Frequency Division Duplex）及び時分割複信（ＴＤＤ：Time Division Duplex）の少なくとも一方を実現するために、高周波スイッチ、デュプレクサ、フィルタ、周波数シンセサイザ等を含んで構成されてもよい。例えば、上述の第１取得部３１、及び出力部３７等は、通信装置１００４によって実現されてもよい。
【0118】
入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサ等）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、ＬＥＤランプ等）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。
【0119】
また、プロセッサ１００１及びメモリ１００２等の各装置は、情報を通信するためのバス１００７によって接続される。バス１００７は、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。
【0120】
また、通信端末１０、店舗管理端末２０、及びコミュニティサーバ３０は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つを用いて実装されてもよい。
【0121】
以上、本実施形態について詳細に説明したが、当業者にとっては、本実施形態が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本実施形態は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本実施形態に対して何ら制限的な意味を有するものではない。
【0122】
上記実施形態では、コミュニティサーバ３０が、上記各機能を有している構成を例示した。しかしながら、情報処理システム１では、例えば、他のサーバが各機能的構成要素の一部あるいは全部を備えていてもよく、また、例えば、通信端末１０及び店舗管理端末２０が各機能的構成要素の一部を備えていてもよい。一例として、第１取得部３１及び管理部３３は、他のサーバが備えていてもよい。また、コミュニティサーバ３０は、インセンティブ決定処理を行わなくてもよい。
【0123】
コミュニティサーバ３０は、物理的又は論理的に結合した１つの装置によって構成されていてもよく、互いに物理的又は論理的に分離している複数の装置によって構成されてもよい。例えば、コミュニティサーバ３０は、クラウドコンピューティングのようにネットワーク上に分散された複数のコンピュータによって実現されてもよい。以上のように、コミュニティサーバ３０の構成は、コミュニティサーバ３０の機能を実現し得るいかなる構成をも含み得る。
【0124】
ユーザアクション情報は、上記実施形態に限られず、複数の店舗を含むコミュニティを利用するユーザＵ毎の、ユーザＵが受信した複数の店舗の呼び込み情報に応じてユーザＵが来店に向けて起こしたアクションを示す情報であればよい。例えば、ユーザアクション情報は、登録用予約情報、呼び込みＦＢ情報、来店ＦＢ情報、及びアクション情報であってもよい。
【0125】
案内メッセージには、割引券を付与する旨を含んでいなくてもよい。また、インセンティブは、例えば、複数の店舗で利用可能なポイント、及び優待券等、割引券以外であってもよい。また、上記実施形態では、管理部３３が、第１処理及び第２処理を行い、割引券をユーザＵに配信する構成を例示した。しかしながら、情報処理システム１では、例えば、コミュニティサーバ３０が、第１処理及び第２処理を行う特定部と、インセンティブをユーザＵに付与するインセンティブ付与部とを備えていてもよい。
【0126】
なお、上記実施形態の説明に用いられたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。また、各機能ブロックの実現方法は特に限定されない。すなわち、各機能ブロックは、物理的又は論理的に結合した１つの装置を用いて実現されてもよいし、物理的又は論理的に分離した２つ以上の装置を直接的又は間接的に（例えば、有線、無線等を用いて）接続し、これら複数の装置を用いて実現されてもよい。機能ブロックは、上記１つの装置又は上記複数の装置にソフトウェアを組み合わせて実現されてもよい。
【0127】
機能には、判断、決定、判定、計算、算出、処理、導出、調査、探索、確認、受信、送信、出力、アクセス、解決、選択、選定、確立、比較、想定、期待、見做し、報知（broadcasting）、通知（notifying）、通信（communicating）、転送（forwarding）、構成（configuring）、再構成（reconfiguring）、割り当て（allocating、mapping）、及び割り振り（assigning）等があるが、これらの機能に限られない。たとえば、送信を機能させる機能ブロック（構成部）は、送信部（transmitting unit）又は送信機（transmitter）と呼称される。いずれも、上述したとおり、実現方法は特に限定されない。
【0128】
情報の通知は、本開示において説明した態様／実施形態に限られず、他の方法を用いて行われてもよい。
【0129】
本開示において説明した各態様／実施形態の処理手順、シーケンス、及びフローチャート等は、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明された方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【0130】
情報等は、上位レイヤ（又は下位レイヤ）から下位レイヤ（又は上位レイヤ）へ出力され得る。情報等は、複数のネットワークノードを介して入出力されてもよい。
【0131】
入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルを用いて管理されてもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
【0132】
判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：true又はfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。
【0133】
本開示において説明した各態様／実施形態は単独で用いられてもよいし、組み合わせて用いられてもよいし、実行に伴って切り替えて用いられてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的な通知に限られず、暗黙的に（例えば、当該所定の情報の通知を行わないことによって）行われてもよい。
【0134】
以上、本開示について詳細に説明したが、当業者にとっては、本開示が本開示中に説明した実施形態に限定されないということは明らかである。本開示は、請求の範囲の記載により定まる本開示の趣旨及び範囲を逸脱することなく修正及び変更態様として実施できる。したがって、本開示の記載は、例示説明を目的とし、本開示に対して何ら制限的な意味を有しない。
【0135】
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能等を意味するよう広く解釈されるべきである。
【0136】
また、ソフトウェア、命令、情報等は、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術（同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ：Digital Subscriber Line）等）及び無線技術（赤外線、マイクロ波等）の少なくとも一方を使用してウェブサイト、コミュニティサーバ３０、又は他のリモートソースから送信される場合、これらの有線技術及び無線技術の少なくとも一方は、伝送媒体の定義内に含まれる。
【0137】
本開示において説明した情報、及び信号等は、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップ等は、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【0138】
なお、本開示において説明した用語及び本開示の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えられてもよい。
【0139】
本開示において使用される「システム」及び「ネットワーク」という用語は、互換的に使用される。
【0140】
また、本開示において説明された情報、パラメータ等は、絶対値を用いて表されてもよいし、所定の値からの相対値を用いて表されてもよいし、対応する別の情報を用いて表されてもよい。
【0141】
上述したパラメータに使用される名称はいかなる点においても限定的な名称ではない。さらに、これらのパラメータを使用する数式等は、本開示で明示的に開示したものと異なる場合もある。
【0142】
本開示で使用する「判断（determining）」、及び「決定（determining）」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定（judging）、計算（calculating）、算出（computing）、処理（processing）、導出（deriving）、調査（investigating）、探索（looking up、search、inquiry）（例えば、テーブル、データベース又は別のデータ構造での探索）、確認（ascertaining）した事を「判断」「決定」したとみなす事等を含み得る。また、「判断」、「決定」は、受信（receiving）（例えば、情報を受信すること）、送信（transmitting）（例えば、情報を送信すること）、入力（input）、出力（output）、アクセス（accessing）（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事等を含み得る。また、「判断」、「決定」は、解決（resolving）、選択（selecting）、選定（choosing）、確立（establishing）、比較（comparing）等した事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。また、「判断（決定）」は、「想定する（assuming）」、「期待する（expecting）」、又は「みなす（considering）」等で読み替えられてもよい。
【0143】
「接続された（connected）」、「結合された（coupled）」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に一又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。例えば、「接続」は「アクセス」で読み替えられてもよい。本開示で使用する場合、２つの要素は、一又はそれ以上の電線、ケーブル及びプリント電気接続の少なくとも一つを用いて、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギー等を用いて、互いに「接続」又は「結合」されると考えることができる。
【0144】
本開示において使用する「に基づき」という記載は、別段に明記されていない限り、「のみに基づき」を意味しない。言い換えれば、「に基づき」という記載は、「のみに基づき」と「に少なくとも基づき」の両方を意味する。
【0145】
本開示において使用する「第１の」、「第２の」等の呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定しない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本開示において使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみが採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。
【0146】
上記の各装置の構成における「部」は、「回路」、又は「デバイス」等に置き換えられてもよい。
【0147】
本開示において、「含む（include）」、「含んでいる（including）」、及びそれらの変形が使用されている場合、これらの用語は、用語「備える（comprising）」と同様に、包括的であることが意図される。さらに、本開示において使用されている用語「又は（or）」は、排他的論理和ではないことが意図される。
【0148】
本開示において、例えば、英語でのa, an及びtheのように、翻訳により冠詞が追加された場合、本開示は、これらの冠詞の後に続く名詞が複数形であることを含んでもよい。
【0149】
本開示において、「ＡとＢが異なる」という用語は、「ＡとＢが互いに異なる」ことを意味してもよい。なお、当該用語は、「ＡとＢがそれぞれＣと異なる」ことを意味してもよい。「離れる」、及び「結合される」等の用語も、「異なる」と同様に解釈されてもよい。
【符号の説明】
【0150】
１…情報処理システム、３３…管理部（特定部、インセンティブ付与部）、３４…第２取得部（取得部）、３５…推定部、３６…制御部、３７…出力部、Ｕ…ユーザ。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】