JP2017188006A - アプリケーション分類システム - Google Patents

Abstract

【課題】 意味的地域を考慮して適切にアプリケーションを分類する。【解決手段】 サーバ１０はユーザ及びアプリケーション毎に、アプリケーションが利用された位置を示す利用位置情報を取得する利用情報取得部１２と、取得された利用位置情報に基づいて、ユーザ毎に設定された地域毎にアプリケーションの利用状態を算出する利用状態算出部１４と、算出された利用状態に基づいて、アプリケーションの分類を行う分類部１５とを備える。【選択図】 図１

Description

本発明は、アプリケーションを分類するアプリケーション分類システムに関する。

従来から、ユーザが興味を持つと推定されるアプリケーションを、ユーザに推薦する技術が提案されている（例えば、特許文献１参照）。

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

アプリケーションの推薦は、アプリケーションのカテゴリ分類に応じて行われることが多い。そのようなカテゴリ分類としては、“カメラ”“エンタメ（エンターテインメント）”といったアプリケーションの使用目的に応じたもの一般的である。しかしながら、アプリケーションの中には、ユーザに応じた意味的地域に応じて利用されるものがある。意味的地域とは、市町村等の物理的に決められた地域ではなく、各ユーザとって意味を持つ地域のことである。例えば、ユーザが日常的に訪問する（位置する）日常圏といった地域である。そのようなアプリケーションについては、上述したような単純なカテゴリ分類では、ユーザに対して適切なアプリケーションを推薦することができない。

本発明は、上記に鑑みてなされたものであり、意味的地域を考慮して適切にアプリケーションを分類することができるアプリケーション分類システムを提供することを目的とする。

上記目的を達成するために、本発明に係るアプリケーション分類システムは、ユーザ及びアプリケーション毎に、アプリケーションが利用された位置を示す利用位置情報を取得する利用情報取得手段と、利用情報取得手段によって取得された利用位置情報に基づいて、ユーザ毎に設定された地域毎にアプリケーションの利用状態を算出する利用状態算出手段と、利用状態算出手段によって算出された利用状態に基づいて、アプリケーションの分類を行う分類手段と、を備える。

本発明に係るアプリケーション分類システムでは、ユーザ毎に設定された地域毎のアプリケーションの利用状態に基づいてアプリケーションの分類が行われる。従って、本発明に係るアプリケーション分類システムによれば、意味的地域を考慮して適切にアプリケーションを分類することができる。

利用状態算出手段は、ユーザ毎の第１の地域及び第２の地域毎にアプリケーションの利用状態を算出し、分類手段は、第１の地域における利用状態を示す値と第２の地域における利用状態を示す値との比に基づいて、アプリケーションの分類を行う、こととしてもよい。この構成によれば、より適切にアプリケーションを分類することができる。

アプリケーション分類システムは、ユーザの位置を示す位置情報を取得し、取得した位置情報に基づいて、地域を設定する地域設定手段を更に備えることとしてもよい。この構成によれば、アプリケーションの分類を行うための地域を適切かつ確実に設定することができ、確実かつ適切に本発明を実施することができる。

利用情報取得手段は、アプリケーションを利用するユーザの属性及び当該アプリケーションが利用された状況の少なくとも何れかを示す付加情報も取得し、分類手段は、利用情報取得手段によって取得された付加情報にも基づいて、アプリケーションの分類を行うこととしてもよい。この構成によれば、より詳細なアプリケーションの分類を行うことができる。

アプリケーション分類システムは、分類手段によって行われたアプリケーションの分類に基づいて、ユーザへのアプリケーションの推薦を行う推薦手段を更に備えることとしてもよい。この構成によれば、意味的地域を考慮したアプリケーションの推薦を行うことができる。

本発明によれば、意味的地域を考慮して適切にアプリケーションを分類することができる。

本発明の実施形態に係るアプリケーション分類システムであるサーバの構成を示す図である。 測位点テーブルを示す図である。 アプリ利用テーブルを示す図である。 滞留点テーブルを示す図である。 インストールアプリテーブルを示す図である。 非日常ランキングテーブルを示す図である。 本発明の実施形態に係るアプリケーション分類システムであるサーバのハードウェア構成を示す図である。 本発明の実施形態に係るアプリケーション分類システムであるサーバでアプリの分類の際に実行される処理を示すフローチャートである。 本発明の実施形態に係るアプリケーション分類システムであるサーバでアプリの推薦の際に実行される処理を示すフローチャートである。

以下、図面と共に本発明に係るアプリケーション分類システムの実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

図１に本実施形態に係るアプリケーション分類システムであるサーバ１０を示す。サーバ１０は、ユーザ端末２０のユーザに対して、アプリケーション（以下、アプリと呼ぶ）を推薦（レコメンド）する装置である。例えば、サーバ１０は、ユーザに応じて、ユーザ端末２０で利用（インストール）してもらいたいアプリの情報をユーザ端末２０に送信する。後述するようにアプリの推薦は、ユーザが日常的に位置している地域である日常圏で使用されるアプリか、ユーザが日常的に位置している地域である非日常圏で使用されるアプリかのアプリの分類を行った上で、当該アプリの分類に基づいて行われる。非日常圏は、例えば、旅行先等、そのユーザにとって普段訪問しない場所である。

ユーザ端末２０は、ユーザによって携帯されて用いられる装置である。ユーザ端末２０は、具体的には、携帯電話機やスマートフォン等に相当する。ユーザ端末２０は、移動体通信網等のネットワークＮに接続して無線通信を行う機能を有している。ユーザ端末２０とサーバ１０とは、ネットワークＮを介して通信を行うことができ、互いに情報の送受信を行えるようになっている。

ユーザ端末２０は、ＧＰＳ（グローバル・ポジショニング・システム）測位機能等の自端末の測位機能を有している。ユーザ端末２０は、測位機能によって得られた自端末の位置である測位点を示す位置情報をサーバ１０に送信する。位置情報は、例えば、緯度及び経度を示す情報である。ユーザ端末２０を所有するユーザには、予めユーザを特定する情報であるユーザＩＤが付与されており、ユーザ端末２０は、予め記憶した当該ユーザＩＤと共に位置情報をサーバ１０に送信する。ユーザ端末２０による自端末の測位は、継続的に行われ、例えば、定期的（例えば、５分毎）に行われる。ユーザ端末２０からサーバ１０に送信される位置情報は、サーバ１０側でいつ測位された位置に係る位置情報か把握されるようにしておく。例えば、ユーザ端末２０は、位置情報に測位時刻を対応付けてサーバ１０に送信する。あるいは、ユーザ端末２０は、測位する度に位置情報をサーバ１０に送信する。

ユーザ端末２０は、様々なアプリを実行する機能を有している。アプリは、例えば、アプリケーションサーバからユーザ端末２０にダウンロードされてインストールされて利用される。ユーザ端末２０にダウンロードされて利用されるアプリは、ユーザ端末２０のユーザによって選択される。ユーザ端末２０は、自端末２０におけるアプリの利用に係るアプリ利用情報をサーバ１０に送信する。アプリ利用情報は、例えば、利用（実行、起動）されたアプリを特定するアプリＩＤ、当該アプリの利用が開始された時刻である利用開始時刻、及び当該アプリの利用が終了された時刻である利用開始時刻利用終了時刻である。ユーザ端末２０は、例えば、自端末２０においてアプリが利用されるとアプリ利用情報を生成し、ユーザＩＤと共に利用情報をサーバ１０に送信する。利用情報の送信は、例えば、定期的（例えば、１日毎）に行われる。

ユーザ端末２０は、通常の携帯電話機やスマートフォン等と同様にＣＰＵ（Central Processing Unit）、メモリ及び無線通信モジュール等のハードウェアを備えて構成される。

引き続いて、本実施形態に係るサーバ１０の機能を説明する。図１に示すようにサーバ１０は、記憶部１１と、利用情報取得部１２と、地域設定部１３と、利用状態算出部１４と、分類部１５と、推薦部１６とを備えて構成される。

記憶部１１は、サーバ１０における処理に必要となる情報を記憶する記憶手段である。具体的に、記憶部１１が、どのような情報を記憶するについては後述する。

利用情報取得部１２は、ユーザ及びアプリ毎に、アプリが利用された位置を示す利用位置情報を取得する利用情報取得手段である。具体的には、利用情報取得部１２は、利用位置情報として、以下のように位置情報及びアプリ利用情報を取得する。

利用情報取得部１２は、ユーザ端末２０から送信される位置情報を受信して取得する。なお、１つの位置情報は、１つの位置に係るものであるとする。利用情報取得部１２は、取得した位置情報を記憶部１１の測位点テーブルに格納する。図２に測位点テーブルを示す。図２に示すように測位点テーブルは、ユーザＩＤ、経度、緯度及び位置取得時刻が対応付けられた情報を格納する。測位点テーブルの各レコード（１つの行のデータ）が、１つの位置情報に対応する。

ユーザＩＤは、位置情報に係るユーザＩＤ（位置情報と共に送信されるユーザＩＤ）である。経度及び緯度は、位置情報により示される測位点の緯度及び経度である。位置取得時刻は、位置情報により示される測位点が測位された時刻（日時）である。なお、ユーザ端末２０が、測位する度に位置情報をサーバ１０に送信する場合には、利用情報取得部１２が受信した時刻を位置取得時刻としてもよい。

利用情報取得部１２は、ユーザ端末２０から送信されるアプリ利用情報を受信して取得する。なお、１つのアプリ利用情報は、１つのアプリの１回のアプリの利用に係るものであるとする。利用情報取得部１２は、取得したアプリ利用情報を記憶部１１のアプリ利用テーブルに格納する。図３にアプリ利用テーブルを示す。図３に示すようにアプリ利用テーブルは、ユーザＩＤ、アプリＩＤ、利用開始時刻及び利用終了時刻が対応付けられた情報を格納する。アプリ利用テーブルの各レコード（１つの行のデータ）が、１つのアプリ利用情報に対応する。

ユーザＩＤは、アプリ利用情報に係るユーザＩＤ（位置情報と共に送信されるユーザＩＤ）である。アプリＩＤ、利用開始時刻及び利用終了時刻は、アプリ利用情報により示されるアプリＩＤ、利用開始時刻（日時）及び利用終了時刻（日時）である。

上記の通り、位置情報及びアプリ利用情報には、時刻が含まれており、時刻で照合することで、アプリが利用された位置を得ることができる。

地域設定部１３は、ユーザの位置を示す位置情報を取得し、取得した位置情報に基づいて、ユーザ毎に地域を設定する地域設定手段である。設定される地域は、第１の地域である日常圏と、第２の地域である非日常圏とである。

地域設定部１３は、ユーザの位置を示す位置情報として、ユーザ端末２０に係る位置情報を取得する。なお、この位置情報は、利用情報取得部１２によって取得された位置情報、即ち、記憶部１１の測位点テーブルに格納されている位置情報としてもよい。あるいは、利用情報取得部１２による位置情報の取得に先立って、ユーザ端末２０から送信される位置情報を受信して取得してもよい。

地域設定部１３は、例えば、Ｎ日分（Ｎは予め設定された整数値）の位置情報それぞれによって示される位置に基づいて、ユーザが滞留した位置を示す滞留点を算出する。滞留点の算出（抽出）は、時空間でクラスタリングを行うことにより行われる。

ユーザの滞留とは、ユーザがある程度狭い領域に留まっていることであり、即ち、ユーザが所定時間以上、所定の領域内に連続して位置していることである。滞留点は、ユーザが滞留した場合に位置していた領域、又は当該領域を代表する位置である。地域設定部１３は、ユーザＩＤ毎に滞留点を算出する。具体的には、地域設定部１３は、以下のように滞留点を算出する。なお、どの位置情報を用いて滞留点を算出するかは、例えば、位置取得時刻の範囲の指定により、予め設定しておく。

地域設定部１３は、滞留点の算出対象となるユーザＩＤの位置情報について、位置取得時刻が古い順に滞留点の判断を行う。まず、地域設定部１３は、位置取得時刻が最も古い位置情報に示される位置を滞留点の判断の基準位置とする。地域設定部１３は、位置取得時刻が次の位置情報に示される位置と当該基準位置とを比較する。地域設定部１３は、それらの位置の間の距離が、予め設定された滞留点判断用の距離閾値よりも小さいか否かを判断する。地域設定部１３は、当該距離が距離閾値よりも小さいと判断したら、更に次の位置情報に示される位置と当該基準位置とを比較して、上記と同様の距離閾値に基づく判断を行う。地域設定部１３は、距離が距離閾値よりも小さくなくなる（距離が距離閾値以上となる）まで順次判断を行う。

地域設定部１３は、距離が距離閾値よりも小さくなくなる１つ前の位置情報に係る位置取得時刻と、基準位置の位置情報に係る位置取得時刻とを比較する。地域設定部１３は、それらの位置取得時刻の間の時間差が、予め設定された滞留点判断用の時間閾値よりも大きいか否かを判断する。地域設定部１３は、当該時間差が時間閾値よりも大きいと判断したら、それらの位置情報（基準位置の位置情報から距離が距離閾値よりも大きくなる１つ前の位置情報までの位置情報）を、滞留点を構成する位置情報であると判断する。即ち、この場合、地域設定部１３は、滞留点を抽出できると判断する。地域設定部１３は、当該時間差が時間閾値よりも大きくないと判断したら、それらの位置情報（基準位置の位置情報から距離が距離閾値よりも大きくなる１つ前の位置情報までの位置情報）を、滞留点を構成する位置情報ではないと判断する。即ち、この場合、地域設定部１３は、滞留点を抽出できないと判断する。

また、地域設定部１３は、距離が距離閾値よりも小さくなくなった位置情報に示される位置を新たな滞留点の判断の基準位置とし、上記と同様の判断を行う。このように、基準位置から距離閾値までの領域に、時間閾値を超える時間、ユーザが位置していれば滞留点があると判断される。なお、この距離閾値及び時間閾値は、算出の目的等に応じて適宜設定される（以下の閾値等についても同様である）。また、滞留点の判断のための領域は、上記のような基準位置に基づく円形の領域でもよいし、基準位置に基づく矩形（メッシュ）の領域でもよい。

続いて、地域設定部１３は、滞留点を構成するとされた位置情報から、滞留点の緯度及び経度を算出する。滞留点の緯度及び経度は、滞留点を代表する位置であり、例えば、滞留点を構成するとされた位置情報によって示される位置の重心（位置の平均）とすることができる。なお、滞留点の緯度及び経度は、本方法以外で算出されてもよい。

地域設定部１３は、上記のように算出した滞留点に係る情報を記憶部１１の滞留点テーブルに格納する。図４に滞留点テーブルを示す。図４に示すように滞留点テーブルは、ユーザＩＤ、経度、緯度、開始時刻、終了時刻及び滞在時間が対応付けられた情報を格納する。滞留点テーブルの各レコード（１つの行のデータ）が、１つの滞留点に対応する。

ユーザＩＤは、滞留点の情報に係るユーザＩＤである。経度及び緯度は、上記のように地域設定部１３によって算出された滞留点の緯度及び経度である。開始時刻は、当該滞留点での滞留が開始された時刻（日時）であり、滞留点を構成するとされた位置情報のうち最初の位置情報の位置取得時刻である。終了時刻は、当該滞留点での滞留が終了された時刻（日時）であり、滞留点を構成するとされた位置情報のうち最後の位置情報の位置取得時刻である。滞在時間は、ユーザが当該滞留点に滞在した時間であり、終了時刻から開始時刻を引いた時間である。

地域設定部１３は、上記のように算出したユーザＩＤ毎の滞留点を更に空間でクラスタリングして、滞留点クラスタを形成する。このクラスタリングは、ミーンシフト法等の従来の方法によって行われる。地域設定部１３は、Ｘ回以上（Ｘは予め設定した整数値）ユーザが訪問している滞留点クラスタ（滞留点をＸ以上含む滞留点クラスタ）の滞留点クラスタを、日常圏に係る滞留点クラスタとする。あるいは、地域設定部１３は、含まれる滞留点の数が上位Ｙ割（Ｙは予め設定した値）の滞留点クラスタを、日常圏に係る滞留点クラスタとする。地域設定部１３は、当該日常圏に係る滞留点クラスタから、日常圏を設定する。例えば、滞留点クラスタに含まれる滞留点の位置の重心（位置の平均）を算出して、当該重心から、Ｚｋｍ以内（Ｚは予め設定した値）の位置を日常圏とする。あるいは、当該重心から、滞留点クラスタに含まれる滞留点のうち最も遠い滞留点までの距離以内の位置を日常圏とする。

地域設定部１３は、上記のように設定した日常圏以外の位置を非日常圏とする。地域設定部１３は、ユーザＩＤ毎に設定した日常圏及び非日常圏の位置を示す情報を記憶部１１に格納する。地域設定部１３による上記の処理は、例えば、後述する利用状態算出部１４による処理に先立つ、予めサーバ１０の管理者等によって設定されたタイミングで行われる。なお、日常圏でなければ、非日常圏となるので、日常圏及び非日常圏の何れか一方の位置を示す情報のみが格納されていればよい。また、地域設定部１３による位置情報に基づく、日常圏及び非日常圏の設定は、上記の方法以外で行われてもよい。

利用状態算出部１４は、利用情報取得部１２によって取得された位置情報及びアプリ利用情報、即ち、利用位置情報に基づいて、ユーザ毎に設定された地域毎にアプリの利用状態を算出する利用状態算出手段である。利用状態算出部１４は、ユーザ毎の日常圏及び非日常圏毎にアプリの利用状態を算出する。なお、どの位置情報及びアプリ利用情報を用いて利用状態を算出するかは、例えば、位置取得時刻及び開始時刻等の範囲の指定により、予め設定しておく。

利用状態算出部１４は、記憶部１１の測位点テーブルに格納された情報、アプリ利用テーブルに格納された情報、並びに日常圏及び非日常圏の位置を示す情報を参照して利用状態を算出する。利用状態算出部１４は、上記の利用状態として、アプリ毎の日常圏及び非日常圏それぞれにおけるアプリの利用回数をカウントする。

まず、利用状態算出部１４は、時刻の情報に基づき、アプリ利用情報毎に対応する位置情報を特定する。例えば、アプリ利用情報の利用開始時刻から利用終了時刻までの間に位置取得時刻が含まれる位置情報を上記の対応する位置情報とする。複数の位置情報が上記の時間帯に含まれている場合には、例えば、利用開始時刻と利用終了時刻との中間の時刻に最も近い位置取得時刻の位置情報を上記の対応する位置情報とする。一つも位置情報が上記の時間帯に含まれていない場合には、例えば、対応する位置情報がないとしてもよいし、当該時間帯に最も近い位置取得時刻の位置情報を上記の対応する位置情報としてもよい。

利用状態算出部１４は、日常圏及び非日常圏の位置を示す情報を参照して、対応する位置情報によって示される位置が日常圏に含まれるか、非日常圏に含まれるかを判断して、上記のカウントを行う。利用状態算出部１４は、ユーザ毎に対象となる全てのアプリ利用情報を用いて、上記のカウントを行う。利用状態算出部１４は、算出した利用状態であるカウント結果の情報を分類部１５に出力する。即ち、利用状態算出部１４は、ユーザ及びアプリ毎の日常圏及び非日常圏それぞれにおけるアプリの利用回数を示す情報を分類部１５に出力する。利用状態算出部１４による上記の処理は、例えば、アプリを分類するタイミングとして、予めサーバ１０の管理者等によって設定されたタイミングで行われる。

分類部１５は、利用状態算出部１４によって算出された利用状態に基づいて、アプリの分類を行う分類手段である。分類部１５は、日常圏における利用状態を示す値と非日常圏における利用状態を示す値との比に基づいて、アプリの分類を行う。

分類部１５は、利用状態算出部１４によって算出された利用状態を示す情報を入力し、当該情報に基づき、ユーザ及びアプリ毎に非日常度の値として、（Ａｎｉ／Ａｎ）／（Ａｉ／Ａ）の値を算出する。ここで、Ａｉは、日常圏での当該アプリの利用回数である。Ａは、日常圏での全アプリの利用回数である。Ａｎｉは非日常圏での当該アプリの利用回数である。Ａｎは、非日常圏での全アプリの利用回数である。上記の値は、例えば、日毎の値を算出して値を平均することとしてもよい。その場合、利用状態算出部１４によるカウントも日毎に行う。

非日常度は、非日常圏における全アプリの利用に対するアプリの利用の度合いが、日常圏における全アプリの利用に対するアプリの利用の度合いと比べて大きくなるほど大きな値となる。即ち、非日常度は、当該ユーザにとって当該アプリが非日常圏で利用されるものである度合いを示している。日常的に利用するアプリ（例えば、ユーザが日常的に利用しているＳＮＳ（ソーシャル・ネットワーキング・サービス）のアプリ）は日常圏でも非日常圏でも利用回数が多いと考えられる。そのため、非日常圏での利用回数での比較はできず、非日常度を上記のように利用割合から算出している。

分類部１５は、算出した非日常度を記憶部１１のインストールアプリテーブルに格納する。図５にインストールアプリテーブルを示す。インストールアプリテーブルは、各ユーザ端末２０においてどのアプリがインストールされているかを管理するためのものである。図５に示すようにインストールアプリテーブルは、ユーザＩＤ、アプリＩＤ、カテゴリ、非日常度及びインストール時刻が対応付けられた情報を格納する。

ユーザＩＤは、アプリを利用しているユーザのユーザＩＤである。アプリＩＤは、当該アプリ（管理対象となるアプリ）のアプリＩＤである。カテゴリは、当該アプリのカテゴリである。当該カテゴリは、アプリの製作者等によって、アプリに対して予め設定されるものであり、“カメラ”、“エンタメ”といったものである。なお、本実施形態では、アプリが利用される位置に応じて分類されるが、その分類とは異なるものである。非日常度は、分類部１５によって算出された非日常度の値である。インストール時刻は、当該アプリがユーザ端末２０にインストールされた時刻（日時）である。

例えば、ユーザ端末２０は、アプリをインストールすると、その旨の情報をサーバ１０に送信する。サーバ１０は、その情報を受信して、それに応じてインストールアプリテーブルのデータを生成して格納する。従って、分類部１５が算出した非日常度を記憶部１１のインストールアプリテーブルに格納する際には、インストールアプリテーブルには非日常度以外の情報が既に格納されている。

分類部１５は、算出した非日常度が予め設定した閾値未満であれば、当該ユーザにとって当該アプリは、日常使いのアプリであるとし、非日常度が閾値以上であれば、当該ユーザにとって当該アプリは、非日常使いのアプリであるとする。続いて、分類部１５は、アプリ毎に非日常使いのアプリであるとされたユーザの数を集計する。分類部１５は、集計した数を記憶部１１の非日常ランキングテーブルに格納する。図６に非日常ランキングテーブルを示す。図６に示すように非日常ランキングテーブルは、ランキング、アプリＩＤ及び集計数が対応付けられた情報を格納する。

ランキングは、集計数のランキングである。ランキングは、集計数が多い順に１から順に設定される。アプリＩＤは、当該アプリのアプリＩＤである。集計数は、分類部１５によって上記のように集計された数である。分類部１５は、アプリを集計数が多い順に並べて、全アプリに対する予め設定した割合の数の上位のアプリを非日常圏のアプリと分類する。分類部１５は、非日常圏のアプリと分類したアプリを示す情報を記憶部１１に格納する。以上の構成が、アプリを非日常圏のアプリと分類するための構成である。以下の構成が、当該分類を用いてアプリの推薦を行うための構成である。

推薦部１６は、分類部１５によって行われたアプリの分類に基づいて、ユーザへのアプリの推薦を行う推薦手段である。推薦部１６は、ユーザ端末２０から位置情報を受信する。位置情報の受信は、利用情報取得部１２による受信と同様に行われる。推薦部１６は、記憶部１１に格納された当該ユーザ端末２０のユーザの日常圏及び非日常圏の位置を示す情報を参照して、受信した位置情報によって示される位置が非日常圏に含まれるか否かを判断する。即ち、推薦部１６は、当該ユーザが非日常圏に位置しているか否かを判断する。

推薦部１６は、位置情報によって示される位置が非日常圏に含まれる、即ち、ユーザが非日常圏に位置していると判断した場合、当該ユーザに対してアプリの推薦を行うと判断する。なお、ユーザが予め設定した一定時間以上継続して非日常圏に位置している場合に、アプリの推薦を行うこととしてもよい。

この場合、推薦部１６は、図５に示す記憶部１１のインストールアプリテーブルを参照して、当該ユーザ端末２０においてインストール済みのアプリを特定する。推薦部１６は、カテゴリ（例えば、上述した“カメラ”、“エンタメ”といったカテゴリ）別に特定したアプリの数を集計して、当該数のカテゴリのランキングを生成する。ランキングは、集計数が多い順に１から順に設定される。続いて、推薦部１６は、記憶部１１に非日常圏のアプリと分類されたアプリとして記憶されているアプリのうち、当該ユーザ端末２０においてインストールされていないアプリを推薦するアプリの候補とする。推薦部１６は、図６に示す記憶部１１の非日常ランキングテーブルを参照して、候補のアプリそれぞれについて、当該アプリのカテゴリのランキングの値（Ｒｃａｔｅ）と集計数のランキング（非日常圏アプリランキング）の値（Ｒｎｏｎｄａｉｌｙ）とを掛け合せた値（Ｒｃａｔｅ×Ｒｎｏｎｄａｉｌｙ）を算出する。

推薦部１６は、算出した値が小さいものから順に予め設定した数の候補のアプリ（上位アプリ）をユーザに推薦するアプリとする。具体的には、推薦部１６は、おすすめアプリとして当該アプリの情報をユーザ端末２０に送信することで、ユーザにアプリの推薦を行う。ユーザ端末２０では、当該情報の表示等の出力がなされることで、ユーザがおすすめアプリを知ることができる。なお、アプリの推薦の仕方は、上記に限られず、従来と同様の任意の推薦が行われてもよい。また、推薦されるアプリの決定は、必ずしも上記のように行われる必要はなく、非日常圏のアプリとの分類が用いられるものであればどのように行われてもよい。

推薦部１６は、位置情報によって示される位置が非日常圏に含まれない、即ち、ユーザが日常圏に位置していると判断した場合、当該ユーザに対してアプリの推薦を行わないと判断する。この場合、推薦部１６は、特段の処理を行わない。なお、この場合に、推薦部１６は、非日常圏のアプリと分類されなかったアプリをユーザに推薦することとしてもよい。以上が、本実施形態に係るサーバ１０の機能構成である。

図７に本実施形態に係るサーバ１０のハードウェア構成を示す。図７に示すようにサーバ１０は、１つ以上のＣＰＵ１０１、主記憶装置であるＲＡＭ（Random Access Memory）１０２及びＲＯＭ（Read Only Memory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の補助記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述したサーバ１０の機能が発揮される。以上が、本実施形態に係るサーバ１０の構成である。

引き続いて、図８及び図９のフローチャートを用いて、本実施形態に係るサーバ１０で実行される処理（サーバ１０の動作方法）を説明する。まず、図８のフローチャートを用いて、アプリの分類の際に実行される処理を説明する。

本処理では、まず、利用情報取得部１２によって、ユーザ端末２０から送信される位置情報及びアプリ利用情報が受信される（Ｓ０１）。当該受信は、位置情報及びアプリ利用情報が、ユーザ端末２０から送信される度に行われる。続いて、地域設定部１３によって、位置情報が取得され、取得した位置情報に基づいて、ユーザ毎に日常圏及び非日常圏が設定される（Ｓ０２）。続いて、利用情報取得部１２によって取得された位置情報及びアプリ利用情報に基づいて、利用状態算出部１４によって、ユーザ及びアプリ毎の日常圏及び非日常圏それぞれにおけるアプリの利用回数がカウントされる（Ｓ０３）。

続いて、分類部１５によって、日常圏及び非日常圏それぞれにおけるアプリの利用回数に基づいて、各アプリについて日常使いのアプリであるか、非日常使いのアプリであるかが特定される（Ｓ０４）。以上の処理（Ｓ０１〜Ｓ０４）は、ユーザ（ユーザＩＤ）毎に行われる。続いて、分類部１５によって、アプリ毎に非日常使いのアプリであるとされたユーザの数が集計され、集計数に基づいて非日常圏のアプリが分類される（Ｓ０５）。以上が、アプリの分類の際に実行される処理である。

続いて、図９のフローチャートを用いて、上述したアプリの分類が用いられるアプリの推薦の際に実行される処理を説明する。本処理では、まず、推薦部１６によって、ユーザ端末２０から送信される位置情報が受信される（Ｓ１１）。続いて、受信した位置情報によって示される位置が非日常圏に含まれるか否かが判断される（Ｓ１２）。位置が非日常圏に含まれないと判断された場合（Ｓ１２のＮＯ）、特段の処理は行われず、終了する。

位置が非日常圏に含まれると判断された場合（Ｓ１２のＹＥＳ）、続いて、推薦部１６によって、当該ユーザ端末２０においてインストール済みのアプリが特定され、カテゴリ別にアプリの数が集計される（Ｓ１３）。続いて、推薦部１６によって、カテゴリのランキングと非日常アプリの集計数のランキングとに基づいて、非日常圏のアプリと分類されたアプリから、ユーザに推薦されるアプリが決定される（Ｓ１４）。続いて、推薦部１６によって、決定されたアプリのユーザへの推薦が行われる（Ｓ１５）。以上が、アプリの推薦の際に実行される処理である。

上述したように本実施形態では、ユーザ毎に設定された日常圏及び非日常圏毎のアプリの利用状態に基づいてアプリの分類が行われる。従って、日常圏及び非日常圏といった意味的地域に応じて用いられるアプリの分類を行うことができる。即ち、本実施形態によれば、意味的地域を考慮して適切にアプリを分類することができる。

また、本実施形態のように日常圏及び非日常圏といった２つの地域を設定し、それらの地域毎におけるアプリの利用状態を示す値の比に基づいて、アプリの分類を行うこととしてもよい。この構成によれば、上述したようにより適切にアプリを分類することができる。なお、本発明は、地域に応じたアプリの利用状態に基づいて分類を行えばよく、必ずしも上記のように比に基づいた分類を行う必要はない。

また、本実施形態のように位置情報に基づく地域を設定することとしてもよい。この構成によれば、アプリの分類を行うための地域を適切かつ確実に設定することができ、確実かつ適切に本発明を実施することができる。なお、位置情報に基づく地域の設定は必ずしも行う必要はなく、ユーザ等によって予め設定されていてもよい。また、設定される地域は、必ずしも日常圏及び非日常圏でなくてもよく、アプリの利用に影響を及ぼす地域であれば、どのような地域でもよい。

また、本実施形態のようにアプリの推薦を行う構成を有していてもよい。この構成によれば、意味的地域を考慮した高精度なアプリの推薦を行うことができる。但し、この構成は、必ずしも備えられる必要はなく、サーバ１０は、アプリの分類のみを行うものであってもよい。

なお、本実施形態では、本発明に係るアプリケーション分類システムは、サーバ１０であることとしたが、ユーザ端末２０にアプリケーション分類システムに係る機能の一部が備えられていてもよい。即ち、本発明に係る機能が、サーバ１０とユーザ端末２０とに分散して設けられていてもよい。その場合、サーバ１０とユーザ端末２０とを含むシステムが、アプリケーション分類システムを構成する。

また、本実施形態では、日常圏及び非日常圏におけるアプリの利用状態として、アプリの利用回数を用いていたが、アプリの利用時間を用いることとしてもよい。

引き続いて、本実施形態の変形例について説明する。本変形例では、アプリを更に詳細に分類する。具体的には、ユーザの属性及びアプリが利用された状況にも基づいてアプリを分類する。ユーザの属性は、例えば、ユーザの性別、年代である。アプリが利用された状況は、アプリが利用されたＰＯＩ（Point of Interest）、曜日、時間帯、天気である。

本変形例では、ユーザ端末２０は、位置情報と共にユーザの属性及びアプリが利用された状況を示す付加情報をサーバ１０に送信する。ユーザの属性の情報は、例えば、予めユーザ端末２０に記憶されている。アプリが利用された状況の情報は、例えば、位置情報が送信されるタイミングで、ユーザ端末２０において従来技術が用いられて取得される。

サーバ１０では、利用情報取得部１２が、ユーザ端末２０から送信された付加情報を受信する。なお、付加情報は、ユーザ端末２０からサーバ１０に送信されるのではなく、ユーザ端末２０から受信されたユーザＩＤ又は位置情報に基づいて、利用情報取得部１２によって取得されてもよい。例えば、ユーザＩＤとユーザの属性の情報とが対応付けられた情報を予め記憶しておき、それを読み出すこととしてもよい。

利用状態算出部１４及び分類部１５は、利用情報取得部１２によって取得された付加情報にも基づいて、アプリの分類を行う。例えば、位置情報について、付加情報毎の位置情報（全ての付加情報の種別について同じグループとなる付加情報と合わせて送信された位置情報）のみを用いて、上述した実施形態と同様にアプリを分類する。付加情報の種別に応じて、同一のグループとする範囲を予め設定しておく。例えば、ユーザの年齢については、１０歳代、２０歳代…をそれぞれ同一のグループとする。また、推薦部１６による推薦の際も、ユーザ端末２０からユーザの属性及び状況の情報を受信して、当該情報に応じた分類を用いて推薦を行う。

この構成によれば、より詳細なアプリの分類を行うことができる。これにより、ユーザの属性及びアプリが利用される状況に応じた、きめの細かいアプリの推薦を行うことができる。例えば、旅行者向けのご当地アプリ等をうまくユーザに推薦することができる。

１０…サーバ、１１…記憶部、１２…利用情報取得部、１３…地域設定部、１４…利用状態算出部、１５…分類部、１６…推薦部、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置、２０…ユーザ端末、Ｎ…ネットワーク。

Claims (5)

1. ユーザ及びアプリケーション毎に、アプリケーションが利用された位置を示す利用位置情報を取得する利用情報取得手段と、
   前記利用情報取得手段によって取得された利用位置情報に基づいて、ユーザ毎に設定された地域毎にアプリケーションの利用状態を算出する利用状態算出手段と、
   前記利用状態算出手段によって算出された利用状態に基づいて、アプリケーションの分類を行う分類手段と、
   を備えるアプリケーション分類システム。
2. 前記利用状態算出手段は、ユーザ毎の第１の地域及び第２の地域毎にアプリケーションの利用状態を算出し、
   前記分類手段は、前記第１の地域における利用状態を示す値と前記第２の地域における利用状態を示す値との比に基づいて、アプリケーションの分類を行う、請求項１に記載のアプリケーション分類システム。
3. ユーザの位置を示す位置情報を取得し、取得した位置情報に基づいて、前記地域を設定する地域設定手段を更に備える請求項１又は２に記載のアプリケーション分類システム。
4. 前記利用情報取得手段は、前記アプリケーションを利用するユーザの属性及び当該アプリケーションが利用された状況の少なくとも何れかを示す付加情報も取得し、
   前記分類手段は、前記利用情報取得手段によって取得された前記付加情報にも基づいて、アプリケーションの分類を行う請求項１〜３の何れか一項に記載のアプリケーション分類システム。
5. 前記分類手段によって行われたアプリケーションの分類に基づいて、ユーザへのアプリケーションの推薦を行う推薦手段を更に備える請求項１〜４の何れか一項に記載のアプリケーション分類システム。

Images