特許 7520097 判定装置、判定方法および判定プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-07-11

(45)【発行日】2024-07-22

(54)【発明の名称】判定装置、判定方法および判定プログラム

(51)【国際特許分類】

   G06F 16/9535 20190101AFI20240712BHJP

   G06Q 50/10 20120101ALI20240712BHJP

【ＦＩ】

G06F16/9535

G06Q50/10

【請求項の数】 13

(21)【出願番号】P 2022203327

(22)【出願日】2022-12-20

(65)【公開番号】P2024088250

(43)【公開日】2024-07-02

【審査請求日】2023-01-13

(73)【特許権者】

【識別番号】500257300

【氏名又は名称】ＬＩＮＥヤフー株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】檀上 周作

(72)【発明者】

【氏名】福山 怜史

【審査官】三橋 竜太郎

(56)【参考文献】

【文献】特開２０１３－２３２１０８（ＪＰ，Ａ）

【文献】特開２０２１－０５６９１６（ＪＰ，Ａ）

【文献】特開２０２０－１５５１４１（ＪＰ，Ａ）

【文献】特開２０２０－０２４６７４（ＪＰ，Ａ）

【文献】特表２０２２－５３８７０２（ＪＰ，Ａ）

【文献】特開２０２２－０８０９１１（ＪＰ，Ａ）

【文献】国際公開第２０２２／０７０９０８（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

Ｇ０６Ｑ ５０／１０

(57)【特許請求の範囲】

【請求項1】

検索対象からタグ候補を抽出する抽出部と、
前記抽出部によって抽出された前記タグ候補に対応する利用者の行動履歴に基づいて前記タグ候補の検索に関する周期性の有無を推定する推定部と、
前記推定部によって前記周期性が有ると判定された前記タグ候補に対して、前記タグ候補を検索時に用いるタグとして採用するか否かを判定する判定部と
を備えることを特徴とする判定装置。

【請求項2】

前記判定部は、
判定対象となる期間にピークを迎える前記タグ候補を前記タグとして採用すると判定すること
を特徴とする請求項１に記載の判定装置。

【請求項3】

前記推定部は、
類似する他の前記タグ候補の周期性に基づいて前記タグ候補の周期性の有無を推定すること
を特徴とする請求項１に記載の判定装置。

【請求項4】

前記タグとして採用すると判定された前記タグ候補を利用者による検索時に提案する提案部
を備えることを特徴とする請求項１に記載の判定装置。

【請求項5】

前記タグとして採用すると判定された前記タグ候補を用いて検索が行われた場合に、当該タグ候補に対応する前記検索対象を含む検索結果を提供する提供部
を備えることを特徴とする請求項１に記載の判定装置。

【請求項6】

前記推定部は、
前記タグ候補から前記検索対象が閲覧された閲覧履歴に基づいて前記周期性の有無を推定すること
を特徴とする請求項１に記載の判定装置。

【請求項7】

前記抽出部は、
前記検索対象に関する投稿情報から前記タグ候補を抽出すること
を特徴とする請求項１に記載の判定装置。

【請求項8】

前記抽出部は、
前記検索対象として飲食店に関する投稿情報から前記タグ候補を抽出すること
を特徴とする請求項７に記載の判定装置。

【請求項9】

前記判定部は、
前記飲食店で提供される提供物に関する前記タグ候補について前記タグとして採用するか否かを判定すること
を特徴とする請求項８に記載の判定装置。

【請求項10】

前記判定部は、
前記利用者の属性に応じて、前記タグ候補を検索時に用いる前記タグとして採用するか否かを判定すること
を特徴とする請求項１に記載の判定装置。

【請求項11】

前記判定部は、
前記利用者によるサービスの利用履歴から推定される前記検索対象の利用目的に応じて、前記タグ候補を検索時に用いる前記タグとして採用するか否かを判定すること
を特徴とする請求項１に記載の判定装置。

【請求項12】

コンピュータが実行する判定方法であって、
検索対象からタグ候補を抽出する抽出工程と、
前記抽出工程によって抽出された前記タグ候補に対応する利用者の行動履歴に基づいて前記タグ候補の検索に関する周期性の有無を推定する推定工程と、
前記推定工程によって前記周期性が有ると判定された前記タグ候補に対して、前記タグ候補を検索時に用いるタグとして採用するか否かを判定する判定工程と
を含むことを特徴とする判定方法。

【請求項13】

検索対象からタグ候補を抽出する抽出手順と、
前記抽出手順によって抽出された前記タグ候補に対応する利用者の行動履歴に基づいて前記タグ候補の検索に関する周期性の有無を推定する推定手順と、
前記推定手順によって前記周期性が有ると判定された前記タグ候補に対して、前記タグ候補を検索時に用いるタグとして採用するか否かを判定する判定手順と
をコンピュータに実行させることを特徴とする判定プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、判定装置、判定方法および判定プログラムに関する。

【背景技術】

【0002】

近年、飲食店を紹介するサービスにおいて、利用者の嗜好にあわせてレコメンドする飲食店を選択する技術がある。このような技術においては、利用者が入力した検索クエリに対して飲食店の紹介情報から抽出した特徴量に応じてレコメンドする飲食店を選択する（例えば、特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１６－５３８７０号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、従来技術では、利用者に対して適切な検索サービスを提供するうえで改善の余地があった。

【0005】

本発明は、上記に鑑みてなされたものであって、利用者に対して適切な検索サービスを提供することができる判定装置、判定方法および判定プログラムを提供することを目的とする。

【課題を解決するための手段】

【0006】

上述した課題を解決し、目的を達成するために、本発明に係る判定装置は、検索対象からタグ候補を抽出する抽出部と、前記抽出部によって抽出された前記タグ候補と、当該タグ候補に対応する利用者の行動履歴とに基づいて、前記タグ候補を検索時に用いるタグとして採用するか否かを判定する判定部とを備える。

【発明の効果】

【0007】

本発明に係る判定装置によれば、利用者に対して適切な検索サービスを提供することができる。

【図面の簡単な説明】

【0008】

【図1】図１は、実施形態に係る情報処理の一例を示す図である。

【図2】図２は、実施形態に係る情報提供装置の構成例を示すブロック図である。

【図3】図３は、実施形態に係る利用者情報データベースに格納する情報の一例を示す図である。

【図4】図４は、実施形態に係る店舗情報データベースに格納される情報の一例を示す図である。

【図5】図５は、実施形態に係るタグ情報データベースに格納する情報の一例を示す図である。

【図6】図６は、実施形態に係る周期性の推定処理の模式図である。

【図7】図７は、実施形態に係るタグ候補のスコアの一例を示す図である。

【図8】図８は、実施形態に係る推定処理の一例を示すフローチャートである。

【図9】図９は、実施形態に係る判定処理の一例を示すフローチャートである。

【図10】図１０は、実施形態に係る情報提供装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

【発明を実施するための形態】

【0009】

以下に、本願に係る判定装置、判定方法および判定プログラムを実施するための形態（以下、「実施形態」と記載する。）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る判定装置、判定方法および判定プログラムが限定されるものではない。

【0010】

［実施形態］
〔１．情報処理〕
まず、図１を用いて、実施形態に係る情報処理の一例について説明する。図１は、実施形態に係る情報処理の一例を示す図である。

【0011】

図１に示す実施形態に係る情報提供装置１は、各種Ｗｅｂサービスを提供する情報提供装置である。情報提供装置１は、実施形態に係る判定装置の一例であり、例えば、グルメサイトを運営する。なお、情報提供装置１は、Ｗｅｂサービスとして、インターネット接続、検索サービス、ＳＮＳ（Social Networking Service）、電子商取引、電子決済、オンラインゲーム、オンラインバンキング、オンライントレーディング、宿泊・チケット予約、動画・音楽配信等のサービスを提供してもよい。

【0012】

情報提供装置１は、各利用者の利用者端末１０と連携し、各利用者Ｕの利用者端末１０に対して、各種アプリケーション（以下、アプリ）等に対するＡＰＩ（Application Programming Interface）サービス等と、各種データを提供する情報提供装置であり、サーバ装置やクラウドシステム等により実現される。また、情報提供装置１は、実際には、上記のようなＷｅｂサービスを提供する各種サーバと連携し、Ｗｅｂサービスを仲介してもよい。

【0013】

利用者端末１０は、利用者Ｕによって操作される端末である。例えば、利用者端末１０は、所定のネットワークを介して情報提供装置１が提供する各種Ｗｅｂサービスを利用者Ｕに対して提供する。

【0014】

例えば、利用者端末１０は、情報提供装置１から提供されるグルメサイトに関する各種情報を利用者Ｕに対して提供する。また、利用者端末１０は、情報提供装置１に対して利用者Ｕによる口コミ（投稿情報）に関する情報を提供する。

【0015】

ところで、情報提供装置１は、グルメサイトに掲載する店舗（飲食店）に関する店舗情報を格納する店舗データベースと、各店舗の検索タグとなるタグ情報データベースとを有する。情報提供装置１は、利用者端末１０から取得した口コミ情報を取得し（ステップＳ１）、店舗情報データベースに格納していく。

【0016】

例えば、情報提供装置１は、各利用者Ｕから取得した口コミ情報を店舗に関する情報とともに各利用者Ｕに対して提供する。なお、口コミ情報は、利用者Ｕが利用した店舗に関する評価（例えば、５段階評価）、店舗のサービス等に関する感想、店舗で撮影した写真等が含まれる。

【0017】

情報提供装置１は、所定の自然言語処理を用い、口コミ情報から各店舗のタグ候補を抽出し（ステップＳ２）、タグ情報データベースに格納する。図１に示す例において、情報提供装置１は、「××ウナギ〇〇店」に対する「（お店の）雰囲気もよく、うなぎがおいしい」との口コミ情報から「雰囲気がいい」および「うなぎがおいしい」といったタグ候補を抽出した場合を示す。

【0018】

つづいて、情報提供装置１は、各タグ情報を用いて検索される各店舗のＰＶ（Page View）数を計測する（ステップＳ３）。情報提供装置１は、「雰囲気がいい」という検索クエリから対応する店舗の店舗ページアクセスされた場合、「雰囲気がいい」というタグ候補にＰＶ数を加算していく。

【0019】

情報提供装置１は、ＰＶ数計測の結果を用い、各タグ候補について周期性の有無を推定する。情報提供装置１は、各種統計処理を用いて、ＰＶ数の推移から周期性の有無を推定する（ステップＳ４）。

【0020】

周期性は、例えば、四季単位、月単位や週単位であるが、曜日単位、日付単位であってもよい。すなわち、情報提供装置１は、四季単位や月単位で各タグ候補のＰＶ数を集計し、四季単位や月単位における各タグ候補のＰＶ数の各種統計処理によって周期性の有無を推定する。

【0021】

例えば、情報提供装置１は、各タグ候補について統計処理によって周期性スコアを算出し、算出した周期性スコアが閾値を超えるタグ候補について周期性有りと推定する。また、情報提供装置１は、店舗カテゴリや、提供する料理種別毎に周期性の有無を推定するようにしてもよい。また、情報提供装置１は、店舗の顧客単価などに応じて分類した所定のカテゴリ毎に周期性を推定するようにしてもよい。

【0022】

図１に示す例では、「雰囲気がいい」というタグ候補に周期性がなく、「うなぎがおいしい」というタグ候補に周期性ありと推定した場合を示し、「うなぎがおいしい」というタグ候補のピークは「１月および７月」である場合を示す。なお、以下では、周期性がないタグ候補について「通年タグ」と記載し、周期性があるタグ候補について「周期性タグ」と記載する場合がある。

【0023】

その後、情報提供装置１は、利用者端末１０から検索リクエストを受け付ける（ステップＳ５）。情報提供装置１は、検索リクエストに対し、採用するタグを判定する（ステップＳ６）。

【0024】

情報提供装置１は、タグ候補毎に検索時にあわせてＰＶ実績に連動するスコアを変動させ、例えば、スコアが閾値を超えるタグ候補を採用するタグとして判定する。情報提供装置１は、例えば、周期性タグのピークを迎える１月および７月においては、対応する周期性タグのスコアを高くし、ピーク以外の期間については周期性タグのスコアを低くする。

【0025】

これにより、周期性タグのスコアが高いピーク期間においては、周期性タグを用いた検索結果において対応する店舗がより検索上位になり、ピーク期間以外の期間において対応する店舗の検索順位が降下する。つまり、情報提供装置１は、タグ候補がトレンドとなる期間か否かで、対応するタグ候補の重みを調整する。

【0026】

その後、情報提供装置１は、検索リクエスト元の利用者端末１０に対して検索結果を提供する（ステップＳ７）。このように、情報提供装置１は、タグ候補の周期性にあわせてタグ候補のスコアを変動させる。

【0027】

これにより、情報提供装置１は、周期性にあわせた適切な検索結果を提供することが可能となるので、利用者Ｕに対して適切な検索サービスを提供することができる。また、情報提供装置１は、飲食店において提供される提供物（例えば、うなぎ）に関するタグ候補についてタグとして採用するか否かを判定することで、提供物に関するトレンドに応じた検索サービスを提供することができる。

【0028】

〔２．情報提供装置の構成例〕
次に、図２を用いて、実施形態に係る情報提供装置１の構成例について説明する。図２は、実施形態に係る情報提供装置１の構成例を示すブロック図である。図２に示すように、情報提供装置１は、通信部２と、記憶部３と、制御部４とを有する。

【0029】

（通信部２）
通信部２、例えば、ＮＩＣ（Network Interface Card）等によって実現される。また、通信部２は、ネットワークと有線又は無線で接続される。

【0030】

（記憶部３）
記憶部３は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ハードディスク、光ディスク等の記憶装置によって実現される。図２に示すように、記憶部３は、利用者情報データベース３１と、店舗情報データベース３２と、タグ情報データベース３３とを有する。

【0031】

（利用者情報データベース３１）
利用者情報データベース３１は、利用者Ｕに関する各種利用者情報を格納するデータベースである。図３は、実施形態に係る利用者情報データベース３１に格納する情報の一例を示す図である。

【0032】

利用者情報データベース３１は、「利用者ＩＤ」、「アカウント情報」、「検索履歴」、「利用履歴」、「口座情報」などといった項目の情報を互い対応付けて記憶する。「利用者ＩＤ」は、各利用者を識別するための識別子である。

【0033】

「アカウント情報」は、情報提供装置１が提供する各種Ｗｅｂサービスに対して各利用者Ｕが登録した情報である。アカウント情報は、氏名、年齢、職業、住所、家族構成などといった情報を含む。

【0034】

「検索履歴」は、対応する利用者ＩＤによって識別される利用者Ｕの検索履歴である。「利用履歴」は、対応する利用者ＩＤによって識別される利用者Ｕの利用履歴である。利用履歴は、情報提供装置１が提供するグルメサイトを経由して利用者Ｕが利用した店舗に関する履歴である。なお、利用履歴は、利用者端末１０の位置情報の履歴や、利用者端末１０を利用した電子決済サービスの使用履歴から利用者Ｕが利用した店舗を特定したものであってもよい。また、利用履歴は、利用者Ｕによる口コミ情報や、ＳＮＳの発信から利用者Ｕが利用した店舗を特定したものであってもよい。

【0035】

「口座情報」は、対応する利用者ＩＤによって識別される利用者Ｕの口座情報である。口座情報は、利用者端末１０を利用した電子決済サービスの口座に関する情報であるが、銀行口座や証券口座、クレジットカードが紐づいていてもよい。

【0036】

（店舗情報データベース３２）
店舗情報データベース３２は、グルメサイトに掲載する店舗に関する各種店舗情報を格納するデータベースである。図４は、実施形態に係る店舗情報データベース３２に格納される情報の一例を示す図である。

【0037】

図４に示すように、店舗情報データベース３２は、「店舗ＩＤ」、「店舗情報」、「投稿情報」、「ＰＶ履歴」、「使用用途」などといった項目の情報を互いに対応付けて記憶する。

【0038】

「店舗ＩＤ」は、各店舗を識別するための識別子である。「店舗情報」は、各店舗に関する基本情報であり、店舗名、営業時間、住所、電話番号、店舗紹介、メニューやコース、利用可能なクーポンに関する情報を含む。

【0039】

「投稿情報」は、各利用者から投稿された口コミに関する情報であり、各利用者の店舗に対する評価や感想、写真を含む。

【0040】

「ＰＶ履歴」は、対応する店舗の店舗ページへのアクセス履歴であり、いつ、だれに、どんな検索クエリで店舗ページにアクセスされたかといった情報が含まれる。利用履歴は、各利用者による店舗の利用履歴であり、いつ、どんな利用者が店舗を利用したかといった情報や支払金額に関する情報が含まれる。

【0041】

「使用用途」は、対応する店舗の使用用途である。なお、使用用途は、例えば、投稿情報から推定するようにしてもよく、店舗情報から抽出するようにしてもよい。また、利用者によって使用用途が異なるため、利用者の属性等に応じて、複数の使用用途を含むようにしてもよい。

【0042】

（タグ情報データベース３３）
タグ情報データベース３３は、タグやタグ候補に関する各種タグ情報を格納するデータベースである。図５は、実施形態に係るタグ情報データベース３３に格納する情報の一例を示す図である。

【0043】

図５に示すように、タグ情報データベース３３は、店舗毎に「検索クエリ」、「種別」、「ＰＶ実績」、「周期性」、「ピーク」、「異常フラグ」などといった項目の情報を互いに対応付けて記憶する。

【0044】

「クエリ」は、対応する店舗にタグ付けされたクエリである。「種別」は、対応するクエリの種別を示し、タグであれば「０」、候補タグであれば「１」となる。「ＰＶ実績」は、対応するクエリによる店舗のＰＶの履歴である。

【0045】

「周期性」は、対応するクエリの周期性の有無である。「ピーク」は、周期性があるクエリのピークとなる期間を示す。「異常フラグ」は、対応するクエリの異常の有無を示す。例えば、ＰＶが通常の挙動である場合「０」、通常と異なる挙動である場合「１」となる。通常と異なる挙動は、対応するクエリが瞬間的に多く利用された場合（いわゆるバズった場合）などが挙げられる。

【0046】

（制御部４）
制御部４は、コントローラ（Controller）であり、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等によって、情報提供装置１の内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭ等の記憶領域を作業領域として実行されることにより実現される。図２に示す例では、制御部４は、取得部４１と、抽出部４２と、推定部４３と、判定部４４と、提案部４５と、提供部４６とを有する。

【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】

〔６．ハードウェア構成〕
また、上述した実施形態に係る情報提供装置１は、例えば図１０に示すような構成のコンピュータ１０００によって実現される。図１０は、ハードウェア構成の一例を示す図である。コンピュータ１０００は、出力装置１０１０、入力装置１０２０と接続され、演算装置１０３０、一次記憶装置１０４０、二次記憶装置１０５０、出力Ｉ／Ｆ（Interface）１０６０、入力Ｉ／Ｆ１０７０、ネットワークＩ／Ｆ１０８０がバス１０９０により接続された形態を有する。

【0088】

演算装置１０３０は、一次記憶装置１０４０や二次記憶装置１０５０に格納されたプログラムや入力装置１０２０から読み出したプログラム等に基づいて動作し、各種の処理を実行する。演算装置１０３０は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等により実現される。

【0089】

一次記憶装置１０４０は、ＲＡＭ（Random Access Memory）等、演算装置１０３０が各種の演算に用いるデータを一次的に記憶するメモリ装置である。また、二次記憶装置１０５０は、演算装置１０３０が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等により実現される。二次記憶装置１０５０は、内蔵ストレージであってもよいし、外付けストレージであってもよい。また、二次記憶装置１０５０は、ＵＳＢメモリやＳＤ（Secure Digital）メモリカード等の取り外し可能な記憶媒体であってもよい。また、二次記憶装置１０５０は、クラウドストレージ（オンラインストレージ）やＮＡＳ（Network Attached Storage）、ファイルサーバ等であってもよい。

【0090】

出力Ｉ／Ｆ１０６０は、ディスプレイ、プロジェクタ、及びプリンタ等といった各種の情報を出力する出力装置１０１０に対し、出力対象となる情報を送信するためのインターフェイスであり、例えば、ＵＳＢ（Universal Serial Bus）やＤＶＩ（Digital Visual Interface）、ＨＤＭＩ（登録商標）（High Definition Multimedia Interface）といった規格のコネクタにより実現される。また、入力Ｉ／Ｆ１０７０は、マウス、キーボード、キーパッド、ボタン、及びスキャナ等といった各種の入力装置１０２０から情報を受信するためのインターフェイスであり、例えば、ＵＳＢ等により実現される。

【0091】

また、出力Ｉ／Ｆ１０６０及び入力Ｉ／Ｆ１０７０はそれぞれ出力装置１０１０及び入力装置１０２０と無線で接続してもよい。すなわち、出力装置１０１０及び入力装置１０２０は、ワイヤレス機器であってもよい。

【0092】

また、出力装置１０１０及び入力装置１０２０は、タッチパネルのように一体化していてもよい。この場合、出力Ｉ／Ｆ１０６０及び入力Ｉ／Ｆ１０７０も、入出力Ｉ／Ｆとして一体化していてもよい。

【0093】

なお、入力装置１０２０は、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、又は半導体メモリ等から情報を読み出す装置であってもよい。

【0094】

ネットワークＩ／Ｆ１０８０は、ネットワークＮを介して他の機器からデータを受信して演算装置１０３０へ送り、また、ネットワークＮを介して演算装置１０３０が生成したデータを他の機器へ送信する。

【0095】

演算装置１０３０は、出力Ｉ／Ｆ１０６０や入力Ｉ／Ｆ１０７０を介して、出力装置１０１０や入力装置１０２０の制御を行う。例えば、演算装置１０３０は、入力装置１０２０や二次記憶装置１０５０からプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行する。

【0096】

例えば、コンピュータ１０００が情報提供装置１として機能する場合、コンピュータ１０００の演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラムを実行することにより、制御部４の機能を実現する。また、コンピュータ１０００の演算装置１０３０は、ネットワークＩ／Ｆ１０８０を介して他の機器から取得したプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行してもよい。また、コンピュータ１０００の演算装置１０３０は、ネットワークＩ／Ｆ１０８０を介して他の機器と連携し、プログラムの機能やデータ等を他の機器の他のプログラムから呼び出して利用してもよい。

【0097】

〔７．その他〕
以上、本願の実施形態を説明したが、これら実施形態の内容により本発明が限定されるものではない。また、前述した構成要素には、当業者が容易に想定できるもの、実質的に同一のもの、いわゆる均等の範囲のものが含まれる。さらに、前述した構成要素は適宜組み合わせることが可能である。さらに、前述した実施形態の要旨を逸脱しない範囲で構成要素の種々の省略、置換又は変更を行うことができる。

【0098】

また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

【0099】

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

【0100】

例えば、上述した情報提供装置１は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティング等で呼び出して実現するなど、構成は柔軟に変更できる。

【0101】

また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

【0102】

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

【符号の説明】

【0103】

１ 情報提供装置
２ 通信部
３ 記憶部
４ 制御部
１０ 利用者端末
３１ 利用者情報データベース
３２ 店舗情報データベース
３３ タグ情報データベース
４１ 取得部
４２ 抽出部
４３ 推定部
４４ 判定部
４５ 提案部
４６ 提供部
Ｕ 利用者

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】