ユーザにアプリケーションを推薦するサーバ及び方法
【課題】通信網を介してサーバがユーザの通信端末と通信するシステムにおいて、ユーザが複数の通信端末を有する場合に、通信端末各々に相応しいアプリケーション（Ap）を、サーバがユーザに推薦できるようにすること。
【解決手段】複数の通信端末を有する第１のユーザと、何れかの通信端末と同じ仕様の端末を有する第２のユーザとを含む通信ステムにおけるサーバは、各ユーザから、Apの利用履歴情報を受信し、利用履歴情報を集計し、第１のユーザに推薦するApの候補を含むマスターリストを作成し、第１のユーザが使用する或る通信端末の利用傾向又は第２のユーザが使用する端末の利用傾向にしたがって、マスターリストに含まれるApの候補各々について、第１のユーザの各通信端末に推薦する優先度を決定し、優先度に応じて候補を第１のユーザに提示するように、第１のユーザにリコメンド信号を送信する。
【解決手段】複数の通信端末を有する第１のユーザと、何れかの通信端末と同じ仕様の端末を有する第２のユーザとを含む通信ステムにおけるサーバは、各ユーザから、Apの利用履歴情報を受信し、利用履歴情報を集計し、第１のユーザに推薦するApの候補を含むマスターリストを作成し、第１のユーザが使用する或る通信端末の利用傾向又は第２のユーザが使用する端末の利用傾向にしたがって、マスターリストに含まれるApの候補各々について、第１のユーザの各通信端末に推薦する優先度を決定し、優先度に応じて候補を第１のユーザに提示するように、第１のユーザにリコメンド信号を送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザにアプリケーションを推薦するサーバ及び方法に関する。
【背景技術】
【０００２】
近年の通信端末は、単に通信を行うだけでなく、様々なアプリケーションをサーバからダウンロードし、実行することができる。通信端末は、具体的には、携帯電話、情報端末、スマートフォン、ノート型パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等であるが、これらに限定されない。通信端末にダウンロードすることが可能なアプリケーションは、極めて多数存在するので、アプリケーションの提供者（プロバイダ）は、提供するアプリケーションをユーザに推薦する必要がある。通信端末にアプリケーションをダウンロードすることについては、例えば特許文献１に記載されている。
【０００３】
プロバイダがユーザに推薦するアプリケーションを決定する１つの方法は、ユーザ同士の類否を判定し、類似するユーザがダウンロードしているアプリケーションを優先的に推薦することである。例えば、ユーザＡが自身の通信端末にアプリケーション１、２、３、４をダウンロードしており、ユーザＢが自身の通信端末にアプリケーション１、２、Ｐ、Ｑをダウンロードしており、ユーザＣが自身の通信端末にアプリケーションＶ、Ｗをダウンロードしていたとする。プロバイダがユーザＡに推薦するアプリケーションを決定する場合、先ず、ユーザ同士の類否を判定する。ユーザＢは、ユーザＡと同じアプリケーション１及び２を所有しているが、ユーザＣは、ユーザＡと同じアプリケーションを１つも所有していない。したがって、ユーザＡ及びＢは似たような好みの傾向（嗜好）を有し、両者は類似しているが、ユーザＡ及びＣは類似していないことが分かる。こうして、プロバイダは、ユーザＢが所有するアプリケーションの内、ユーザＡが所有していないアプリケーションＰ、Ｑを、ユーザＡに推薦すればよいことが分かる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−３０１４７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、通信端末の普及により、１人のユーザが複数の通信端末を有することもある。この場合において、複数の通信端末に対してユーザアカウントが１つであった場合、プロバイダは、複数の通信端末を有するユーザに対して、それら複数の通信端末を区別せずに、同じアプリケーションを推薦することになる。通常、同一ユーザが所有する複数の端末は、それぞれ異なる製品仕様（ＣＰＵの処理速度、表示画面サイズ等）を有し、動作環境は異なる。このような複数の通信端末に対して、単にユーザが所有していないアプリケーションを一律に推薦しても、そのユーザにとって必ずしも有意義でないことが懸念される。アプリケーションが、ある通信端末では良好に動作するが、別の通信端末では良好に動作しないかもしれないからである。このように、ユーザにアプリケーションを勧める場合、ユーザが使用する通信端末、すなわち動作環境がどのようであるかは、極めて重要な問題である。この点、アプリケーションではない単なるコンテンツをユーザに推薦する場合と事情が異なる。コンテンツを推薦する場合、ユーザの動作環境は、アプリケーションの場合ほど重要ではないからである。
【０００６】
このような通信端末間の相違に配慮する観点からは、同一ユーザが所有する複数の通信端末各々に異なるユーザアカウントを割り当てることが考えられる。しかしながら、ユーザアカウントが異なると、複数の通信端末各々のユーザが異なる場合と同様に管理されてしまう。そもそもユーザの好みの傾向は、そのユーザが所有する複数の通信端末にダウンロードされたアプリケーション全体を考慮することで、適切に突き止めることができる。複数の通信端末各々にダウンロードされた一部のアプリケーションだけから、そのユーザの好みの傾向を適切に読み取ることは容易でない。
【０００７】
したがって、従来の方法では、ユーザが複数の通信端末を有する場合に、通信端末各々に相応しいアプリケーションを適切に推薦できないことが懸念される。
【０００８】
本発明の課題は、通信網を介してサーバがユーザの通信端末と通信するシステムにおいて、ユーザが複数の通信端末を有する場合に、通信端末各々に相応しいアプリケーションを、サーバがユーザに推薦できるようにすることである。
【課題を解決するための手段】
【０００９】
本発明の一形態によるサーバは、
複数の通信端末を有する第１のユーザと、前記複数の通信端末の何れかと同じ仕様の端末を有する第２のユーザとを少なくとも含む通信ステムにおけるサーバであって、
前記通信システムのユーザ各々から、アプリケーションの利用状況を示す利用履歴情報を受信する受信部と、
前記利用履歴情報を集計し、前記第１のユーザに推薦するアプリケーションの候補を含むマスターリストを作成する集計部と、
前記第１のユーザが使用する或る通信端末の利用傾向又は前記第２のユーザが使用する前記端末の利用傾向にしたがって、前記マスターリストに含まれるアプリケーションの候補各々について、前記第１のユーザの各通信端末に推薦する優先度を決定する推薦アプリ決定部と、
前記優先度に応じて前記候補を前記第１のユーザに提示するように、前記第１のユーザにリコメンド信号を送信する送信部と
を有するサーバである。
【発明の効果】
【００１０】
本発明の一形態によれば、通信網を介してサーバがユーザの通信端末と通信するシステムにおいて、ユーザが複数の通信端末を有する場合に、通信端末各々に相応しいアプリケーションを、サーバがユーザに推薦できる。
【図面の簡単な説明】
【００１１】
【図１】実施例で使用される通信システムを示す図。
【図２】通信端末の機能ブロック図。
【図３】配信サーバの機能ブロック図。
【図４】実施例における動作概念図。
【図５】実施例で使用される動作例のフローチャート。
【図６】類似度ｓｉｍ（Ａ，Ｂ）を算出する際の動作例のフローチャート。
【図７】ユーザ全体の利用傾向に基づいて重み付けを行う場合のフローチャート。
【図８】推薦対象ユーザの利用傾向（カテゴリ）に基づいて重み付けを行う場合のフローチャート。
【図９】各通信端末における各カテゴリのアプリケーションの利用率の計算例を示す図。
【図１０】推薦対象ユーザの利用傾向（特徴ベクトル）に基づいて重み付けを行う場合のフローチャート。
【発明を実施するための形態】
【００１２】
以下の観点から実施例を説明する。
【００１３】
１．システム
２．通信端末
３．サーバ
４．動作例
４．１ 動作概要
４．２ 動作フロー
４．３ 重み付けの具体例
４．３．１ ユーザ全体の利用傾向に基づく重み付け
４．３．２ 推薦対象ユーザの利用傾向（カテゴリ）に基づく重み付け
４．３．３ 推薦対象ユーザの利用傾向（特徴ベクトル）に基づく重み付け
【実施例１】
【００１４】
＜１．システム＞
図１は、実施例で使用される通信システム１を示す。通信システム１は、通信端末１０、移動通信網２０、配信サーバ３０及びアプリケーションサーバ４０を有する。通信端末１０は、移動通信網２０を介して配信サーバ３０と通信を行う。配信サーバ３０は必要に応じてアプリケーションサーバ４０と通信する。アプリケーションサーバ４０は、プロバイダが提供可能なアプリケーションを有し、配信サーバ３０からの要請に応じてアプリケーションを提供する。
【００１５】
＜２．通信端末＞
図２は、通信端末１０の機能ブロック図を示す。図２には、通信端末１０に備わる様々な機能要素の内、本実施例に特に関連するものが示されている。通信端末は、配信サーバからアプリケーションをダウンロードして実行することができる適切な如何なる通信端末でもよい。通信端末は、具体的には、携帯電話、情報端末、スマートフォン、ノート型パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等であるが、これらに限定されない。図示の通信端末１０は、受信部１０１、表示部１０２、利用履歴取得部１０３及び送信部１０４を少なくとも有する。
【００１６】
受信部１０１は、移動通信網を介して配信サーバからアプリケーション及びその他の信号を受信する。その他の信号には、例えば、ユーザが何らかのアプリケーションをダウンロードすることを促すリコメンド信号が含まれる。
【００１７】
表示部１０２は、視覚的なユーザインターフェースの機能を果たす。表示部１０２は、具体的には、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機ＥＬパネル等であるが、これらに限定されない。本実施例における表示部１０２は、接触感知式の透明パネルを有するタッチスクリーンを実現し、ユーザの指の動きで画面の表示を制御することができる。表示部１０２は、文字、図形、記号、静止画像、動画像等を表示することができ、例えば、アプリケーションを表すアイコンが画面上に表示される。
【００１８】
表示部１０２のような視覚的なユーザインターフェースだけでなく、他のユーザインターフェースが、通信端末１０に備わっていてもよい。例えば、キーパッド、制御パネル、キーボード、タッチパッド、マウス、トラックボール、マイクロフォン、スピーカ等が備わっていてもよい。
【００１９】
利用履歴取得部１０３は、アプリケーションのダウンロード、起動、削除等を示す利用履歴情報を作成する。例えば、あるアプリケーションがダウンロードされた場合、そのアプリケーション名、ダウンロードの日時が少なくとも利用履歴情報に記録される。さらに、アプリケーションが起動された場合、対象のアプリケーション名、起動した日時、利用した期間、起動回数等が少なくとも利用履歴情報に記録される。アプリケーションが削除された場合、対象のアプリケーション名、削除された日時が少なくとも利用履歴情報に記録される。利用履歴情報は、アプリケーション名、日時、利用時間等に加えて、アプリケーションが使用された場所の情報を含んでもよい。
【００２０】
送信部１０４は、移動通信網を介して配信サーバに信号を送信する。送信される信号は、例えば、上記の利用履歴情報を含む。利用履歴情報は、一定の頻度で配信サーバに報告されてもよいし、ユーザや配信サーバ等からの要求に応じて報告されてもよい。利用履歴情報を一定の頻度で報告する場合の頻度は、例えば、時間、日、週、月等の適切な如何なる頻度でもよい。配信サーバが最新情報を蓄積すること、及び通信端末に保存する利用履歴情報の情報量を少なくする等の観点からは、高い頻度で報告されることが望ましい。ネットワークリソースの有効利用の観点からは、必要に応じて報告されることが望ましい。
【００２１】
＜３．サーバ＞
図３は、配信サーバ３０の機能ブロック図を示す。図３には、配信サーバ３０に備わる様々な機能要素の内、本実施例に特に関連するものが示されている。配信サーバ３０は、アプリケーションサーバ４０に記憶されているアプリケーションを検索し、移動通信網を介して通信端末のユーザにアプリケーションを提供する。図示の配信サーバ３０は、受信部３０１、格納部３０２、利用履歴集計部３０３、ユーザ間類似度算出部３０４、推薦アプリ決定部３０５、メタデータ処理部３０６及び送信部３０７を少なくとも有する。
【００２２】
受信部３０１は、移動通信網を介して通信端末からの信号を受信する。その他の信号には、例えば、利用履歴情報が含まれる。利用履歴情報は、配信サーバ３０に接続されている複数の通信端末各々から受信される。
【００２３】
格納部３０２は、配信サーバで使用されるパラメータ、計算結果、情報を格納する。特に、受信部３０１が各ユーザから受信した利用履歴情報が格納される。
【００２４】
利用履歴集計部３０３は、各ユーザから受信した利用履歴情報に基づいて、特定のユーザに推薦するアプリケーションの候補が列挙されているマスターリストを作成し、格納部３０２に格納する。概して、マスターリストは、特定のユーザ（例えば、ユーザＡ）が自身のどの通信端末にもダウンロードしていないアプリケーションを列挙しているリストである。このリストは、特定のユーザ（ユーザＡ）と似ているユーザ（例えば、ユーザＢ）が、自身の（ユーザＢ）の通信端末にダウンロードしているアプリケーションが優先的に含まれている。
【００２５】
ユーザ間類似度算出部３０４は、ユーザ同士の類似の度合い（類似度）を算出する。ユーザ間の類似度は、適切な如何なる基準で算出されてもよい。例えば、ユーザが自身の通信端末にダウンロードしているアプリケーションが、ユーザ同士の間で共通しているか否かの観点から計算されてもよい。例えば、ユーザＡ及びＢが、ともにダウンロードしているアプリケーションの数が多いほど、両者の類似度は大きい（似ている）。あるいは、アプリケーションを利用する傾向（例えば、使用頻度等）に基づいて、類似度が計算されてもよい。類似度の具体的な計算法については後述する。
【００２６】
推薦アプリ決定部３０５は、複数の通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ２）を有する特定のユーザ（ユーザＡ）に勧めるアプリケーションを、マスターリストの中から選択する。選択は、ユーザＡの通信端末（ＵＥ＿Ａ１）と同様な通信端末を有する他のユーザＸの利用傾向や、ユーザＡの通信端末（ＵＥ＿Ａ２）と同様な通信端末を有する他のユーザＹの利用傾向に基づいて、行われてもよい。あるいは、マスターリストからの選択は、ユーザＡの通信端末（ＵＥ＿Ａ１）の利用傾向や、ユーザＡの別の通信端末（ＵＥ＿Ａ２）の利用傾向に基づいて行われてもよい。なお、ユーザＸが使用する通信端末は、ユーザＡの通信端末（ＵＥ＿Ａ１）と必ずしも同一でなくてもよい。ユーザＡの通信端末（ＵＥ＿Ａ１）と同じ製品仕様にしたがう通信端末のユーザが、ユーザＸに該当する。同様に、ユーザＹが使用する通信端末は、ユーザＡの通信端末（ＵＥ＿Ａ２）と必ずしも同一でなくてもよい。ユーザＡの通信端末（ＵＥ＿Ａ２）と同じ製品仕様にしたがう通信端末のユーザが、ユーザＹに該当する。製品仕様とは、ＣＰＵの処理速度、表示画面のサイズ、オペレーティングシステム等のようなアプリケーションの動作環境に影響する事項である。
【００２７】
推薦アプリ決定部３０５が、マスターリストの候補の中から、推薦するアプリケーションをどのように選択するかについては後述する。
【００２８】
メタデータ処理部３０６は、上述したように、アプリケーションのメタデータから特徴ベクトルを生成する。例えば、乗換案内のアプリケーションの場合、メタデータから、乗換、駅、時刻表等の言葉が特徴的な言葉として抽出され、これらの言葉から特徴ベクトルが作成される。
【００２９】
送信部３０７は、ユーザに勧めることに決まったアプリケーションについて、そのアプリケーションのダウンロードを勧めるリコメンド信号を作成し、ユーザに送信する。
【００３０】
＜４．動作例＞
＜４．１ 動作概要＞
図４は、本実施例における動作を概念的に示す。３人のユーザＡ、Ｂ、Ｃが示されているが、実際には多数のユーザが存在する。ユーザＡは、３台の通信端末を有し、スマートフォンのような情報端末（ＵＥ＿Ａ１）と、別の情報端末（ＵＥ＿Ａ２）と、テレビジョン（ＵＥ＿Ａ３）とを有する。ユーザＢは、２台の通信端末を有し、情報端末（ＵＥ＿Ａ２）と、カーナビゲーション（ＵＥ＿Ｂ１）とを有する。ユーザＣは、３台の通信端末を有し、情報端末（ＵＥ＿Ａ１）と、テレビジョン（ＵＥ＿Ａ３）と、カーナビゲーション（ＵＥ＿Ｂ１）とを有する。
【００３１】
本実施例では、ユーザ毎に複数の通信端末の利用履歴が集約され、不図示の配信サーバに適宜報告される。すなわち、複数の通信端末に対してユーザアカウントは１つである。ただし、後述するように端末各々に応じた重み係数が考慮される。配信サーバ（図４では図示せず）は、ユーザ間の類似度を算出する。図示の例場合、ユーザＡ及びＢ間の類似度はγであり、ユーザＢ及びＣ間の類似度はβであり、ユーザＡ及びＣ間の類似度はαである。配信サーバは、各ユーザの利用履歴に基づいて、例えばユーザＡに対するマスターリストを作成する。
【００３２】
マスターリストは、ユーザＡがダウンロードしていないアプリケーションのリストである。例えば、ユーザＡが自身の通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ２、ＵＥ＿Ａ３）にアプリケーション１、２、３、４をダウンロードしており、ユーザＢが自身の通信端末（ＵＥ＿Ｂ１、ＵＥ＿Ａ２）にアプリケーション１、２、ａ、ｂ、ｃをダウンロードしており、ユーザＣが自身の通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ３、ＵＥ＿Ｂ１）にアプリケーションＶ、Ｗをダウンロードしていたとする。ユーザＢは、ユーザＡと同じアプリケーション１及び２を所有しているが、ユーザＣは、ユーザＡと同じアプリケーションを１つも所有していない。したがって、アプリケーションの類否の観点からは、ユーザＡ及びＢは似たような好みの傾向（嗜好）を有するが、ユーザＡ及びＣは似ていないことが分かる。図示の例の場合、ユーザＡ及びＢは、情報端末（ＵＥ＿Ａ１）及びテレビジョン（ＵＥ＿Ａ３）を有する。ユーザＡ及びＣは、情報端末（ＵＥ＿Ａ２）を有する。したがって、所有している通信端末の類否の観点からも、ユーザＢはユーザＡに似ているが、ユーザＣはユーザＢほどは似ていないことがわかる。このような観点から、ユーザＡに対するマスターリストは、例えば、アプリケーションａ、ｂ、ｃを含むように決定できる。
【００３３】
配信サーバは、マスターリストに含まれるアプリケーションを、ユーザＡに勧める際、ユーザＡ又は他のユーザのアプリケーションの利用傾向に応じて、ユーザＡの特定の通信端末に相応しいアプリケーションの候補を推薦する。
【００３４】
＜４．２ 動作フロー＞
図５は、配信サーバが、マスターリスト中のアプリケーションの候補を、ユーザにどのように勧めるかを示すフローチャートを示す。
【００３５】
ステップＳ５１において、配信サーバは、ある特定のユーザＡの未評価候補ａに対するレートｒ'（Ａ，ａ）を、他のユーザのレートｒ（ｊ，ａ）及びユーザ間類似度ｓｉｍ（Ａ，ｊ）（ユーザＡとユーザｊの類似度）を用いて算出する。未評価候補とは、ユーザＡに対するマスターリストに含まれているアプリケーションの候補の内、０でないレートが未だ推定されていない候補である。配信サーバは、先ず、各ユーザのレーティングベクトル及び類似度を計算する。
【００３６】
図６は、類似度ｓｉｍ（Ａ，Ｂ）を算出する際のフローチャートを示す。ステップＳ６１において、配信サーバのユーザ間類似度算出部３０４は、各ユーザのアプリケーションの利用履歴を端末毎に格納部３０２から収集する。利用履歴の情報は、配信サーバにより適宜受信され、格納部３０２に随時格納されている。例えば、ユーザＡは、複数の通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ３、ＵＥ＿Ｂ１）を有するので、通信端末（ＵＥ＿Ａ１）に対する利用履歴、通信端末（ＵＥ＿Ａ２）に対する利用履歴、及び通信端末（ＵＥ＿Ａ３）に対する利用履歴が収集される。
【００３７】
ステップＳ６２において、配信サーバの利用履歴集計部３０３は、端末毎のアプリケーションの利用履歴を、ユーザ毎の利用履歴に集計する。例えば、ユーザＡの通信端末（ＵＥ＿Ａ１）の利用履歴が、アプリケーションｐを６回起動したことを示し、ユーザＡの通信端末（ＵＥ＿Ａ２）の利用履歴が、アプリケーションｐを４回起動したことを示していたとする。この場合、これらの利用履歴は、ユーザＡがアプリケーションｐを１０回起動したことを示す情報に集約される。
【００３８】
ステップＳ６３において、ユーザ毎にレーティングベクトルが算出される。「ベクトルｒ」により表現されるレーティングベクトルは、Ｍ次元のベクトルである。Ｍは、市場に存在するアプリケーション数を表す。あるいは、Ｍはプロバイダが提供可能なアプリケーション数である。ユーザＡのレーティングベクトル「ベクトルｒＡ」のＭ個の成分は、各成分に対応するアプリケーションをどの程度使用しているかを示し、「レート」と言及される。例えば、上記の例において、ユーザＡは、アプリケーションｐを合計１０回使用している。したがって、ユーザＡのレーティングベクトル「ベクトルｒＡ」のＭ個の成分の内、アプリケーションｐに対応する成分（レート）は、「１０」の値を有する（ｒ（Ａ，ｐ）＝１０）。一例として、市場のアプリケーションが、ｐ、ｑ、ｓ、ｔの４つであったとする（Ｍ＝４）。ユーザＡは、これらの内アプリケーションｐを有し、１０回起動している。他のアプリケーションはダウンロードされていないとする。この場合、ユーザＡのレーティングベクトル「ベクトルｒＡ」は、
（ｒ（Ａ，ｐ），ｒ（Ａ，ｑ），ｒ（Ａ，ｓ），ｒ（Ａ，ｔ））＝（１０，０，０，０）
のように表現することができる。あるいは、使用回数そのものではなく、何らかの値で規格化又は正規化された値が、成分値として設定されてもよい。
【００３９】
ステップＳ６４では、ユーザ各自のレーティングベクトルを用いて、ユーザ同士の類似度が、以下の数式（１）にしたがって算出される。
【００４０】
【数１】
ユーザＡは、マスターリスト中のアプリケーションの候補ａを未だダウンロードしていない。したがって、ユーザＡのレーティングベクトルの候補ａに対するレートｒ（Ａ，ａ）は、０の値をとることになる。本実施例では、このレートｒ（Ａ，ａ）＝０をそのまま使用するのではなく、実際のレートｒ（Ａ，ａ）＝０の代わりに、推定されたレートｒ'（Ａ，ａ）を使用する。推定されたレート（推定レート）ｒ'（Ａ，ａ）は、以下の数式（２）にしたがって算出される。
【００４１】
【数２】
上記の数式を参照すると、ユーザＡと類似しているユーザｊが、アプリケーションａを何回も利用していた場合、推定レートｒ'（Ａ，ａ）は大きくなることが分かる。マスターリストに含まれている全ての候補ａ、ｂ、ｃ、...について、推定レートｒ'（Ａ，ａ）、ｒ'（Ａ，ｂ）、ｒ'（Ａ，ｃ）、...が算出される。
【００４２】
図５のステップＳ５２において、ステップＳ５１で算出された推定レートｒ'（Ａ，ａ）、ｒ'（Ａ，ｂ）、ｒ'（Ａ，ｃ）、...と、後述の重み係数とを用いて、アプリケーションの候補ａ、ｂ、ｃ、...の優先度が決定される。後述するように重み係数及び優先度は、個々の配信先端末に対して相応しい値に設定される点で、従来のアプリケーション推薦方式と大きく異なる。
【００４３】
ステップＳ５３において、優先度の高い順に、候補のアプリケーションがユーザに提示される。これにより、ユーザＡの複数の通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ３、ＵＥ＿Ｂ１）各々の表示画面には、各通信端末に相応しいアプリケーションが、各自に有意義な順序で表示され、ユーザは、優れた推薦機能の恩恵を受けることができる。
【００４４】
＜４．３ 重み付けの具体例＞
上述したように、図５のフローのステップＳ５２では、推定レートｒ'（Ａ，ａ）、ｒ'（Ａ，ｂ）、ｒ'（Ａ，ｃ）、...と、重み係数とを用いて、アプリケーションの候補ａ、ｂ、ｃ、...の優先度が決定される。説明の便宜上、図４に示す例のように、ユーザＡは、３台の通信端末を有し、スマートフォンのような情報端末（ＵＥ＿Ａ１）と、別の情報端末（ＵＥ＿Ａ２）と、テレビジョン（ＵＥ＿Ａ３）とを有するものとする。ユーザＢは、２台の通信端末を有し、情報端末（ＵＥ＿Ａ２）と、カーナビゲーション（ＵＥ＿Ｂ１）とを有するものとする。ユーザＣは、３台の通信端末を有し、情報端末（ＵＥ＿Ａ１）と、テレビジョン（ＵＥ＿Ａ３）と、カーナビゲーション（ＵＥ＿Ｂ１）とを有するものとする。このような状況において、図５のステップＳ５２における重み係数をどのように決定するかを説明する。
【００４５】
＜４．３．１ ユーザ全体の利用傾向に基づく重み付け＞
重み係数を決定する第１の方法は、ユーザ全体の利用傾向を利用することである。図７は、このような重み付けを行うためのフローチャートを示す。ステップＳ７１において、配信サーバの推薦アプリ決定部３０５は、マスターリストに含まれている候補ａについて、ユーザ全体の利用履歴情報を格納部３０２から抽出する。
【００４６】
ステップＳ７２において、抽出された利用履歴情報を端末毎に集計する。
【００４７】
ステップＳ７３において、同様な端末を有するユーザの内、候補のアプリケーションを利用しているユーザが、どの程度の割合であるかを算出する。例えば、候補ａのアプリケーションが、通信端末（ＵＥ＿Ａ１）と同様な端末を有するユーザの内、何人又は何％のユーザにダウンロードされているか（利用率１）、及び通信端末（ＵＥ＿Ａ２）と同様な端末を有するユーザの内、何人又は何％のユーザにダウンロードされているか（利用率２）等が算出される。
【００４８】
例えば、ユーザＡの通信端末（ＵＥ＿Ａ１）と同じ仕様の端末を有するユーザＸが１００人存在し、マスターリストに含まれているアプリケーションの候補ａが、７０人のユーザＸにダウンロードされていたとする。この場合、候補ａに対する利用率１は、７０／１００＝０．７である。さらに、ユーザＡの別の通信端末（ＵＥ＿Ａ２）については、この通信端末（ＵＥ＿Ａ２）と同じ仕様の端末を有する他のユーザＹの利用傾向が利用される。例えば、ユーザＹが５０人存在し、マスターリストに含まれているアプリケーションの候補ａが、５０人中２人のユーザＹにしかダウンロードされていなかったとする。この場合、候補ａに対する利用率２は、２／５０＝０．０４である。
【００４９】
ステップＳ７４において、ステップＳ７２で算出された利用率が、対象のユーザＡの複数の通信端末各々に対する重み係数として設定される。例えば、ユーザＡの通信端末（ＵＥ＿Ａ１）に対する重み係数は、利用率１＝０．７に設定され、ユーザＡの通信端末（ＵＥ＿Ａ２）に対する重み係数は、利用率２＝０．０４に設定される。
【００５０】
このようにして、ユーザＡの通信端末と同じ仕様の端末を有するユーザの利用傾向に基づいて、アプリケーションの候補をユーザＡにどの程度強く推薦するかを適切に決定することができる。
【００５１】
以後、この重み係数と、図５のステップＳ５１で推定したレートとを組み合わせることで、マスターリスト中の候補ａ、ｂ、ｃ、...の優先度を決定する。一例として、重み係数とレートとを乗算することで、優先度が決定されてもよい。例えば、候補ａは、ユーザＡの通信端末（ＵＥ＿Ａ１）に対して、ｒ'（Ａ，ａ）×（利用率１）のように重み付けされる。また、候補ａは、ユーザＡの通信端末（ＵＥ＿Ａ２）に対して、ｒ'（Ａ，ａ）×（利用率２）のように重み付けされる。これらの重み付けの結果に基づいて、各候補の優先度が決定される。
【００５２】
この重み付けの方法によれば、通信端末に適したアプリケーションを推薦することができる。例えば、大画面の表示部を有する通信端末に対して、動画アプリケーションを推薦する一方、携帯電話に対して乗換案内アプリケーションを推薦することができる。
【００５３】
＜４．３．２ 推薦対象ユーザの利用傾向（カテゴリ）に基づく重み付け＞
重み係数を決定する第２の方法は、推薦対象ユーザ（ユーザＡ）の利用傾向を利用することである。
【００５４】
図８は、このような重み付けを行うためのフローチャートを示す。ステップＳ８１において、配信サーバの推薦アプリ決定部３０５は、ユーザＡの利用履歴情報を格納部３０２から抽出する。
【００５５】
ステップＳ８２において、ユーザＡの利用履歴情報が、アプリケーションのカテゴリ毎に集計される。カテゴリとは、ツール、乗換案内、ゲーム等であり、複数のアプリケーションを分類する情報項目である。
【００５６】
ステップＳ８３において、ステップＳ８２における集計結果から、端末毎の利用率を算出する。例えば、ユーザＡが、３つの通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ２、ＵＥ＿Ａ３）にダウンロードしている５０個のアプリケーションのカテゴリが、カテゴリ１（２０個、４０％）、カテゴリ２（１５個、３０％）、カテゴリ３（１０個、２０％）及びカテゴリ４（５個、１０％）であったとする。カテゴリ１のアプリケーションが、通信端末（ＵＥ＿Ａ１）に１０個、通信端末（ＵＥ＿Ａ２）に６個、通信端末（ＵＥ＿Ａ３）に４個ダウンロードされていたとする。この場合、通信端末（ＵＥ＿Ａ１）におけるカテゴリ１のアプリケーションの利用率は、１０／２０＝０．５である。同様に、通信端末（ＵＥ＿Ａ２）におけるカテゴリ１のアプリケーションの利用率は、６／２０＝０．３である。通信端末（ＵＥ＿Ａ３）におけるカテゴリ１のアプリケーションの利用率は、４／２０＝０．２である。
【００５７】
図９は、各通信端末における各カテゴリのアプリケーションの利用率の計算例を示す。カテゴリ１に対する上記の考察は、図９のカテゴリ１の行にまとめられている。図中、割合の列におけるカッコ内の数字は、５０個のアプリケーションの内の幾つであるかを示す。通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ２、ＵＥ＿Ａ３）各々の欄におけるカッコ内の数字が、上記の利用率を示す。
【００５８】
このように、ステップＳ８３では、各カテゴリに対して、通信端末毎の利用率が算出される。
【００５９】
ステップＳ８４では、ステップＳ８３で算出された利用率が、対象のユーザＡの複数の通信端末各々に対する重み係数として設定される。例えば、アプリケーションの候補ａのカテゴリが、カテゴリ２であった場合、通信端末（ＵＥ＿Ａ１）に対する重み係数は、１０／１５＝０．６６７であり、通信端末（ＵＥ＿Ａ２）に対する重み係数は、５／１５＝０．３３４であり、通信端末（ＵＥ＿Ａ３）に対する重み係数は、０である。
【００６０】
このようにして、ユーザＡの各通信端末における利用傾向に基づいて、アプリケーションの候補をユーザＡにどの程度強く推薦するかを適切に決定することができる。
【００６１】
以後、この重み係数と、図５のステップＳ５１で推定したレートとを組み合わせることで、マスターリスト中の候補ａ、ｂ、ｃ、...の優先度を決定する。一例として、重み係数とレートとを乗算することで、優先度が決定されてもよい。例えば、カテゴリ２の候補は、ユーザＡの通信端末（ＵＥ＿Ａ１）に対して、ｒ'（Ａ，ａ）×（０．６６７）のように重み付けされる。カテゴリ２の候補は、ユーザＡの通信端末（ＵＥ＿Ａ２）に対して、ｒ'（Ａ，ａ）×（０．３３４）のように重み付けされる。さらに、カテゴリ２の候補は、ユーザＡの通信端末（ＵＥ＿Ａ３）に対して、ｒ'（Ａ，ａ）×（０）＝０のように重み付けされる。これらの重み付けの結果に基づいて、各候補の優先度が決定される。
【００６２】
この重み付けの方法によれば、ユーザ各自の通信端末の利用用途に合わせてアプリケーションを推薦することができる。例えば、パズルゲームを頻繁に利用している通信端末に対してゲームのアプリケーションを推薦する一方、地図検索アプリケーションを頻繁に利用している通信端末に対して、乗換案内のアプリケーションを推薦することができる。
【００６３】
＜４．３．３ 推薦対象ユーザの利用傾向（特徴ベクトル）に基づく重み付け＞
重み係数を決定する第３の方法は、第２の方法と同様に、推薦対象ユーザ（ユーザＡ）の利用傾向を利用するが、カテゴリの代わりに特徴ベクトルを利用する点が異なる。
【００６４】
図１０は、このような重み付けを行うためのフローチャートを示す。ステップＳ１０１において、配信サーバのメタデータ処理部３０６は、プロバイダが提供可能な全てのアプリケーションのメタデータから、特徴的な単語である特徴語を判別及び抽出し、総数ｎ個の特徴語を決定する。特徴語の抽出は、当該技術分野における適切な如何なる方法により行われてもよい。一例として、ＴＦＩＤＦにより行われてもよい。なお、この場合におけるメタデータとは、アプリケーション名、アプリケーションの説明文等のような、アプリケーションを特徴付ける情報である。
【００６５】
ステップＳ１０２において、メタデータ処理部３０６は、ユーザＡに対するマスターリストに含まれているアプリケーションの候補各々について、特徴ベクトルを生成する。特徴ベクトルは、ｎ次元のベクトルであり、概して、ステップＳ１０１で決定されたｎ個の特徴語を含むか否かを判別することで生成される。
【００６６】
ステップＳ１０３において、メタデータ処理部３０６は、ユーザＡの利用履歴情報に基づいて、ユーザＡの通信端末各々に対する特徴ベクトルを生成する。例えば、ユーザＡの通信端末（ＵＥ＿Ａ１）が、地図検索アプリケーション（Ａｐ１）と、音楽鑑賞用アプリケーション（Ａｐ２）とをダウンロードしていたとする。この場合、２つのアプリケーションＡｐ１及びＡｐ２各々のメタデータを用いて、１つの特徴ベクトルが生成される。同様に、ユーザＡの他の通信端末についても、特徴ベクトルが生成される。
【００６７】
ステップＳ１０４において、ステップＳ１０２で生成されたアプリケーションの候補の特徴ベクトルと、ステップＳ１０３で生成された各端末の特徴ベクトルとの類似度が算出され、その類似度が重み係数として決定される。
【００６８】
このようにして、ユーザＡの通信端末各々における利用傾向に基づいて、アプリケーションの候補をユーザＡにどの程度強く推薦するかを適切に決定することができる。
【００６９】
以後、この重み係数と、図５のステップＳ５１で推定したレートとを組み合わせることで、マスターリスト中の候補ａ、ｂ、ｃ、...の優先度を決定する。一例として、重み係数とレートとを乗算することで、優先度が決定されてもよい。
【００７０】
以上本発明は特定の実施例を参照しながら説明されてきたが、それらは単なる例示に過ぎず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。例えば、本発明は、アプリケーションをユーザに推薦する適切な如何なる移動通信システムに適用されてもよい。例えば本発明は、W−CDMA方式のシステム、HSDPA／HSUPA方式のW−CDMAシステム、LTE方式のシステム、LTE−Advanced方式のシステム、IMT−Advanced方式のシステム、WiMAX、Wi−Fi方式のシステム等に適用されてもよい。発明の理解を促すため具体的な数式を用いて説明がなされたが、特に断りのない限り、それらの数式は単なる一例に過ぎず適切な如何なる数式が使用されてもよい。実施例又は項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。説明の便宜上、本発明の実施例に係る装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。ソフトウェアは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に用意されてもよい。本発明は上記実施例に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。
【符号の説明】
【００７１】
１ 通信システム
１０ 通信端末
１０１ 受信部
１０２ 表示部
１０３ 利用履歴取得部
１０４ 送信部
２０ 移動通信網
３０ 配信サーバ
３０１ 受信部
３０２ 格納部
３０３ 利用履歴集計部
３０４ ユーザ間類似度算出部
３０５ 推薦アプリ決定部
３０６ メタデータ処理部
３０７ 送信部
４０ アプリケーションサーバ
【技術分野】
【０００１】
本発明は、ユーザにアプリケーションを推薦するサーバ及び方法に関する。
【背景技術】
【０００２】
近年の通信端末は、単に通信を行うだけでなく、様々なアプリケーションをサーバからダウンロードし、実行することができる。通信端末は、具体的には、携帯電話、情報端末、スマートフォン、ノート型パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等であるが、これらに限定されない。通信端末にダウンロードすることが可能なアプリケーションは、極めて多数存在するので、アプリケーションの提供者（プロバイダ）は、提供するアプリケーションをユーザに推薦する必要がある。通信端末にアプリケーションをダウンロードすることについては、例えば特許文献１に記載されている。
【０００３】
プロバイダがユーザに推薦するアプリケーションを決定する１つの方法は、ユーザ同士の類否を判定し、類似するユーザがダウンロードしているアプリケーションを優先的に推薦することである。例えば、ユーザＡが自身の通信端末にアプリケーション１、２、３、４をダウンロードしており、ユーザＢが自身の通信端末にアプリケーション１、２、Ｐ、Ｑをダウンロードしており、ユーザＣが自身の通信端末にアプリケーションＶ、Ｗをダウンロードしていたとする。プロバイダがユーザＡに推薦するアプリケーションを決定する場合、先ず、ユーザ同士の類否を判定する。ユーザＢは、ユーザＡと同じアプリケーション１及び２を所有しているが、ユーザＣは、ユーザＡと同じアプリケーションを１つも所有していない。したがって、ユーザＡ及びＢは似たような好みの傾向（嗜好）を有し、両者は類似しているが、ユーザＡ及びＣは類似していないことが分かる。こうして、プロバイダは、ユーザＢが所有するアプリケーションの内、ユーザＡが所有していないアプリケーションＰ、Ｑを、ユーザＡに推薦すればよいことが分かる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−３０１４７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、通信端末の普及により、１人のユーザが複数の通信端末を有することもある。この場合において、複数の通信端末に対してユーザアカウントが１つであった場合、プロバイダは、複数の通信端末を有するユーザに対して、それら複数の通信端末を区別せずに、同じアプリケーションを推薦することになる。通常、同一ユーザが所有する複数の端末は、それぞれ異なる製品仕様（ＣＰＵの処理速度、表示画面サイズ等）を有し、動作環境は異なる。このような複数の通信端末に対して、単にユーザが所有していないアプリケーションを一律に推薦しても、そのユーザにとって必ずしも有意義でないことが懸念される。アプリケーションが、ある通信端末では良好に動作するが、別の通信端末では良好に動作しないかもしれないからである。このように、ユーザにアプリケーションを勧める場合、ユーザが使用する通信端末、すなわち動作環境がどのようであるかは、極めて重要な問題である。この点、アプリケーションではない単なるコンテンツをユーザに推薦する場合と事情が異なる。コンテンツを推薦する場合、ユーザの動作環境は、アプリケーションの場合ほど重要ではないからである。
【０００６】
このような通信端末間の相違に配慮する観点からは、同一ユーザが所有する複数の通信端末各々に異なるユーザアカウントを割り当てることが考えられる。しかしながら、ユーザアカウントが異なると、複数の通信端末各々のユーザが異なる場合と同様に管理されてしまう。そもそもユーザの好みの傾向は、そのユーザが所有する複数の通信端末にダウンロードされたアプリケーション全体を考慮することで、適切に突き止めることができる。複数の通信端末各々にダウンロードされた一部のアプリケーションだけから、そのユーザの好みの傾向を適切に読み取ることは容易でない。
【０００７】
したがって、従来の方法では、ユーザが複数の通信端末を有する場合に、通信端末各々に相応しいアプリケーションを適切に推薦できないことが懸念される。
【０００８】
本発明の課題は、通信網を介してサーバがユーザの通信端末と通信するシステムにおいて、ユーザが複数の通信端末を有する場合に、通信端末各々に相応しいアプリケーションを、サーバがユーザに推薦できるようにすることである。
【課題を解決するための手段】
【０００９】
本発明の一形態によるサーバは、
複数の通信端末を有する第１のユーザと、前記複数の通信端末の何れかと同じ仕様の端末を有する第２のユーザとを少なくとも含む通信ステムにおけるサーバであって、
前記通信システムのユーザ各々から、アプリケーションの利用状況を示す利用履歴情報を受信する受信部と、
前記利用履歴情報を集計し、前記第１のユーザに推薦するアプリケーションの候補を含むマスターリストを作成する集計部と、
前記第１のユーザが使用する或る通信端末の利用傾向又は前記第２のユーザが使用する前記端末の利用傾向にしたがって、前記マスターリストに含まれるアプリケーションの候補各々について、前記第１のユーザの各通信端末に推薦する優先度を決定する推薦アプリ決定部と、
前記優先度に応じて前記候補を前記第１のユーザに提示するように、前記第１のユーザにリコメンド信号を送信する送信部と
を有するサーバである。
【発明の効果】
【００１０】
本発明の一形態によれば、通信網を介してサーバがユーザの通信端末と通信するシステムにおいて、ユーザが複数の通信端末を有する場合に、通信端末各々に相応しいアプリケーションを、サーバがユーザに推薦できる。
【図面の簡単な説明】
【００１１】
【図１】実施例で使用される通信システムを示す図。
【図２】通信端末の機能ブロック図。
【図３】配信サーバの機能ブロック図。
【図４】実施例における動作概念図。
【図５】実施例で使用される動作例のフローチャート。
【図６】類似度ｓｉｍ（Ａ，Ｂ）を算出する際の動作例のフローチャート。
【図７】ユーザ全体の利用傾向に基づいて重み付けを行う場合のフローチャート。
【図８】推薦対象ユーザの利用傾向（カテゴリ）に基づいて重み付けを行う場合のフローチャート。
【図９】各通信端末における各カテゴリのアプリケーションの利用率の計算例を示す図。
【図１０】推薦対象ユーザの利用傾向（特徴ベクトル）に基づいて重み付けを行う場合のフローチャート。
【発明を実施するための形態】
【００１２】
以下の観点から実施例を説明する。
【００１３】
１．システム
２．通信端末
３．サーバ
４．動作例
４．１ 動作概要
４．２ 動作フロー
４．３ 重み付けの具体例
４．３．１ ユーザ全体の利用傾向に基づく重み付け
４．３．２ 推薦対象ユーザの利用傾向（カテゴリ）に基づく重み付け
４．３．３ 推薦対象ユーザの利用傾向（特徴ベクトル）に基づく重み付け
【実施例１】
【００１４】
＜１．システム＞
図１は、実施例で使用される通信システム１を示す。通信システム１は、通信端末１０、移動通信網２０、配信サーバ３０及びアプリケーションサーバ４０を有する。通信端末１０は、移動通信網２０を介して配信サーバ３０と通信を行う。配信サーバ３０は必要に応じてアプリケーションサーバ４０と通信する。アプリケーションサーバ４０は、プロバイダが提供可能なアプリケーションを有し、配信サーバ３０からの要請に応じてアプリケーションを提供する。
【００１５】
＜２．通信端末＞
図２は、通信端末１０の機能ブロック図を示す。図２には、通信端末１０に備わる様々な機能要素の内、本実施例に特に関連するものが示されている。通信端末は、配信サーバからアプリケーションをダウンロードして実行することができる適切な如何なる通信端末でもよい。通信端末は、具体的には、携帯電話、情報端末、スマートフォン、ノート型パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等であるが、これらに限定されない。図示の通信端末１０は、受信部１０１、表示部１０２、利用履歴取得部１０３及び送信部１０４を少なくとも有する。
【００１６】
受信部１０１は、移動通信網を介して配信サーバからアプリケーション及びその他の信号を受信する。その他の信号には、例えば、ユーザが何らかのアプリケーションをダウンロードすることを促すリコメンド信号が含まれる。
【００１７】
表示部１０２は、視覚的なユーザインターフェースの機能を果たす。表示部１０２は、具体的には、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機ＥＬパネル等であるが、これらに限定されない。本実施例における表示部１０２は、接触感知式の透明パネルを有するタッチスクリーンを実現し、ユーザの指の動きで画面の表示を制御することができる。表示部１０２は、文字、図形、記号、静止画像、動画像等を表示することができ、例えば、アプリケーションを表すアイコンが画面上に表示される。
【００１８】
表示部１０２のような視覚的なユーザインターフェースだけでなく、他のユーザインターフェースが、通信端末１０に備わっていてもよい。例えば、キーパッド、制御パネル、キーボード、タッチパッド、マウス、トラックボール、マイクロフォン、スピーカ等が備わっていてもよい。
【００１９】
利用履歴取得部１０３は、アプリケーションのダウンロード、起動、削除等を示す利用履歴情報を作成する。例えば、あるアプリケーションがダウンロードされた場合、そのアプリケーション名、ダウンロードの日時が少なくとも利用履歴情報に記録される。さらに、アプリケーションが起動された場合、対象のアプリケーション名、起動した日時、利用した期間、起動回数等が少なくとも利用履歴情報に記録される。アプリケーションが削除された場合、対象のアプリケーション名、削除された日時が少なくとも利用履歴情報に記録される。利用履歴情報は、アプリケーション名、日時、利用時間等に加えて、アプリケーションが使用された場所の情報を含んでもよい。
【００２０】
送信部１０４は、移動通信網を介して配信サーバに信号を送信する。送信される信号は、例えば、上記の利用履歴情報を含む。利用履歴情報は、一定の頻度で配信サーバに報告されてもよいし、ユーザや配信サーバ等からの要求に応じて報告されてもよい。利用履歴情報を一定の頻度で報告する場合の頻度は、例えば、時間、日、週、月等の適切な如何なる頻度でもよい。配信サーバが最新情報を蓄積すること、及び通信端末に保存する利用履歴情報の情報量を少なくする等の観点からは、高い頻度で報告されることが望ましい。ネットワークリソースの有効利用の観点からは、必要に応じて報告されることが望ましい。
【００２１】
＜３．サーバ＞
図３は、配信サーバ３０の機能ブロック図を示す。図３には、配信サーバ３０に備わる様々な機能要素の内、本実施例に特に関連するものが示されている。配信サーバ３０は、アプリケーションサーバ４０に記憶されているアプリケーションを検索し、移動通信網を介して通信端末のユーザにアプリケーションを提供する。図示の配信サーバ３０は、受信部３０１、格納部３０２、利用履歴集計部３０３、ユーザ間類似度算出部３０４、推薦アプリ決定部３０５、メタデータ処理部３０６及び送信部３０７を少なくとも有する。
【００２２】
受信部３０１は、移動通信網を介して通信端末からの信号を受信する。その他の信号には、例えば、利用履歴情報が含まれる。利用履歴情報は、配信サーバ３０に接続されている複数の通信端末各々から受信される。
【００２３】
格納部３０２は、配信サーバで使用されるパラメータ、計算結果、情報を格納する。特に、受信部３０１が各ユーザから受信した利用履歴情報が格納される。
【００２４】
利用履歴集計部３０３は、各ユーザから受信した利用履歴情報に基づいて、特定のユーザに推薦するアプリケーションの候補が列挙されているマスターリストを作成し、格納部３０２に格納する。概して、マスターリストは、特定のユーザ（例えば、ユーザＡ）が自身のどの通信端末にもダウンロードしていないアプリケーションを列挙しているリストである。このリストは、特定のユーザ（ユーザＡ）と似ているユーザ（例えば、ユーザＢ）が、自身の（ユーザＢ）の通信端末にダウンロードしているアプリケーションが優先的に含まれている。
【００２５】
ユーザ間類似度算出部３０４は、ユーザ同士の類似の度合い（類似度）を算出する。ユーザ間の類似度は、適切な如何なる基準で算出されてもよい。例えば、ユーザが自身の通信端末にダウンロードしているアプリケーションが、ユーザ同士の間で共通しているか否かの観点から計算されてもよい。例えば、ユーザＡ及びＢが、ともにダウンロードしているアプリケーションの数が多いほど、両者の類似度は大きい（似ている）。あるいは、アプリケーションを利用する傾向（例えば、使用頻度等）に基づいて、類似度が計算されてもよい。類似度の具体的な計算法については後述する。
【００２６】
推薦アプリ決定部３０５は、複数の通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ２）を有する特定のユーザ（ユーザＡ）に勧めるアプリケーションを、マスターリストの中から選択する。選択は、ユーザＡの通信端末（ＵＥ＿Ａ１）と同様な通信端末を有する他のユーザＸの利用傾向や、ユーザＡの通信端末（ＵＥ＿Ａ２）と同様な通信端末を有する他のユーザＹの利用傾向に基づいて、行われてもよい。あるいは、マスターリストからの選択は、ユーザＡの通信端末（ＵＥ＿Ａ１）の利用傾向や、ユーザＡの別の通信端末（ＵＥ＿Ａ２）の利用傾向に基づいて行われてもよい。なお、ユーザＸが使用する通信端末は、ユーザＡの通信端末（ＵＥ＿Ａ１）と必ずしも同一でなくてもよい。ユーザＡの通信端末（ＵＥ＿Ａ１）と同じ製品仕様にしたがう通信端末のユーザが、ユーザＸに該当する。同様に、ユーザＹが使用する通信端末は、ユーザＡの通信端末（ＵＥ＿Ａ２）と必ずしも同一でなくてもよい。ユーザＡの通信端末（ＵＥ＿Ａ２）と同じ製品仕様にしたがう通信端末のユーザが、ユーザＹに該当する。製品仕様とは、ＣＰＵの処理速度、表示画面のサイズ、オペレーティングシステム等のようなアプリケーションの動作環境に影響する事項である。
【００２７】
推薦アプリ決定部３０５が、マスターリストの候補の中から、推薦するアプリケーションをどのように選択するかについては後述する。
【００２８】
メタデータ処理部３０６は、上述したように、アプリケーションのメタデータから特徴ベクトルを生成する。例えば、乗換案内のアプリケーションの場合、メタデータから、乗換、駅、時刻表等の言葉が特徴的な言葉として抽出され、これらの言葉から特徴ベクトルが作成される。
【００２９】
送信部３０７は、ユーザに勧めることに決まったアプリケーションについて、そのアプリケーションのダウンロードを勧めるリコメンド信号を作成し、ユーザに送信する。
【００３０】
＜４．動作例＞
＜４．１ 動作概要＞
図４は、本実施例における動作を概念的に示す。３人のユーザＡ、Ｂ、Ｃが示されているが、実際には多数のユーザが存在する。ユーザＡは、３台の通信端末を有し、スマートフォンのような情報端末（ＵＥ＿Ａ１）と、別の情報端末（ＵＥ＿Ａ２）と、テレビジョン（ＵＥ＿Ａ３）とを有する。ユーザＢは、２台の通信端末を有し、情報端末（ＵＥ＿Ａ２）と、カーナビゲーション（ＵＥ＿Ｂ１）とを有する。ユーザＣは、３台の通信端末を有し、情報端末（ＵＥ＿Ａ１）と、テレビジョン（ＵＥ＿Ａ３）と、カーナビゲーション（ＵＥ＿Ｂ１）とを有する。
【００３１】
本実施例では、ユーザ毎に複数の通信端末の利用履歴が集約され、不図示の配信サーバに適宜報告される。すなわち、複数の通信端末に対してユーザアカウントは１つである。ただし、後述するように端末各々に応じた重み係数が考慮される。配信サーバ（図４では図示せず）は、ユーザ間の類似度を算出する。図示の例場合、ユーザＡ及びＢ間の類似度はγであり、ユーザＢ及びＣ間の類似度はβであり、ユーザＡ及びＣ間の類似度はαである。配信サーバは、各ユーザの利用履歴に基づいて、例えばユーザＡに対するマスターリストを作成する。
【００３２】
マスターリストは、ユーザＡがダウンロードしていないアプリケーションのリストである。例えば、ユーザＡが自身の通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ２、ＵＥ＿Ａ３）にアプリケーション１、２、３、４をダウンロードしており、ユーザＢが自身の通信端末（ＵＥ＿Ｂ１、ＵＥ＿Ａ２）にアプリケーション１、２、ａ、ｂ、ｃをダウンロードしており、ユーザＣが自身の通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ３、ＵＥ＿Ｂ１）にアプリケーションＶ、Ｗをダウンロードしていたとする。ユーザＢは、ユーザＡと同じアプリケーション１及び２を所有しているが、ユーザＣは、ユーザＡと同じアプリケーションを１つも所有していない。したがって、アプリケーションの類否の観点からは、ユーザＡ及びＢは似たような好みの傾向（嗜好）を有するが、ユーザＡ及びＣは似ていないことが分かる。図示の例の場合、ユーザＡ及びＢは、情報端末（ＵＥ＿Ａ１）及びテレビジョン（ＵＥ＿Ａ３）を有する。ユーザＡ及びＣは、情報端末（ＵＥ＿Ａ２）を有する。したがって、所有している通信端末の類否の観点からも、ユーザＢはユーザＡに似ているが、ユーザＣはユーザＢほどは似ていないことがわかる。このような観点から、ユーザＡに対するマスターリストは、例えば、アプリケーションａ、ｂ、ｃを含むように決定できる。
【００３３】
配信サーバは、マスターリストに含まれるアプリケーションを、ユーザＡに勧める際、ユーザＡ又は他のユーザのアプリケーションの利用傾向に応じて、ユーザＡの特定の通信端末に相応しいアプリケーションの候補を推薦する。
【００３４】
＜４．２ 動作フロー＞
図５は、配信サーバが、マスターリスト中のアプリケーションの候補を、ユーザにどのように勧めるかを示すフローチャートを示す。
【００３５】
ステップＳ５１において、配信サーバは、ある特定のユーザＡの未評価候補ａに対するレートｒ'（Ａ，ａ）を、他のユーザのレートｒ（ｊ，ａ）及びユーザ間類似度ｓｉｍ（Ａ，ｊ）（ユーザＡとユーザｊの類似度）を用いて算出する。未評価候補とは、ユーザＡに対するマスターリストに含まれているアプリケーションの候補の内、０でないレートが未だ推定されていない候補である。配信サーバは、先ず、各ユーザのレーティングベクトル及び類似度を計算する。
【００３６】
図６は、類似度ｓｉｍ（Ａ，Ｂ）を算出する際のフローチャートを示す。ステップＳ６１において、配信サーバのユーザ間類似度算出部３０４は、各ユーザのアプリケーションの利用履歴を端末毎に格納部３０２から収集する。利用履歴の情報は、配信サーバにより適宜受信され、格納部３０２に随時格納されている。例えば、ユーザＡは、複数の通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ３、ＵＥ＿Ｂ１）を有するので、通信端末（ＵＥ＿Ａ１）に対する利用履歴、通信端末（ＵＥ＿Ａ２）に対する利用履歴、及び通信端末（ＵＥ＿Ａ３）に対する利用履歴が収集される。
【００３７】
ステップＳ６２において、配信サーバの利用履歴集計部３０３は、端末毎のアプリケーションの利用履歴を、ユーザ毎の利用履歴に集計する。例えば、ユーザＡの通信端末（ＵＥ＿Ａ１）の利用履歴が、アプリケーションｐを６回起動したことを示し、ユーザＡの通信端末（ＵＥ＿Ａ２）の利用履歴が、アプリケーションｐを４回起動したことを示していたとする。この場合、これらの利用履歴は、ユーザＡがアプリケーションｐを１０回起動したことを示す情報に集約される。
【００３８】
ステップＳ６３において、ユーザ毎にレーティングベクトルが算出される。「ベクトルｒ」により表現されるレーティングベクトルは、Ｍ次元のベクトルである。Ｍは、市場に存在するアプリケーション数を表す。あるいは、Ｍはプロバイダが提供可能なアプリケーション数である。ユーザＡのレーティングベクトル「ベクトルｒＡ」のＭ個の成分は、各成分に対応するアプリケーションをどの程度使用しているかを示し、「レート」と言及される。例えば、上記の例において、ユーザＡは、アプリケーションｐを合計１０回使用している。したがって、ユーザＡのレーティングベクトル「ベクトルｒＡ」のＭ個の成分の内、アプリケーションｐに対応する成分（レート）は、「１０」の値を有する（ｒ（Ａ，ｐ）＝１０）。一例として、市場のアプリケーションが、ｐ、ｑ、ｓ、ｔの４つであったとする（Ｍ＝４）。ユーザＡは、これらの内アプリケーションｐを有し、１０回起動している。他のアプリケーションはダウンロードされていないとする。この場合、ユーザＡのレーティングベクトル「ベクトルｒＡ」は、
（ｒ（Ａ，ｐ），ｒ（Ａ，ｑ），ｒ（Ａ，ｓ），ｒ（Ａ，ｔ））＝（１０，０，０，０）
のように表現することができる。あるいは、使用回数そのものではなく、何らかの値で規格化又は正規化された値が、成分値として設定されてもよい。
【００３９】
ステップＳ６４では、ユーザ各自のレーティングベクトルを用いて、ユーザ同士の類似度が、以下の数式（１）にしたがって算出される。
【００４０】
【数１】
ユーザＡは、マスターリスト中のアプリケーションの候補ａを未だダウンロードしていない。したがって、ユーザＡのレーティングベクトルの候補ａに対するレートｒ（Ａ，ａ）は、０の値をとることになる。本実施例では、このレートｒ（Ａ，ａ）＝０をそのまま使用するのではなく、実際のレートｒ（Ａ，ａ）＝０の代わりに、推定されたレートｒ'（Ａ，ａ）を使用する。推定されたレート（推定レート）ｒ'（Ａ，ａ）は、以下の数式（２）にしたがって算出される。
【００４１】
【数２】
上記の数式を参照すると、ユーザＡと類似しているユーザｊが、アプリケーションａを何回も利用していた場合、推定レートｒ'（Ａ，ａ）は大きくなることが分かる。マスターリストに含まれている全ての候補ａ、ｂ、ｃ、...について、推定レートｒ'（Ａ，ａ）、ｒ'（Ａ，ｂ）、ｒ'（Ａ，ｃ）、...が算出される。
【００４２】
図５のステップＳ５２において、ステップＳ５１で算出された推定レートｒ'（Ａ，ａ）、ｒ'（Ａ，ｂ）、ｒ'（Ａ，ｃ）、...と、後述の重み係数とを用いて、アプリケーションの候補ａ、ｂ、ｃ、...の優先度が決定される。後述するように重み係数及び優先度は、個々の配信先端末に対して相応しい値に設定される点で、従来のアプリケーション推薦方式と大きく異なる。
【００４３】
ステップＳ５３において、優先度の高い順に、候補のアプリケーションがユーザに提示される。これにより、ユーザＡの複数の通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ３、ＵＥ＿Ｂ１）各々の表示画面には、各通信端末に相応しいアプリケーションが、各自に有意義な順序で表示され、ユーザは、優れた推薦機能の恩恵を受けることができる。
【００４４】
＜４．３ 重み付けの具体例＞
上述したように、図５のフローのステップＳ５２では、推定レートｒ'（Ａ，ａ）、ｒ'（Ａ，ｂ）、ｒ'（Ａ，ｃ）、...と、重み係数とを用いて、アプリケーションの候補ａ、ｂ、ｃ、...の優先度が決定される。説明の便宜上、図４に示す例のように、ユーザＡは、３台の通信端末を有し、スマートフォンのような情報端末（ＵＥ＿Ａ１）と、別の情報端末（ＵＥ＿Ａ２）と、テレビジョン（ＵＥ＿Ａ３）とを有するものとする。ユーザＢは、２台の通信端末を有し、情報端末（ＵＥ＿Ａ２）と、カーナビゲーション（ＵＥ＿Ｂ１）とを有するものとする。ユーザＣは、３台の通信端末を有し、情報端末（ＵＥ＿Ａ１）と、テレビジョン（ＵＥ＿Ａ３）と、カーナビゲーション（ＵＥ＿Ｂ１）とを有するものとする。このような状況において、図５のステップＳ５２における重み係数をどのように決定するかを説明する。
【００４５】
＜４．３．１ ユーザ全体の利用傾向に基づく重み付け＞
重み係数を決定する第１の方法は、ユーザ全体の利用傾向を利用することである。図７は、このような重み付けを行うためのフローチャートを示す。ステップＳ７１において、配信サーバの推薦アプリ決定部３０５は、マスターリストに含まれている候補ａについて、ユーザ全体の利用履歴情報を格納部３０２から抽出する。
【００４６】
ステップＳ７２において、抽出された利用履歴情報を端末毎に集計する。
【００４７】
ステップＳ７３において、同様な端末を有するユーザの内、候補のアプリケーションを利用しているユーザが、どの程度の割合であるかを算出する。例えば、候補ａのアプリケーションが、通信端末（ＵＥ＿Ａ１）と同様な端末を有するユーザの内、何人又は何％のユーザにダウンロードされているか（利用率１）、及び通信端末（ＵＥ＿Ａ２）と同様な端末を有するユーザの内、何人又は何％のユーザにダウンロードされているか（利用率２）等が算出される。
【００４８】
例えば、ユーザＡの通信端末（ＵＥ＿Ａ１）と同じ仕様の端末を有するユーザＸが１００人存在し、マスターリストに含まれているアプリケーションの候補ａが、７０人のユーザＸにダウンロードされていたとする。この場合、候補ａに対する利用率１は、７０／１００＝０．７である。さらに、ユーザＡの別の通信端末（ＵＥ＿Ａ２）については、この通信端末（ＵＥ＿Ａ２）と同じ仕様の端末を有する他のユーザＹの利用傾向が利用される。例えば、ユーザＹが５０人存在し、マスターリストに含まれているアプリケーションの候補ａが、５０人中２人のユーザＹにしかダウンロードされていなかったとする。この場合、候補ａに対する利用率２は、２／５０＝０．０４である。
【００４９】
ステップＳ７４において、ステップＳ７２で算出された利用率が、対象のユーザＡの複数の通信端末各々に対する重み係数として設定される。例えば、ユーザＡの通信端末（ＵＥ＿Ａ１）に対する重み係数は、利用率１＝０．７に設定され、ユーザＡの通信端末（ＵＥ＿Ａ２）に対する重み係数は、利用率２＝０．０４に設定される。
【００５０】
このようにして、ユーザＡの通信端末と同じ仕様の端末を有するユーザの利用傾向に基づいて、アプリケーションの候補をユーザＡにどの程度強く推薦するかを適切に決定することができる。
【００５１】
以後、この重み係数と、図５のステップＳ５１で推定したレートとを組み合わせることで、マスターリスト中の候補ａ、ｂ、ｃ、...の優先度を決定する。一例として、重み係数とレートとを乗算することで、優先度が決定されてもよい。例えば、候補ａは、ユーザＡの通信端末（ＵＥ＿Ａ１）に対して、ｒ'（Ａ，ａ）×（利用率１）のように重み付けされる。また、候補ａは、ユーザＡの通信端末（ＵＥ＿Ａ２）に対して、ｒ'（Ａ，ａ）×（利用率２）のように重み付けされる。これらの重み付けの結果に基づいて、各候補の優先度が決定される。
【００５２】
この重み付けの方法によれば、通信端末に適したアプリケーションを推薦することができる。例えば、大画面の表示部を有する通信端末に対して、動画アプリケーションを推薦する一方、携帯電話に対して乗換案内アプリケーションを推薦することができる。
【００５３】
＜４．３．２ 推薦対象ユーザの利用傾向（カテゴリ）に基づく重み付け＞
重み係数を決定する第２の方法は、推薦対象ユーザ（ユーザＡ）の利用傾向を利用することである。
【００５４】
図８は、このような重み付けを行うためのフローチャートを示す。ステップＳ８１において、配信サーバの推薦アプリ決定部３０５は、ユーザＡの利用履歴情報を格納部３０２から抽出する。
【００５５】
ステップＳ８２において、ユーザＡの利用履歴情報が、アプリケーションのカテゴリ毎に集計される。カテゴリとは、ツール、乗換案内、ゲーム等であり、複数のアプリケーションを分類する情報項目である。
【００５６】
ステップＳ８３において、ステップＳ８２における集計結果から、端末毎の利用率を算出する。例えば、ユーザＡが、３つの通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ２、ＵＥ＿Ａ３）にダウンロードしている５０個のアプリケーションのカテゴリが、カテゴリ１（２０個、４０％）、カテゴリ２（１５個、３０％）、カテゴリ３（１０個、２０％）及びカテゴリ４（５個、１０％）であったとする。カテゴリ１のアプリケーションが、通信端末（ＵＥ＿Ａ１）に１０個、通信端末（ＵＥ＿Ａ２）に６個、通信端末（ＵＥ＿Ａ３）に４個ダウンロードされていたとする。この場合、通信端末（ＵＥ＿Ａ１）におけるカテゴリ１のアプリケーションの利用率は、１０／２０＝０．５である。同様に、通信端末（ＵＥ＿Ａ２）におけるカテゴリ１のアプリケーションの利用率は、６／２０＝０．３である。通信端末（ＵＥ＿Ａ３）におけるカテゴリ１のアプリケーションの利用率は、４／２０＝０．２である。
【００５７】
図９は、各通信端末における各カテゴリのアプリケーションの利用率の計算例を示す。カテゴリ１に対する上記の考察は、図９のカテゴリ１の行にまとめられている。図中、割合の列におけるカッコ内の数字は、５０個のアプリケーションの内の幾つであるかを示す。通信端末（ＵＥ＿Ａ１、ＵＥ＿Ａ２、ＵＥ＿Ａ３）各々の欄におけるカッコ内の数字が、上記の利用率を示す。
【００５８】
このように、ステップＳ８３では、各カテゴリに対して、通信端末毎の利用率が算出される。
【００５９】
ステップＳ８４では、ステップＳ８３で算出された利用率が、対象のユーザＡの複数の通信端末各々に対する重み係数として設定される。例えば、アプリケーションの候補ａのカテゴリが、カテゴリ２であった場合、通信端末（ＵＥ＿Ａ１）に対する重み係数は、１０／１５＝０．６６７であり、通信端末（ＵＥ＿Ａ２）に対する重み係数は、５／１５＝０．３３４であり、通信端末（ＵＥ＿Ａ３）に対する重み係数は、０である。
【００６０】
このようにして、ユーザＡの各通信端末における利用傾向に基づいて、アプリケーションの候補をユーザＡにどの程度強く推薦するかを適切に決定することができる。
【００６１】
以後、この重み係数と、図５のステップＳ５１で推定したレートとを組み合わせることで、マスターリスト中の候補ａ、ｂ、ｃ、...の優先度を決定する。一例として、重み係数とレートとを乗算することで、優先度が決定されてもよい。例えば、カテゴリ２の候補は、ユーザＡの通信端末（ＵＥ＿Ａ１）に対して、ｒ'（Ａ，ａ）×（０．６６７）のように重み付けされる。カテゴリ２の候補は、ユーザＡの通信端末（ＵＥ＿Ａ２）に対して、ｒ'（Ａ，ａ）×（０．３３４）のように重み付けされる。さらに、カテゴリ２の候補は、ユーザＡの通信端末（ＵＥ＿Ａ３）に対して、ｒ'（Ａ，ａ）×（０）＝０のように重み付けされる。これらの重み付けの結果に基づいて、各候補の優先度が決定される。
【００６２】
この重み付けの方法によれば、ユーザ各自の通信端末の利用用途に合わせてアプリケーションを推薦することができる。例えば、パズルゲームを頻繁に利用している通信端末に対してゲームのアプリケーションを推薦する一方、地図検索アプリケーションを頻繁に利用している通信端末に対して、乗換案内のアプリケーションを推薦することができる。
【００６３】
＜４．３．３ 推薦対象ユーザの利用傾向（特徴ベクトル）に基づく重み付け＞
重み係数を決定する第３の方法は、第２の方法と同様に、推薦対象ユーザ（ユーザＡ）の利用傾向を利用するが、カテゴリの代わりに特徴ベクトルを利用する点が異なる。
【００６４】
図１０は、このような重み付けを行うためのフローチャートを示す。ステップＳ１０１において、配信サーバのメタデータ処理部３０６は、プロバイダが提供可能な全てのアプリケーションのメタデータから、特徴的な単語である特徴語を判別及び抽出し、総数ｎ個の特徴語を決定する。特徴語の抽出は、当該技術分野における適切な如何なる方法により行われてもよい。一例として、ＴＦＩＤＦにより行われてもよい。なお、この場合におけるメタデータとは、アプリケーション名、アプリケーションの説明文等のような、アプリケーションを特徴付ける情報である。
【００６５】
ステップＳ１０２において、メタデータ処理部３０６は、ユーザＡに対するマスターリストに含まれているアプリケーションの候補各々について、特徴ベクトルを生成する。特徴ベクトルは、ｎ次元のベクトルであり、概して、ステップＳ１０１で決定されたｎ個の特徴語を含むか否かを判別することで生成される。
【００６６】
ステップＳ１０３において、メタデータ処理部３０６は、ユーザＡの利用履歴情報に基づいて、ユーザＡの通信端末各々に対する特徴ベクトルを生成する。例えば、ユーザＡの通信端末（ＵＥ＿Ａ１）が、地図検索アプリケーション（Ａｐ１）と、音楽鑑賞用アプリケーション（Ａｐ２）とをダウンロードしていたとする。この場合、２つのアプリケーションＡｐ１及びＡｐ２各々のメタデータを用いて、１つの特徴ベクトルが生成される。同様に、ユーザＡの他の通信端末についても、特徴ベクトルが生成される。
【００６７】
ステップＳ１０４において、ステップＳ１０２で生成されたアプリケーションの候補の特徴ベクトルと、ステップＳ１０３で生成された各端末の特徴ベクトルとの類似度が算出され、その類似度が重み係数として決定される。
【００６８】
このようにして、ユーザＡの通信端末各々における利用傾向に基づいて、アプリケーションの候補をユーザＡにどの程度強く推薦するかを適切に決定することができる。
【００６９】
以後、この重み係数と、図５のステップＳ５１で推定したレートとを組み合わせることで、マスターリスト中の候補ａ、ｂ、ｃ、...の優先度を決定する。一例として、重み係数とレートとを乗算することで、優先度が決定されてもよい。
【００７０】
以上本発明は特定の実施例を参照しながら説明されてきたが、それらは単なる例示に過ぎず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。例えば、本発明は、アプリケーションをユーザに推薦する適切な如何なる移動通信システムに適用されてもよい。例えば本発明は、W−CDMA方式のシステム、HSDPA／HSUPA方式のW−CDMAシステム、LTE方式のシステム、LTE−Advanced方式のシステム、IMT−Advanced方式のシステム、WiMAX、Wi−Fi方式のシステム等に適用されてもよい。発明の理解を促すため具体的な数式を用いて説明がなされたが、特に断りのない限り、それらの数式は単なる一例に過ぎず適切な如何なる数式が使用されてもよい。実施例又は項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。説明の便宜上、本発明の実施例に係る装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。ソフトウェアは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に用意されてもよい。本発明は上記実施例に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。
【符号の説明】
【００７１】
１ 通信システム
１０ 通信端末
１０１ 受信部
１０２ 表示部
１０３ 利用履歴取得部
１０４ 送信部
２０ 移動通信網
３０ 配信サーバ
３０１ 受信部
３０２ 格納部
３０３ 利用履歴集計部
３０４ ユーザ間類似度算出部
３０５ 推薦アプリ決定部
３０６ メタデータ処理部
３０７ 送信部
４０ アプリケーションサーバ
【特許請求の範囲】
【請求項１】
複数の通信端末を有する第１のユーザと、前記複数の通信端末の何れかと同じ仕様の端末を有する第２のユーザとを少なくとも含む通信ステムにおけるサーバであって、
前記通信システムのユーザ各々から、アプリケーションの利用状況を示す利用履歴情報を受信する受信部と、
前記利用履歴情報を集計し、前記第１のユーザに推薦するアプリケーションの候補を含むマスターリストを作成する集計部と、
前記第１のユーザが使用する或る通信端末の利用傾向又は前記第２のユーザが使用する前記端末の利用傾向にしたがって、前記マスターリストに含まれるアプリケーションの候補各々について、前記第１のユーザの各通信端末に推薦する優先度を決定する推薦アプリ決定部と、
前記優先度に応じて前記候補を前記第１のユーザに提示するように、前記第１のユーザにリコメンド信号を送信する送信部と
を有するサーバ。
【請求項２】
前記推薦アプリ決定部が、前記第２のユーザが使用する前記端末の利用傾向にしたがって前記優先度を決定する際、前記マスターリストに含まれるアプリケーションの候補が、前記第２のユーザに該当するユーザの内、どの程度の割合のユーザに既にダウンロードされているかを算出し、該割合にしたがって前記優先度を決定する、請求項１記載のサーバ。
【請求項３】
前記推薦アプリ決定部が、前記第１のユーザが使用する或る通信端末の利用傾向にしたがって前記優先度を決定する際、前記マスターリストに含まれている前記候補と同じカテゴリのアプリケーションが、前記複数の通信端末の１つ以上にダウンロードされていた場合、各通信端末にダウンロードされている該カテゴリのアプリケーション数に基づいて、前記優先度を決定する、請求項１記載のサーバ。
【請求項４】
当該サーバが、アプリケーションの情報から、特徴的な言葉を抽出することで、該アプリケーションに対する特徴ベクトルを作成するメタデータ処理部をさらに有し、
前記推薦アプリ決定部が、前記第１のユーザが使用する或る通信端末の利用傾向にしたがって決定を行う際、前記マスターリストに含まれる前記候補の情報から作成された特徴ベクトルと、前記或る通信端末にダウンロードされているアプリケーションの情報から作成された特徴ベクトルとの類否に応じて、前記優先度を決定する、請求項１記載のサーバ。
【請求項５】
複数の通信端末を有する第１のユーザと、前記複数の通信端末の何れかと同じ仕様の端末を有する第２のユーザとを少なくとも含む通信ステムのサーバにおける方法であって、
前記通信システムのユーザ各々から、アプリケーションの利用状況を示す利用履歴情報を受信し、
前記利用履歴情報を集計し、前記第１のユーザに推薦するアプリケーションの候補を含むマスターリストを作成し、
前記第１のユーザが使用する或る通信端末の利用傾向又は前記第２のユーザが使用する前記端末の利用傾向にしたがって、前記マスターリストに含まれるアプリケーションの候補各々について、前記第１のユーザの各通信端末に推薦する優先度を決定し、
前記優先度に応じて前記候補を前記第１のユーザに提示するように、前記第１のユーザにリコメンド信号を送信するステップ
を有する方法。
【請求項１】
複数の通信端末を有する第１のユーザと、前記複数の通信端末の何れかと同じ仕様の端末を有する第２のユーザとを少なくとも含む通信ステムにおけるサーバであって、
前記通信システムのユーザ各々から、アプリケーションの利用状況を示す利用履歴情報を受信する受信部と、
前記利用履歴情報を集計し、前記第１のユーザに推薦するアプリケーションの候補を含むマスターリストを作成する集計部と、
前記第１のユーザが使用する或る通信端末の利用傾向又は前記第２のユーザが使用する前記端末の利用傾向にしたがって、前記マスターリストに含まれるアプリケーションの候補各々について、前記第１のユーザの各通信端末に推薦する優先度を決定する推薦アプリ決定部と、
前記優先度に応じて前記候補を前記第１のユーザに提示するように、前記第１のユーザにリコメンド信号を送信する送信部と
を有するサーバ。
【請求項２】
前記推薦アプリ決定部が、前記第２のユーザが使用する前記端末の利用傾向にしたがって前記優先度を決定する際、前記マスターリストに含まれるアプリケーションの候補が、前記第２のユーザに該当するユーザの内、どの程度の割合のユーザに既にダウンロードされているかを算出し、該割合にしたがって前記優先度を決定する、請求項１記載のサーバ。
【請求項３】
前記推薦アプリ決定部が、前記第１のユーザが使用する或る通信端末の利用傾向にしたがって前記優先度を決定する際、前記マスターリストに含まれている前記候補と同じカテゴリのアプリケーションが、前記複数の通信端末の１つ以上にダウンロードされていた場合、各通信端末にダウンロードされている該カテゴリのアプリケーション数に基づいて、前記優先度を決定する、請求項１記載のサーバ。
【請求項４】
当該サーバが、アプリケーションの情報から、特徴的な言葉を抽出することで、該アプリケーションに対する特徴ベクトルを作成するメタデータ処理部をさらに有し、
前記推薦アプリ決定部が、前記第１のユーザが使用する或る通信端末の利用傾向にしたがって決定を行う際、前記マスターリストに含まれる前記候補の情報から作成された特徴ベクトルと、前記或る通信端末にダウンロードされているアプリケーションの情報から作成された特徴ベクトルとの類否に応じて、前記優先度を決定する、請求項１記載のサーバ。
【請求項５】
複数の通信端末を有する第１のユーザと、前記複数の通信端末の何れかと同じ仕様の端末を有する第２のユーザとを少なくとも含む通信ステムのサーバにおける方法であって、
前記通信システムのユーザ各々から、アプリケーションの利用状況を示す利用履歴情報を受信し、
前記利用履歴情報を集計し、前記第１のユーザに推薦するアプリケーションの候補を含むマスターリストを作成し、
前記第１のユーザが使用する或る通信端末の利用傾向又は前記第２のユーザが使用する前記端末の利用傾向にしたがって、前記マスターリストに含まれるアプリケーションの候補各々について、前記第１のユーザの各通信端末に推薦する優先度を決定し、
前記優先度に応じて前記候補を前記第１のユーザに提示するように、前記第１のユーザにリコメンド信号を送信するステップ
を有する方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−１４４４１（Ｐ２０１２−１４４４１Ａ）
【公開日】平成２４年１月１９日（２０１２．１．１９）
【国際特許分類】
【出願番号】特願２０１０−１５０３８７（Ｐ２０１０−１５０３８７）
【出願日】平成２２年６月３０日（２０１０．６．３０）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公開日】平成２４年１月１９日（２０１２．１．１９）
【国際特許分類】
【出願日】平成２２年６月３０日（２０１０．６．３０）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]