JP2019079319A - レコメンドシステム、装置、方法、及びプログラム - Google Patents

Abstract

【課題】 ユーザにとって有用な設定値をレコメンド可能とする。【解決手段】 一実施形態に係るレコメンドシステムは、複数のユーザのアプリケーションの利用傾向を複数のクラスタに分類する分類部と、対象ユーザの前記利用傾向が属する前記クラスタにおける前記アプリケーションの設定値の有用度と、レコメンド条件と、に基づいて、前記対象ユーザに前記アプリケーションの前記設定値をレコメンドするレコメンド部と、前記利用傾向に基づいて、前記分類部による分類方法及び前記レコメンド条件の少なくとも一方を更新する学習部と、を備える。【選択図】 図３

Description

本発明は、レコメンドシステム、装置、方法、及びプログラムに関する。

近年、スマートデバイスに各種のアプリケーション（以下「アプリ」という。）を提供するオンラインマーケットが利用されている。スマートデバイスのユーザは、当該マーケットから所望のアプリを有料又は無料でダウンロードし、スマートデバイス上で利用できる。

従来、アプリの操作性を高める方法として、ユーザにとって有用なアプリの設定値をレコメンドする方法が提案されている。設定値をレコメンドする方法として、対象ジョブと、対象ジョブと類似する実行済みのジョブと、の設定値の差異を抽出し、差異として抽出された設定値をレコメンドする方法が提案されている。

しかしながら、上記従来の方法では、類似するジョブ間で相違する設定値がレコメンドされるだけであるため、レコメンドされる設定値がユーザにとって有用な設定値であるか否か不明であった。

本発明は、上記の課題に鑑みてなされたものであり、ユーザにとって有用な設定値をレコメンド可能とすることを目的とする。

一実施形態に係るレコメンドシステムは、複数のユーザのアプリケーションの利用傾向を複数のクラスタに分類する分類部と、対象ユーザの前記利用傾向が属する前記クラスタにおける前記アプリケーションの設定値の有用度と、レコメンド条件と、に基づいて、前記対象ユーザに前記アプリケーションの前記設定値をレコメンドするレコメンド部と、前記利用傾向に基づいて、前記分類部による分類方法及び前記レコメンド条件の少なくとも一方を更新する学習部と、を備える。

本発明の各実施形態によれば、ユーザにとって有用な設定値をレコメンドできる。

レコメンドシステムの構成の一例を示す図。 ユーザ端末のハードウェア構成の一例を示す図。 レコメンドシステムの機能構成の一例を示す図。 操作ログの一例を示す図。 利用傾向記憶部に記憶された利用傾向の一例を示す図。 利用傾向の一例を示す図。 利用傾向の一例を示す図。 有用度の一例を示す図。 レコメンドの成功例及び失敗例を示す図。 利用傾向及びクラスタの更新処理の一例を示すシーケンス図。 設定値のレコメンド処理の一例を示すシーケンス図。 有用度の更新処理の一例を示すシーケンス図。 分類方法及びレコメンド条件の学習処理の一例を示すシーケンス図。

以下、本発明の各実施形態について、添付の図面を参照しながら説明する。なお、各実施形態に係る明細書及び図面の記載に関して、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重畳した説明を省略する。

一実施形態に係るレコメンドシステム１０００について、図１〜図１３を参照して説明する。まず、レコメンドシステム１０００の構成について説明する。図１は、レコメンドシステム１０００の構成の一例を示す図である。図１のレコメンドシステム１０００は、ユーザ端末１Ａ〜１Ｂと、レコメンドサーバ２と、アプリマーケット３と、ネットワーク４と、を含む。

ユーザ端末１Ａ〜１Ｃは、ユーザが各種のアプリを利用するためのコンピュータである。ユーザ端末１Ａ〜１Ｃは、例えば、ＰＣ（Personal Computer）、スマートフォン、タブレット端末、スマートウォッチ、又はテレビであるが、これに限られない。以下、ユーザ端末１Ａ〜１Ｃを区別しない場合、単にユーザ端末１と称する。図１の例では、レコメンドシステム１０００には、３つのユーザ端末１が含まれるが、レコメンドシステム１０００に含まれるユーザ端末１の数は任意である。なお、ユーザ端末１において利用可能な各アプリは、それぞれ複数のアプリ設定を有し、各アプリ設定は、デフォルト値として設定可能な複数の設定値をそれぞれ有する。

レコメンドサーバ２は、レコメンド装置の一例であり、ユーザ端末１のユーザに、当該ユーザにとってデフォルト値として有用な、アプリの設定値をレコメンドするサーバコンピュータである。レコメンドサーバ２は、レコメンドシステム１０００に含まれる各ユーザ端末１から取得した情報に基づいて、各ユーザ端末１のユーザに、デフォルト値として有用な設定値をそれぞれレコメンドする。なお、本実施形態において、レコメンド装置は、例えば、ＰＣ、スマートフォン、タブレット端末などであってもよい。また、レコメンド装置は、複数のサーバコンピュータにより構成されてもよい。

アプリマーケット３は、ユーザに有料又は無料でアプリを提供するオンラインマーケットであり、１つ又は複数のサーバコンピュータにより構成される。ユーザは、アプリマーケット３から所望のアプリをユーザ端末１にダウンロードできる。

ネットワーク４は、ＬＡＮ（Local Area Network）やインターネットなどを含み、ユーザ端末１、レコメンドサーバ２、及びアプリマーケット３を相互に接続する。

次に、本実施形態に係るユーザ端末１のハードウェア構成について説明する。図２は、ユーザ端末１のハードウェア構成の一例を示す図である。図２のユーザ端末１は、ＣＰＵ（Central Processing Unit）１０１と、ＲＯＭ（Read Only Memory）１０２と、ＲＡＭ（Random Access Memory）１０３と、ＨＤＤ（Hard Disk Drive）１０４と、を備える。また、ユーザ端末１は、入力装置１０５と、表示装置１０６と、通信インタフェース１０７と、システムバス１０８と、を備える。

ＣＰＵ１０１は、プログラムを実行することにより、ユーザ端末１の各構成を制御し、ユーザ端末１の機能を実現する。

ＲＯＭ１０２は、ＣＰＵ１０１が実行するプログラム（ＢＩＯＳ（Basic Input Output System）など）や各種のデータを記憶する。

ＲＡＭ１０３は、ＣＰＵ１０１に作業領域を提供する。

ＨＤＤ１０４は、ＣＰＵ１０１が実行するプログラム（ＯＳ（Operating System）など）や各種のデータを記憶する。

入力装置１０５は、ユーザの操作に応じた情報をユーザ端末１に入力する。入力装置１０５は、例えば、タッチパネル、キーボード、マウス、又はハードウェアボタンであるが、これに限られない。

表示装置１０６は、ユーザの操作に応じた画面を表示する。表示装置１０６は、例えば、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ、又はプラズマディスプレイであるが、これに限られない。

通信インタフェース１０７は、ユーザ端末１をネットワーク４に接続するためのインタフェースである。ユーザ端末１は、通信インタフェース１０７を介して、ネットワーク４に接続されたレコメンドサーバ２やアプリマーケット３と通信する。

システムバス１０８は、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、ＨＤＤ１０４、入力装置１０５、表示装置１０６、及び通信インタフェース１０７を相互に接続する。

なお、レコメンドサーバ２は、ユーザ端末１と同様に、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、ＨＤＤ２０４と、入力装置２０５と、表示装置２０６と、通信インタフェース２０７と、を備え、これらがシステムバス２０８を介して相互に接続される。各ハードウェアについては、ユーザ端末１と同様であるため、説明を省略する。

次に、本実施形態に係るレコメンドシステム１０００の機能構成について説明する。図３は、レコメンドシステム１０００の機能構成の一例を示す図である。

まず、ユーザ端末１の機能構成について説明する。図３のユーザ端末１は、端末制御部１１と、アプリ記憶部１２と、操作ログ記憶部１３と、アップロード部１４と、を備える。これらの各機能構成は、ＣＰＵ１０１がプログラムを実行し、ユーザ端末１の各ハードウェアと協働することにより実現される。

端末制御部１１は、ユーザ端末１の全体の動作を制御する。具体的には、端末制御部１１は、アプリマーケット３からのアプリのダウンロード、アプリのインストール及びアンインストール、操作ログの更新、及びユーザへのアプリのレコメンドなどを行う。端末制御部１１の動作について、詳しくは後述する。

アプリ記憶部１２は、端末制御部１１にインストールされたアプリ（プログラム）及び当該アプリのアプリ情報を記憶する。アプリ情報には、アプリ名やアプリＩＤなどの情報が含まれる。アプリＩＤは、アプリの識別情報である。

操作ログ記憶部１３は、ユーザによるユーザ端末１の操作ログを記憶する。操作ログは、操作の実行日時と、操作内容と、が対応づけられたデータである。操作内容には、アプリのダウンロード、インストール、アンインストール、起動、終了、画面の切り替え、設定値の変更、ジョブの実行などが含まれる。

図４は、操作ログ記憶部１３に記憶された操作ログの一例を示す図である。図４の各レコードが、各操作に対応する操作ログに相当する。図４の例では、２月１日の１５：００にアプリＡのダウンロードが実行され、２月１日の１５：０１にアプリＡのインストールが実行されている。また、アプリＡの起動後、画面切替と、設定ａのデフォルト値ａ１から設定値ａ２への変更（設定値の変更）と、を経てジョブが実行されている。

なお、ユーザ端末１が複数のユーザにより利用される場合には、各操作に対応する操作ログに、当該操作を実行したユーザのユーザＩＤが含まれてもよい。ユーザＩＤは、ユーザの識別情報である。また、各操作ログにユーザＩＤが含まれる代わりに、操作ログを記憶される操作内容に、ユーザのログインが含まれてもよい。この場合、ユーザのログインに対応する操作ログには、実行日時（ログイン日時）と、ログインしたユーザのユーザＩＤと、が含まれる。以下、ユーザＩＤがＸであるユーザを、ユーザＸと称する。

アップロード部１４は、定期的に又は所定のタイミング（操作ログが更新されたタイミングやユーザ端末１に電源が投入されたタイミングなど）で、操作ログ記憶部１３に記憶された操作ログをレコメンドサーバ２にアップロードする。

次に、レコメンドサーバ２の機能構成について説明する。図３のレコメンドサーバ２は、レコメンド制御部２１と、利用傾向記憶部２２と、設定情報記憶部２３と、分類部２４と、レコメンド部２５と、学習部２６と、を備える。これらの各機能構成は、ＣＰＵ２０１がプログラムを実行し、レコメンドサーバ２の各ハードウェアと協働することにより実現される。

レコメンド制御部２１は、レコメンドサーバ２の全体の動作を制御する。具体的には、レコメンド制御部２１は、ユーザ端末１からアップロードされた操作ログの受け付け、利用傾向の更新、及び各機能構成への動作要求などを行う。また、レコメンド制御部２１は、ユーザ端末１から設定情報を取得する。レコメンド制御部２１の動作について、詳しくは後述する。

利用傾向記憶部２２は、所定期間ごとの各ユーザの各アプリの利用傾向を記憶する。所定期間は、１日、１週間、１ヶ月など、任意に設定可能である。また、利用傾向は、利用回数（起動回数又はジョブの実行回数）及び平均ステップ数を含む。

平均ステップ数は、アプリを起動してからジョブが実行されるまでのステップ数（操作回数）の平均値である。例えば、図４の例では、アプリＡのジョブは、アプリＡの起動後、画面切替、設定値の変更、及びジョブ実行という３つの操作を経て実行されているため、ステップ数は３である。ステップ数は、ユーザがジョブを実行するために要する手間の量に相当し、ステップ数が小さいほど、ユーザの手間が少ないことを意味する。このことから、平均ステップ数が小さいアプリのデフォルト値は、ユーザの手間を減らす、ユーザにとって有用なデフォルト値であると考えられる。

また、利用傾向記憶部２２は、所定期間ごとの各ユーザの利用傾向が属するクラスタを記憶する。後述する通り、所定期間ごとの各ユーザの利用傾向は、分類部２４により、複数のクラスタに分類される。利用傾向記憶部２２は、分類部２４により分類されたクラスタを、所定期間ごとの各ユーザの利用傾向と対応付けて記憶する。

図５は、利用傾向記憶部２２に記憶された利用傾向の一例を示す図である。図５の例では、ユーザＵ００１，Ｕ００２による１週間ごとのアプリＡ，Ｂの利用傾向（利用回数及びステップ数）が、クラスタと対応付けて記憶されている。例えば、ユーザＵ００１による２月１日から２月７日までのアプリＡの利用回数は５０回、平均ステップ数は５．０、アプリＢの利用回数は１００回、平均ステップ数は４．０であり、ユーザＵ００１のアプリの利用傾向はクラスタ１に属している。図５において、アプリの利用回数の値「−」は、アプリがインストールされていないことを示している。インストールされていないにもかかわらず利用回数が記憶されるアプリとして、レコメンドされたもののインストールされていないアプリが考えられる。

利用傾向記憶部２２に記憶される利用傾向は、例えば、各ユーザ端末１からアップロードされた操作ログに基づいて、レコメンド制御部２１が更新する。具体的には、レコメンド制御部２１は、ユーザ端末１からアップロードされた操作ログに基づいて、所定期間ごとの各アプリの利用傾向を集計し、当該利用傾向をユーザ端末１のユーザの各アプリの利用傾向に追加する。例えば、レコメンド制御部２１は、利用傾向記憶部２２に図５の利用傾向が記憶され、ユーザ端末１から図４の操作ログをアップロードされた場合、ユーザ端末１のユーザの２月１日から２月６日までの期間のアプリＡ，Ｂの利用回数を１ずつ追加する。また、レコメンド制御部２１は、ユーザ端末１のユーザの２月１日から２月６日までの期間のアプリＡの平均ステップ数を更新する。

また、ユーザ端末１のアップロード部１４は、操作ログ記憶部１３に記憶された操作ログに基づいて、所定期間ごとの各アプリの利用傾向を集計し、集計した利用傾向をレコメンドサーバ２にアップロードしてもよい。この場合、レコメンド制御部２１は、アップロードされた利用傾向を、利用傾向記憶部２２に記憶された利用傾向にそのまま追加すればよい。

設定情報記憶部２３は、各ユーザ端末１の設定情報を記憶する。設定情報には、ユーザ端末１の端末ＩＤ、アドレス、インストールされたアプリのアプリＩＤ、及び設定中のデフォルト値などが含まれる。端末ＩＤは、ユーザ端末１の識別情報である。デフォルト値は、設定日時と対応付けて、履歴情報として記憶される。レコメンド制御部２１は、定期的に又は所定のタイミング（ユーザ端末１がレコメンドサーバ２に接続したタイミングやユーザ端末１から操作ログを取得したタイミングなど）で、ユーザ端末１から設定情報を取得し、設定情報記憶部２３に記憶された設定情報を更新する。

分類部２４は、定期的に又は所定のタイミング（利用傾向が更新されたタイミングなど）で、利用傾向記憶部２２に記憶された複数のユーザの利用傾向に基づいて、所定期間ごとの各ユーザの利用傾向を複数のクラスタに分類する。クラスタは、類似する利用傾向の集合である。分類部２４により分類されたクラスタは、そのクラスタに属する利用傾向と対応付けて、利用傾向記憶部２２に記憶される。

分類部２４は、利用傾向を分類するための分類方法を記憶する。分類部２４は、利用傾向の分類方法として、最短距離法、ウォード法、ｋ平均法などの任意のクラスタリング方法を利用できる。この場合、分類部２４は、利用傾向間の距離（非類似度）を、アプリ毎の利用傾向の値に基づいて算出してもよいし、アプリ毎の利用傾向の値に基づいてアプリ毎の利用傾向の割合を算出し、アプリ毎の利用傾向の割合に基づいて算出してもよい。

図６及び図７は、利用傾向の一例を示す図である。図６の例では、ユーザＵ００１〜Ｕ００３のアプリＡ〜Ｄの利用回数が示されている。図６の例では、ユーザＵ００１及びユーザのＵ００２の利用回数の値が類似しており、ユーザＵ００２とユーザのＵ００３とは利用回数の割合が類似している。

また、図７の例では、ユーザＵ００１〜Ｕ００３のアプリＡ〜Ｄの平均ステップ数が示されている。図７の例では、ユーザＵ００２及びユーザＵ００３の平均ステップ数の値は、類似しているが、ユーザＵ００１の平均ステップ数の値は類似していない。

図６の例では、分類部２４が利用傾向の値に基づいて利用傾向間の距離を算出する場合、ユーザＵ００１，Ｕ００２の利用傾向は同一のクラスタに分類され、ユーザＵ００３の利用傾向は異なるクラスタに分類される。一方、分類部２４が利用傾向の割合に基づいて利用傾向間の距離を算出する場合、ユーザＵ００２，Ｕ００３の利用傾向は同一のクラスタに分類され、ユーザＵ００１の利用傾向は異なるクラスタに分類される。

また、分類部２４は、利用傾向の分類方法として、所定の分類条件に従った方法を利用してもよい。例えば、分類部２４は、利用傾向の値又は割合が最大のアプリごとに、利用傾向を分類してもよいし、利用傾向の値又はその割合が閾値以上のアプリごとに利用傾向を分類してもよい。前者の分類条件の場合、図６の例では、ユーザＵ００２，Ｕ００３の利用傾向が同一のクラスタに分類され、図７の例では、ユーザＵ００１〜Ｕ００３の利用傾向が同一のクラスタに分類される。

レコメンド部２５は、定期的に又は所定のタイミング（利用傾向やクラスタが更新されたタイミングなど）で、ユーザにとってデフォルト値として有用な設定値を選択し、選択した設定値をユーザにレコメンドする。具体的には、レコメンド部２５は、ユーザにとってデフォルト値として有用な設定値を示す情報を、当該ユーザのユーザ端末１に送信する。

レコメンド部２５は、利用傾向のクラスタごとの各設定値の有用度を記憶する。あるクラスタのある設定値の有用度は、利用傾向が当該クラスタに属するユーザが、当該設定値をデフォルト値として設定した場合の有用さの程度を示す指標である。有用度の算出方法については後述する。

図８は、レコメンド部２５に記憶された有用度の一例を示す図である。図８の例では、クラスタ１〜３における、アプリＡの設定ａ〜ｃの各設定値の有用度がそれぞれ示されている。例えば、クラスタ１における設定値ａ１の有用度は９、設定値ａ２の有用度は４、設定値ａ３の有用度は２である。これは、利用傾向がクラスタ１に属するユーザにとって、アプリＡの設定ａのデフォルト値として、設定値ａ１が最も有用であることを意味している。

また、レコメンド部２５は、レコメンド条件を記憶する。レコメンド条件は、ユーザにレコメンドする設定値（有用な設定値）の選択条件に相当する。レコメンド条件として、有用度が最大であることや、有用度が閾値以上であることが挙げられる。

レコメンド部２５は、その利用傾向があるクラスタに属するユーザに対して、当該クラスタにおける、有用度がレコメンド条件を満たす設定値を、デフォルト値として有用な設定値（有用なデフォルト値）としてレコメンドする。例えば、レコメンド条件が、有用度が７以上である場合、図８の例では、レコメンド部２５は、利用傾向がクラスタ１に属するユーザに、設定値ａ１，ｃ１を有用なデフォルト値としてレコメンドする。

なお、レコメンド部２５は、有用度がレコメンド条件を満たす設定値であっても、当該設定値がデフォルト値として設定済みである場合には、当該設定値をレコメンドしないのが好ましい。これにより、ユーザに対する余計なレコメンドを抑制できる。レコメンド部２５は、設定情報記憶部２３に記憶されたユーザ端末１のデフォルト値を参照することにより、設定値がデフォルト値として設定済みであるか判断できる。

学習部２６は、定期的に又は所定のタイミング（利用傾向やクラスタが更新されたタイミングなど）で、利用傾向記憶部２２に記憶された利用傾向に基づいて、利用傾向の分類方法及び設定値のレコメンド条件を、レコメンドの成功確率が高まるように更新する。すなわち、学習部２６が、レコメンドの成功確率が高い分類方法及びレコメンド条件を学習する。

分類方法を更新するとは、クラスタリング方法のパラメータ（ｋ平均法におけるｋなど）や分類条件のパラメータ（利用傾向の値や割合の閾値など）を更新することをいう。レコメンド条件を更新するとは、レコメンド条件のパラメータ（有用度の閾値など）を更新することをいう。レコメンドの成功確率とは、レコメンド部２５による設定値のレコメンドが成功する確率のことである。レコメンドの成功とは、レコメンド部２５がレコメンドした設定値がユーザによりデフォルト値として設定され、かつ、レコメンドした設定値に対応するアプリの利用傾向が所定の条件を満たすことをいう。所定の条件として、例えば、アプリの利用回数が増加することや、平均ステップ数が減少することなどが考えられる。

図９は、レコメンドの成功例及び失敗例を説明する図である。図９（Ａ）は、ユーザＸのレコメンド前の利用回数の一例を示し、図９（Ｂ）〜図９（Ｄ）は、ユーザＸのレコメンド後の利用回数の一例を示している。図９（Ｂ），（Ｃ）はレコメンドの失敗例、図９（Ｄ）はレコメンドの成功例に相当する。図９の例では、ユーザＸのレコメンド前のアプリＡの設定ａのデフォルト値はａ１であり、レコメンドサーバ２は、ユーザＸに対して、設定ａのデフォルト値として設定値ａ２をレコメンドしている。また、上記の所定の条件は、アプリの利用回数の増加であるものとする。

図９（Ｂ）の例では、ユーザＸは、レコメンドサーバ２からのレコメンドに応じず、設定ａのデフォルト値を変更していない。この場合、ユーザが、設定値ａ２はデフォルト値として有用でない、と判断したと考えられるため、学習部２６は、ユーザＸへのレコメンドは失敗と判断する。

図９（Ｃ）の例では、ユーザＸは、レコメンドサーバ２からのレコメンドに応じて、設定ａのデフォルト値を設定値ａ２に変更したものの、レコメンド後のアプリＡの利用回数が減少している。この場合、ユーザが、設定値ａ２はデフォルト値として有用である、と判断したものの、実際には有用ではなかったと考えられるため、学習部２６は、ユーザＸへのレコメンドは失敗と判断する。

図９（Ｄ）の例では、ユーザＸは、レコメンドサーバ２からのレコメンドに応じて、設定ａのデフォルト値を設定値ａ２に変更し、かつ、レコメンド後のアプリＡの利用回数が増加している。この場合、ユーザが、設定値ａ２はデフォルト値として有用であると判断し、かつ、実際に有用であった、と考えられるため、学習部２６は、ユーザＸへのレコメンドは成功と判断する。

このように、学習部２６は、レコメンド前後の利用傾向と、レコメンド前後のデフォルト値と、に基づいて、レコメンドの成否を判断することができる。なお、学習部２６は、利用傾向記憶部２２に記憶された利用傾向を参照することにより、レコメンド前後の利用傾向を取得することができる。また、学習部２６は、設定情報記憶部２３に記憶された設定情報を参照することにより、レコメンド前後のデフォルト値を取得することができる。

本実施形態において、レコメンド部２５はユーザに設定値をレコメンドし、ユーザはレコメンドされた設定値をデフォルト値として設定する（又は設定しない）。また、アップロード部１４はアプリの操作ログをレコメンドサーバ２に送信し、利用傾向記憶部２２はユーザ端末１から受信した操作ログに基づいて集計されたアプリの利用傾向を記憶する。さらに、学習部２６は利用傾向記憶部２２に記憶されたアプリの利用傾向と、設定情報記憶部２３に記憶されたデフォルト値と、に基づいて、分類部２４が利用する分類方法及びレコメンド部２５が利用するレコメンド条件を学習する。このように、学習部２６は、アプリのレコメンド結果（レコメンド後のデフォルト値及び利用傾向）をフィードバックされ、当該レコメンド結果に基づいて、分類方法及びレコメンド条件を学習する。したがって、学習部２６は、レコメンドの成功確率が高まるように分類方法及びレコメンド条件を学習できる。

学習部２６は、サポートベクターマシン（ＳＶＭ）、クラスタリング、ニューラルネットワーク、決定木などの、任意の学習方法を利用して、レコメンドの成功確率が高い分類方法及びレコメンド条件を学習できる。なお、学習部２６は、分類方法及びレコメンド条件を学習するための機械学習エンジンを備えるのが好ましい。

また、学習部２６は、定期的に又は所定のタイミング（利用傾向やクラスタが更新されたタイミングなど）で、利用傾向記憶部２２に記憶された利用傾向と、設定情報記憶部２３に記憶されたデフォルト値と、に基づいて、クラスタごとの各設定値の有用度を更新する。ここで、有用度の算出方法について、クラスタＸにおける設定値ａ１の有用度を例に説明する。設定値ａ１は、アプリＡの設定ａの設定値であるものとする。

学習部２６は、利用傾向がクラスタＸに属するユーザによるアプリＡの利用回数（又はその割合）の平均値が多いほど、クラスタＸにおける設定値ａ１の有用度が高くなるように、有用度を算出する。また、学習部２６は、利用傾向がクラスタＸに属するユーザによるアプリＡの平均ステップ数（又はその割合）の平均値が小さいほど、クラスタＸにおける設定値ａ１の有用度が高くなるように、有用度を算出する。これは、アプリＡの利用回数の平均値が多いほど、又はアプリＡの平均ステップ数の平均値が小さいほど、クラスタＸに属するユーザがアプリＡを使い慣れており、当該ユーザの利用傾向に基づく有用度の信頼性が高くなる、と考えられるためである。

また、学習部２６は、利用傾向がクラスタＸに属するユーザのアプリＡのデフォルト値における、設定値ａ１の割合が大きいほど、クラスタＸにおける設定値ａ１の有用度が高くなるように、有用度を算出する。これは、デフォルト値として設定値ａ１を利用するユーザが多いほど、設定値ａ１が有用なデフォルト値である可能性が高い、と考えられるためである。

また、学習部２６は、利用傾向がクラスタＸに属するユーザに設定値ａ１がレコメンドされた後、当該ユーザがデフォルト値として設定値ａ１を設定した場合、クラスタＸにおける設定値ａ１の有用度が高くなるように、有用度を算出してもよい。これは、レコメンドされた設定値ａ１がデフォルト値に設定された場合、ユーザにより設定値ａ１が有用なデフォルト値と判断された、と考えられるためである。

また、学習部２６は、利用傾向がクラスタＸに属するユーザが、デフォルト値を設定値ａ１から他の設定値に変更した場合、クラスタＸにおける設定値ａ１の有用度が低くなるように、有用度を算出してもよい。これは、ユーザによりデフォルト値が設定値ａ１から他の設定値に変更された場合、当該ユーザにより設定値ａ１がデフォルト値として有用ではないと判断された、と考えられるためである。

また、学習部２６は、利用傾向がクラスタＸに属するユーザによりデフォルト値が設定値ａ１に設定された後、当該ユーザのアプリＡの利用回数（又はその割合）が増加した場合、クラスタＸにおける設定値ａ１の有用度が高くなるように、有用度を算出してもよい。これは、設定値ａ１をデフォルト値に設定することにより、アプリＡの利便性が向上した結果、アプリＡの利用回数（又はその割合）が増加した、と考えられるためである。

また、学習部２６は、利用傾向がクラスタＸに属するユーザによりデフォルト値が設定値ａ１に設定された後、当該ユーザのアプリＡの平均ステップ数（又はその割合）が減少した場合、クラスタＸにおける設定値ａ１の有用度が高くなるように、有用度を算出してもよい。これは、設定値ａ１をデフォルト値に設定することにより、ユーザがアプリＡのジョブを実行するために要する手間が減少した、と考えられるためである。

次に、本実施形態に係るレコメンドシステム１０００の処理について説明する。図１０は、利用傾向及びクラスタの更新処理の一例を示すシーケンス図である。

ユーザ端末１のアップロード部１４は、更新タイミングが到来すると、操作ログ記憶部１３に、当該タイミングに送信する操作ログを要求する（ステップＳ１０１）。具体的には、アップロード部１４は、前回の更新タイミング以降に操作ログ記憶部１３に記憶された操作ログ（実行日時が前回の送信タイミング以降の操作ログ）を、操作ログ記憶部１３に要求する。

操作ログ記憶部１３は、操作ログを要求されると、要求された操作ログをアップロード部１４に渡す（ステップＳ１０２）。

アップロード部１４は、操作ログを受け取ると、受け取った操作ログをレコメンドサーバ２にアップロードする（ステップＳ１０３）。

アップロード部１４が操作ログをアップロードすると、レコメンド制御部２１は、アップロードされた操作ログを受け付け、当該操作ログに基づいて、所定期間ごとの各ユーザの各アプリの利用傾向を集計する（ステップＳ１０４）。

レコメンド制御部２１は、利用傾向を集計すると、集計した利用傾向を、利用傾向記憶部２２に保存する（ステップＳ１０５）。これにより、利用傾向記憶部２２に記憶された利用傾向が更新される。

また、レコメンド制御部２１は、分類部２４に利用傾向の分類を要求する（ステップＳ１０６）。なお、図１０の例では、分類部２４が、レコメンド制御部２１からの要求に応じて利用傾向を分類する場合を想定しているが、分類部２４は、レコメンド制御部２１とは独立したタイミングで利用傾向を分類してもよい。

分類部２４は、利用傾向の分類を要求されると、利用傾向記憶部２２に各ユーザの各アプリの利用傾向を要求する（ステップＳ１０７）。この際、分類部２４は、更新タイミングを含む期間の利用傾向（ステップＳ１０７において更新された利用傾向）だけを要求してもよい。これにより、レコメンドサーバ２の負荷を低減し、処理を高速化できる。

また、分類部２４は、更新タイミングを含む期間を含む、複数の期間の利用傾向を要求してもよい。これにより、複数の期間の利用傾向を、同一の分類方法で分類できる。

利用傾向記憶部２２は、利用傾向を要求されると、要求された利用傾向を分類部２４に渡す（ステップＳ１０８）。

分類部２４は、利用傾向を受け取ると、受け取った利用傾向に基づいて、所定期間ごとの各ユーザの利用傾向を分類する（ステップＳ１０９）。利用傾向の分類方法は、上述の通りである。

分類部２４は、利用傾向を分類すると、分類により得られたクラスタを、利用傾向記憶部２２に保存する（ステップＳ１１０）。これにより、利用傾向記憶部２２に記憶されたクラスタが更新される。

以上の処理により、レコメンドサーバ２は、最新の操作ログに基づいて、利用傾向及びクラスタを更新できる。これにより、図５のような利用傾向及びクラスタが、利用傾向記憶部２２に記憶される。

図１１は、設定値のレコメンド処理の一例を示すシーケンス図である。以下、設定値のレコメンド対象となるユーザを、対象ユーザと称する。対象ユーザは、１人であってもよいし、複数であってもよい。

レコメンドサーバ２のレコメンド制御部２１は、レコメンドタイミングが到来すると、レコメンド部２５に、対象ユーザへの設定値のレコメンドを要求する（ステップＳ２０１）。図１１の例では、レコメンド部２５が、レコメンド制御部２１からの要求に応じて設定値をレコメンドする場合を想定しているが、レコメンド部２５は、レコメンド制御部２１とは独立したタイミングで設定値をレコメンドしてもよい。

レコメンド部２５は、設定値のレコメンドを要求されると、利用傾向記憶部２２にレコメンドタイミングを含む期間における、対象ユーザの利用傾向が属するクラスタを要求する（ステップＳ２０２）。

利用傾向記憶部２２は、クラスタを要求されると、要求されたクラスタをレコメンド部２５に渡す（ステップＳ２０３）。

レコメンド部２５は、クラスタを受け取ると、受け取ったクラスタ（対象ユーザのクラスタ）における各設定値の有用度及びレコメンド条件を参照し、有用度がレコメンド条件を満たす設定値を、デフォルト値として有用な設定値として選択する（ステップＳ２０４）。

レコメンド部２５は、設定値を選択すると、選択した設定値を示す情報を対象ユーザのユーザ端末１に送信する（ステップＳ２０６）。設定値を示す情報には、設定値や、当該設定値に対応するアプリ及び設定を示す情報が含まれる。

レコメンド部２５が設定値を示す情報を送信すると、対象ユーザのユーザ端末１の端末制御部１１は、当該情報を受け付け、操作ログ記憶部１３に操作ログを保存する（ステップＳ２０６）。ここで保存される操作ログの操作内容は、設定値のレコメンドである。

また、端末制御部１１は、受け付けた情報に基づいて、レコメンド部２５が選択した設定値を、対象ユーザにデフォルト値として有用な設定値としてレコメンドする（ステップＳ２０７）。端末制御部１１による設定値のレコメンド方法は任意である。端末制御部１１は、例えば、ユーザ端末１の表示装置１０６にポップアップやダイアログを表示させることにより、設定値をレコメンドしてもよいし、プッシュ通知やメール送信により設定値をレコメンドしてもよい。

以上の処理により、レコメンドサーバ２は、対象ユーザにとってデフォルト値として有用な設定値をレコメンドできる。また、図５のような利用傾向及びクラスタが、利用傾向記憶部２２に記憶される。

図１２は、有用度の更新処理の一例を示すシーケンス図である。

レコメンドサーバ２のレコメンド制御部２１は、有用度の更新タイミングが到来すると、学習部２６に、有用度の更新を要求する（ステップＳ４０１）。図１２の例では、学習部２６が、レコメンド制御部２１からの要求に応じて有用度を更新する場合を想定しているが、学習部２６は、レコメンド制御部２１とは独立したタイミングで有用度を更新してもよい。

学習部２６は、有用度の更新を要求されると、利用傾向記憶部２２に利用傾向及びクラスタを要求する（ステップＳ４０２）。学習部２６は、有用度の算出方法に応じた利用傾向及びクラスタを要求すればよい。学習部２６は、例えば、更新タイミングを含む複数の期間の利用傾向及びクラスタを要求する。

利用傾向記憶部２２は、利用傾向及びクラスタを要求されると、要求された利用傾向及びクラスタを学習部２６に渡す（ステップＳ４０３）。

また、学習部２６は、設定情報記憶部２３に、設定中のデフォルト値を要求する（ステップＳ４０４）。学習部２６は、有用度の算出方法に応じたデフォルト値を要求すればよい。学習部２６は、例えば、更新タイミングを含む複数の期間のデフォルト値を要求する。

設定情報記憶部２３は、デフォルト値を要求されると、要求されたデフォルト値を学習部２６に渡す（ステップＳ４０５）。

学習部２６は、利用傾向、クラスタ、及びデフォルト値を受け取ると、受け取った利用傾向、クラスタ、及びデフォルト値に基づいて、クラスタごとの各設定値の有用度を算出する（ステップＳ４０６）。有用度の算出方法は、上述の通りである。

学習部２６は、有用度を算出すると、算出した有用度をレコメンド部２５に渡す（ステップＳ４０７）。レコメンド部２５は、有用度を受け取ると、受け取った有用度を記憶し、元の有用度を削除する。これにより、レコメンド部２５が記憶する有用度が更新される。以降、レコメンド部２５は、更新された有用度を利用して、有用な設定値を選択する。

以上の処理により、有用度を更新できる。有用度を随時更新することにより、レコメンド部２５は、最新の利用傾向及びデフォルト値に応じた有用な設定値をユーザにレコメンドできる。

図１３は、分類方法及びレコメンド条件の学習処理の一例を示すシーケンス図である。

レコメンドサーバ２のレコメンド制御部２１は、分類方法及びレコメンド条件の学習タイミングが到来すると、学習部２６に、分類方法及びレコメンド条件の学習を要求する（ステップＳ５０１）。図１３の例では、学習部２６が、レコメンド制御部２１からの要求に応じて分類方法及びレコメンド条件を学習する場合を想定しているが、学習部２６は、レコメンド制御部２１とは独立したタイミングで分類方法及びレコメンド条件を学習してもよい。

学習部２６は、分類方法及びレコメンド条件の学習を要求されると、利用傾向記憶部２２に利用傾向及びクラスタを要求する（ステップＳ５０２）。学習部２６は、分類方法及びレコメンド条件の学習方法に応じた利用傾向及びクラスタを要求すればよい。

利用傾向記憶部２２は、利用傾向及びクラスタを要求されると、要求された利用傾向及びクラスタを学習部２６に渡す（ステップＳ５０３）。

また、学習部２６は、設定情報記憶部２３にデフォルト値を要求する（ステップＳ５０４）。学習部２６は、分類方法及びレコメンド条件の学習方法に応じたデフォルト値を要求すればよい。

設定情報記憶部２３は、デフォルト値を要求されると、要求されたデフォルト値を学習部２６に渡す（ステップＳ５０５）。

学習部２６は、利用傾向、クラスタ、及びデフォルト値を受け取ると、受け取った利用傾向、クラスタ、及びデフォルト値に基づいて、レコメンドの成功確率が高い分類方法及びレコメンド条件（パラメータ）をそれぞれ学習する（ステップＳ５０６）。分類方法及びレコメンド条件の学習方法は、上述の通りである。

学習部２６は、分類方法を学習すると、学習した分類方法を分類部２４に渡す（ステップＳ５０７）。分類部２４は、分類方法を受け取ると、受け取った分類方法を記憶し、元の分類方法を削除する。これにより、分類部２４が記憶する分類方法が更新される。以降、分類部２４は、更新された分類方法を利用して、利用傾向を分類する。

また、学習部２６は、レコメンド条件を学習すると、学習したレコメンド条件をレコメンド部２５に渡す（ステップＳ５０８）。レコメンド部２５は、レコメンド条件を受け取ると、受け取ったレコメンド条件を記憶し、元のレコメンド条件を削除する。これにより、レコメンド部２５が記憶するレコメンド条件が更新される。以降、レコメンド部２５は、更新されたレコメンド条件を利用して、有用な設定値をレコメンドする。

以上の処理により、分類方法及びレコメンド条件を更新できる。分類方法を随時更新することにより、分類部２４は、最新の利用傾向及びデフォルト値に応じた分類方法により、ユーザの利用傾向を分類できる。また、レコメンド条件を随時更新することにより、レコメンド部２５は、最新の利用傾向及びデフォルト値に応じたレコメンド条件により、有用な設定値をレコメンドできる。

以上説明した通り、本実施形態に係るレコメンドシステム１０００は、利用傾向が対象ユーザと同一のクラスタに属するユーザ、すなわち、対象ユーザと類似する利用傾向を有するユーザ、にとって有用な設定値を、対象ユーザにレコメンドする。利用傾向が類似するユーザ間では、有用な設定値が同一である可能性が高いため、レコメンドシステム１０００は、対象ユーザにとって有用な設定値をレコメンドすることができる。

なお、本実施形態において、レコメンドシステム１０００に含まれるユーザ端末１の少なくとも一部がレコメンドサーバ２の機能を備え、レコメンドサーバ２の機能を備えたユーザ端末１がレコメンド装置として、他のユーザ端末１に有用な設定値をレコメンドしてもよい。

また、上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現可能である。ここで、本明細書における「処理回路」とは、電子回路により実装されるプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたＡＳＩＣ(Application Specific Integrated Circuit)、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）や従来の回路モジュール等のデバイスを含むものとする。

また、上記実施形態に挙げた構成等に、その他の要素との組み合わせなど、ここで示した構成に本発明が限定されるものではない。これらの点に関しては、本発明の趣旨を逸脱しない範囲で変更可能であり、その応用形態に応じて適切に定めることができる。

１：ユーザ端末
２：レコメンドサーバ
３：アプリマーケット
１１：端末制御部
１２：アプリ記憶部
１３：操作ログ記憶部
１４：アップロード部
２１：レコメンド制御部
２２：利用傾向記憶部
２３：設定情報記憶部
２４：分類部
２５：レコメンド部
２６：学習部
１０００：レコメンドシステム

特開２０１６−００７７２４号公報

Claims (15)

1. 複数のユーザのアプリケーションの利用傾向を複数のクラスタに分類する分類部と、
   対象ユーザの前記利用傾向が属する前記クラスタにおける前記アプリケーションの設定値の有用度と、レコメンド条件と、に基づいて、前記対象ユーザに前記アプリケーションの前記設定値をレコメンドするレコメンド部と、
   前記利用傾向に基づいて、前記分類部による分類方法及び前記レコメンド条件の少なくとも一方を更新する学習部と、
   を備えるレコメンドシステム。
2. 前記利用傾向は、前記アプリケーションの利用回数及び平均ステップ数の少なくとも一方を含む
   請求項１に記載のレコメンドシステム。
3. 前記学習部は、レコメンドの成功確率が高まるように、前記分類方法及び前記レコメンド条件の少なくとも一方を更新する
   請求項１又は請求項２に記載のレコメンドシステム。
4. 前記レコメンドの成功は、レコメンドした前記設定値が前記対象ユーザにより設定された後、前記対象ユーザの前記利用傾向が所定の条件を満たすことを含む
   請求項３に記載のレコメンドシステム。
5. 前記レコメンド部は、前記有用度が前記レコメンド条件を満たす前記設定値を、前記対象ユーザにレコメンドする
   請求項１から請求項４までのいずれか１項に記載のレコメンドシステム。
6. 前記設定値の前記有用度は、前記利用傾向が前記クラスタに属する前記ユーザの、当該設定値に対応する前記アプリケーションの利用回数の平均値が多いほど高く算出される
   請求項１から請求項５までのいずれか１項に記載のレコメンドシステム。
7. 前記設定値の前記有用度は、前記利用傾向が前記クラスタに属する前記ユーザの、当該設定値に対応する前記アプリケーションの平均ステップ数の平均値が小さいほど高く算出される
   請求項１から請求項６までのいずれか１項に記載のレコメンドシステム。
8. 前記設定値の前記有用度は、前記利用傾向が前記クラスタに属する前記ユーザのうち、当該設定値を設定中の前記ユーザの割合が大きいほど高く算出される
   請求項１から請求項７までのいずれか１項に記載のレコメンドシステム。
9. 前記設定値の前記有用度は、当該設定値をレコメンドされた前記対象ユーザが、当該設定値を設定した場合、高く算出される
   請求項１から請求項８までのいずれか１項に記載のレコメンドシステム。
10. 前記設定値の前記有用度は、前記ユーザが当該設定値を他の設定値に変更した場合、低く算出される
    請求項１から請求項９までのいずれか１項に記載のレコメンドシステム。
11. 前記設定値の前記有用度は、前記ユーザが当該設定値を設定した後、当該ユーザの、当該設定値に対応する前記アプリケーションの利用回数が増加した場合、高く算出される
    請求項１から請求項１０までのいずれか１項に記載のレコメンドシステム。
12. 前記設定値の前記有用度は、前記ユーザが当該設定値を設定した後、当該ユーザの、当該設定値に対応する前記アプリケーションの平均ステップ数が減少した場合、高く算出される
    請求項１から請求項１１までのいずれか１項に記載のレコメンドシステム。
13. 複数のユーザのアプリケーションの利用傾向を複数のクラスタに分類する分類部と、
    対象ユーザの前記利用傾向が属する前記クラスタにおける前記アプリケーションの設定値の有用度と、レコメンド条件と、に基づいて、前記対象ユーザに前記アプリケーションの前記設定値をレコメンドするレコメンド部と、
    前記利用傾向に基づいて、前記分類部による分類方法及び前記レコメンド条件の少なくとも一方を更新する学習部と、
    を備えるレコメンド装置。
14. 複数のユーザのアプリケーションの利用傾向を複数のクラスタに分類する分類工程と、
    対象ユーザの前記利用傾向が属する前記クラスタにおける前記アプリケーションの設定値の有用度と、レコメンド条件と、に基づいて、前記対象ユーザに前記アプリケーションの前記設定値をレコメンドするレコメンド工程と、
    前記利用傾向に基づいて、前記分類工程による分類方法及び前記レコメンド条件の少なくとも一方を更新する学習工程と、
    を含むレコメンド方法。
15. 複数のユーザのアプリケーションの利用傾向を複数のクラスタに分類する分類工程と、
    対象ユーザの前記利用傾向が属する前記クラスタにおける前記アプリケーションの設定値の有用度と、レコメンド条件と、に基づいて、前記対象ユーザに前記アプリケーションの前記設定値をレコメンドするレコメンド工程と、
    前記利用傾向に基づいて、前記分類工程による分類方法及び前記レコメンド条件の少なくとも一方を更新する学習工程と、
    をコンピュータに実行させるためのプログラム。

Images