JP2012014447A - ユーザにアプリケーションを推薦するサーバ及び方法 - Google Patents

Abstract

【課題】特定のユーザにアプリケーション（Ａｐ）のダウンロードを促す場合において、Ａｐを使用した複数の他のユーザからの評判情報を、特定のユーザにとって有意義な順序で提示できるようにすること。
【解決手段】サーバは、特定のＡｐを使用した複数のユーザが作成した複数の評判情報を、データベースから読み込み、所定の判断基準にしたがって、複数の評判情報各々について優先度を決定し、優先度にしたがって並べられた複数の評判情報のリストを、特定のユーザに送信する。所定の判断基準は、評判情報の作成者の通信端末と、特定のユーザの通信端末とが共通していた場合、優先度を高くする基準、所定の複数の言葉を数多く含んでいたほど、評判情報の優先度を高くする基準、Ａｐの利用期間が長いユーザの評判情報の優先度を高くする基準、及びＡｐの利用傾向の類似度が高いほど、優先度を高くする基準の内の１つ以上により規定される。
【選択図】図１

Description

本発明は、ユーザにアプリケーションを推薦するサーバ及び方法に関連する。

近年の通信端末は、単に通信を行うだけでなく、様々なアプリケーションをサーバからダウンロードし、実行することができる。通信端末は、具体的には、携帯電話、情報端末、スマートフォン、ノート型パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等であるが、これらに限定されない。通信端末にダウンロードすることが可能なアプリケーションは、極めて多数存在するので、アプリケーションの提供者（プロバイダ）は、提供するアプリケーションをユーザに推薦する必要がある。通信端末にアプリケーションをダウンロードすることについては、例えば特許文献１に記載されている。

特開２００９−３０１４７２号公報

ところで、プロバイダのサーバからアプリケーションをダウンロードしたユーザが、アプリケーションを使用した後、そのアプリケーションに対する評判情報を作成し、サーバに送信することが多い。アプリケーションに対する一般的な説明は、プロバイダや開発元から提供される。しかしながら、評判情報は、個々のユーザが実際にアプリケーションを使用した経験に基づいて記述されているので、一般的な説明からは得られない情報を含んでいる。したがって、アプリケーションのダウンロードを検討しているユーザにとって、そのような評判情報は、非常に参考になることがある。このような観点から、プロバイダは、アプリケーションに対する評判情報を公開し、そのアプリケーションのダウンロードを検討しているユーザが閲覧できるようにしている。

しかしながら、アプリケーションをダウンロードした誰もが簡単に評判情報を作成できるので、評判情報の数は非常に多く、これらは有用なものから有用でないものまで様々である。したがって、何らかのアプリケーションに対する評判情報が、それらを閲覧したユーザにとって必ずしも有意義であるとは限らず、評判情報の有効活用が十分になされていない。

本発明の課題は、特定のユーザにアプリケーションのダウンロードを促す場合において、そのアプリケーションを使用した複数の他のユーザからの評判情報を、特定のユーザにとって有意義な順序で提示できるようにすることである。

本発明の一形態によるサーバは、
特定のアプリケーションを使用した複数のユーザが作成した複数の評判情報を、データベースから読み込む読込部と、
所定の判断基準にしたがって、前記複数の評判情報各々について優先度を決定する優先度決定部と、
前記優先度にしたがって並べられた前記複数の評判情報のリストを、特定のユーザに送信する送信部と
を有し、前記所定の判断基準は、
評判情報を作成したユーザの通信端末と、前記特定のユーザの通信端末とが共通していた場合、該評判情報の優先度を高くする第１の基準、
評判情報が、所定の複数の言葉を１つ以上含んでいた場合、含まれていた言葉の数が多いほど、該評判情報の優先度を高くする第２の基準、
評判情報を作成したユーザが、アプリケーションを利用した期間が長いほど、該評判情報の優先度を高くする第３の基準、及び
評判情報を作成したユーザによるアプリケーションの利用傾向と、前記特定のユーザによるアプリケーションの利用傾向との類似度が高いほど、該評判情報の優先度を高くする第４の基準
の内の１つ以上により規定されている、サーバである。

本発明の一形態によれば、特定のユーザにアプリケーションのダウンロードを促す場合において、そのアプリケーションを使用した複数の他のユーザからの評判情報を、特定のユーザにとって有意義な順序で提示することができる。

実施例で使用される通信システムを示す図。 通信端末の機能ブロック図。 アプリ検索サーバの機能ブロック図。 「端末に基づく優先度決定」を行う場合の動作概要を示す図。 動作例の詳細を示すフローチャート。 別の動作例の詳細を示すフローチャート。 通信端末及びアプリ検索サーバの機能ブロック図。 「アプリケーションの利用経験に基づく優先度決定」を行う場合の動作概要を示す図。 動作例の詳細を示すフローチャート。 別の動作例の詳細を示すフローチャート。 通信端末及びアプリ検索サーバの機能ブロック図。 「アプリケーションの利用傾向の類似度に基づく優先度決定」を行う場合の動作概要を示す図。 動作例の詳細を示すフローチャート。

以下の観点から実施例を説明する。

１．システム
２．端末に基づく優先度決定
２．１ 端末及びサーバ
２．２ 動作概要
２．３ 動作例−その１
２．４ 動作例−その２
３．アプリケーションの利用経験に基づく優先度決定
３．１ 端末及びサーバ
３．２ 動作概要
３．３ 動作例
４．アプリケーションの利用傾向の類似度に基づく優先度決定
４．１ 端末及びサーバ
４．２ 動作概要
４．３ 動作例

＜１．システム＞
図１は、実施例で使用される通信システムを示す。通信システムは、通信端末１１、１２、移動通信網２０、アプリ検索サーバ３０、アプリＤＢ４１及びアプリ評判情報ＤＢ４２を有する。通信端末１１、１２は、移動通信網２０を介してアプリ検索サーバ３０と通信を行う。アプリ検索サーバ３０は必要に応じてアプリＤＢ４１及びアプリ評判情報ＤＢ４２と通信する。アプリＤＢ４１は、プロバイダが提供可能なアプリケーションを格納するデータベースであり、アプリ検索サーバ３０からの要請に応じてアプリケーションを提供する。アプリ評判情報ＤＢ４２は、アプリケーションを使用したユーザから収集した評判情報を格納するデータベースであり、アプリ検索サーバ３０からの要請に応じて評判情報を提供する。

評判情報には優先度が付けられ、この優先度はユーザ毎に異なる。アプリ検索サーバ３０は、優先度にしたがって並んだ評判情報をユーザに提供する。これにより、ユーザ１が何らかのアプリケーションの評判情報を閲覧する場合、アプリ検索サーバ３０は、ユーザ１の通信端末１１に相応しい順序に並んだ評判情報をユーザ１に提供できる。同様に、ユーザ２が何らかのアプリケーションの評判情報を閲覧する場合、アプリ検索サーバ３０は、ユーザ２の通信端末１２に相応しい順序に並んだ評判情報をユーザ２に提供できる。この優先度をどのように決定するかについて、本実施例では、大別して３通りの方法を説明する。それらは、「２．端末に基づく優先度決定」、「３．アプリケーションの利用経験に基づく優先度決定」及び「４．アプリケーションの利用傾向の類似度に基づく優先度決定」の項目で説明される。

＜２．端末に基づく優先度決定＞
＜＜２．１ 端末及びサーバ＞＞
図２は、通信端末１１の機能ブロック図を示す。図示の通信端末は図１の通信端末１２にも使用可能である。図２には、通信端末１１に備わる様々な機能要素の内、本実施例に特に関連するものが示されている。通信端末は、アプリ検索サーバからアプリケーションをダウンロードして実行することができる適切な如何なる通信端末でもよい。通信端末は、具体的には、携帯電話、情報端末、スマートフォン、ノート型パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等であるが、これらに限定されない。図示の通信端末１１は、通信部２０１、利用履歴取得部２０２及び評判情報閲覧部２０３を少なくとも有する。

通信部２０１は、移動通信網を介してアプリ検索サーバ３０からアプリケーション及びその他の信号を受信する。その他の信号には、例えば、ユーザが何らかのアプリケーションをダウンロードすることを促すリコメンド信号が含まれる。本実施例では、リコメンド信号は、適切な優先度にしたがって並べられた評判情報のリストを含む。さらに、通信部２０１は、移動通信網を介してアプリ検索サーバ３０に信号を送信する。送信される信号は、例えば、利用履歴情報を含む。

利用履歴取得部２０３は、アプリケーションのダウンロード、起動、削除等を示す利用履歴情報を作成する。例えば、あるアプリケーションがダウンロードされた場合、そのアプリケーション名、ダウンロードの日時が少なくとも利用履歴情報に記録される。さらに、アプリケーションが起動された場合、対象のアプリケーション名、起動した日時、利用した期間、起動回数等が少なくとも利用履歴情報に記録される。アプリケーションが削除された場合、対象のアプリケーション名、削除された日時が少なくとも利用履歴情報に記録される。利用履歴情報は、アプリケーション名、日時、利用時間等に加えて、アプリケーションが使用された場所の情報を含んでもよい。利用履歴情報は、一定の頻度でアプリ検索サーバ３０に報告されてもよいし、ユーザやアプリ検索サーバ３０等からの要求に応じて報告されてもよい。利用履歴情報を一定の頻度で報告する場合の頻度は、例えば、時間、日、週、月等の適切な如何なる頻度でもよい。配信サーバが最新情報を蓄積すること、及び通信端末に保存する利用履歴情報の情報量を少なくする等の観点からは、高い頻度で報告されることが望ましい。ネットワークリソースの有効利用の観点からは、必要に応じて報告されることが望ましい。

評判情報閲覧部２０３は、視覚的なユーザインターフェースとして機能する表示部において、評判情報を表示する。表示部は、具体的には、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機ＥＬパネル等であるが、これらに限定されない。本実施例における表示部は、接触感知式の透明パネルを有するタッチスクリーンを実現し、ユーザの指の動きで画面の表示を制御することができる。表示部は、文字、図形、記号、静止画像、動画像等を表示することができ、例えば、アプリケーションを表すアイコンが画面上に表示される。評判情報閲覧部２０３は、アプリ検索サーバ３０が指定した優先度にしたがって並んだ評判情報のリストを表示部に表示する。

なお、視覚的なユーザインターフェースだけでなく、他のユーザインターフェースが、通信端末１１に備わっていてもよい。例えば、キーパッド、制御パネル、キーボード、タッチパッド、マウス、トラックボール、マイクロフォン、スピーカ等が備わっていてもよい。

図３は、アプリ検索サーバ３０の機能ブロック図を示す。図３には、アプリ検索サーバ３０に備わる様々な機能要素の内、本実施例に特に関連するものが示されている。アプリ検索サーバ３０は、アプリＤＢ４１に記憶されているアプリケーションを検索し、移動通信網を介してユーザにアプリケーションを提供する。さらに、アプリ検索サーバ３０は、アプリ評判情報ＤＢに記憶されている評判情報を抽出し、後述の優先度にしたがって並んだ評判情報のリストをユーザに提供する。図示のアプリ検索サーバ３０は、評判情報取得要求受信部３０１、端末機種情報読み込み部３０２、機種情報の一致性による評判情報重み付け処理部３０３、評判情報読み込み部３０４、評判情報の機種依存性判別部３０５、機種依存性に基づく評判情報の重み付け処理部３０６、端末利用期間判定部３０７及び優先度算出部３０８を少なくとも有する。

評判情報取得要求受信部３０１は、評判情報を取得することを求める要求信号を受信する。この要求信号は、アプリケーションを特定するアプリＩＤ、通信端末を特定する端末ＩＤを少なくとも含む。この通信端末に評判情報が提示される。要求信号を受信したことで、本実施例により、評判情報の優先度が決定され、適切な順に並んだ評判情報のリストがユーザに提示される。要求信号は、例えば、ユーザが何らかのアプリケーションの情報を要求したことに応じて、通信端末から送信されてもよいし、不図示の何らかの管理部から送信されてもよい。

端末機種情報読み込み部３０２は、評判情報の提示を受けるユーザの通信端末が、何であるかの情報（端末機種情報）を、不図示のデータベースから取得する。データベースには各ユーザの利用履歴情報が含まれている。この利用履歴情報から、ユーザの通信端末の機種情報を特定することができる。あるいは、利用履歴情報ではなく、ユーザの通信端末に対する契約情報等から端末機種情報が取得されてもよい。

機種情報の一致性による評判情報重み付け処理部３０３は、評判情報の送信先であるユーザの通信端末の端末機種情報と、評判情報を作成したユーザの通信端末の端末機種情報とを照合する。両者が一致していた場合、その評判情報に対する重み変数を増やす（例えば、１ポイント加算する。）。後述するように、評判情報各々に対する重み変数は、最終的には各評判情報の優先度に関連する。

評判情報読み込み部３０４は、アプリ評判情報ＤＢ４２から評判情報を読み込む。

評判情報の機種依存性判別部３０５は、評判情報に含まれている文字を解析（テキスト解析）し、評判情報が、所定の複数の言葉の１つ以上を含んでいるか否かを判定する。所定の複数の言葉は、通信端末に依存する言葉として予め決定されている。例えば、「操作性」、「画面」、「動作が速い」、「動作が遅い」等のような言葉が、通信端末に依存する言葉として決定されている。

機種依存性に基づく評判情報の重み付け処理部３０６は、評判情報が、上記の所定の言葉をどの程度多く含んでいるかという観点から、評判情報の重み変数を調整する。例えば、所定の言葉が１００個予め決定さてれており、ある評判情報が、その内６０個の言葉を含んでいたとする。この場合、その評判情報に対して、６０×αのような値が重み変数に加算される（αは、所定の定数である。）。

端末利用期間判定部３０７は、ユーザの利用履歴情報から、ユーザが通信端末を利用している合計期間を判定する。また、端末利用期間判定部３０７は、ユーザの利用履歴情報から、ユーザが、アプリケーションをどの程度長く利用しているかも判定する。

優先度算出部３０８は、重み付け処理部３０３、３０６により決定された重み変数に基づいて、評判情報各々の優先度を決定する。一例として、重み変数が、そのまま優先度として使用されてもよいし、重み変数から所定の規則にしたがって優先度が導出されてもよい。いずれにせよ、重み変数が大きければ優先度は高く、重み変数が小さければ優先度は低い。

＜＜２．２ 動作概要＞＞
図４は、「２．端末に基づく優先度決定」を行う場合の動作概要を示す。ユーザＸは、アプリケーションＡをダウンロードして使用し、アプリケーションＡに対する評判情報を投稿する。この評判情報には、「操作性が良い」、「他の類似アプリより画面が見やすい」等の意見が含まれていたとする。一方、ユーザ１及びユーザ２は、アプリケーションＡのダウンロードを行うか否かを検討している。ユーザＸは通信端末（ＵＥ＿Ｘｐ）を有し、ユーザ１も同じ通信端末（ＵＥ＿Ｘｐ）を有する。したがって、ユーザＸの評判情報の重み変数は、端末の異同の観点からは、ユーザ１に対して大きく評価される（例えば、１ポイント加算される。）。これに対して、ユーザ２の通信端末（ＵＥ＿ＨＴ）はユーザＸの通信端末とは異なる。このため、ユーザＸの評判情報の重み変数は、端末の異同の観点からは、ユーザ２に対して大きくは評価されない（例えば、加算されない。）。

さらに、アプリ検索サーバ（図４には図示されていない）は、ユーザＸの評判情報を解析する。評判情報は、「操作性」や「画面」等の端末に依存する所定の言葉を含んでいる。したがって、この評判情報は、そのような言葉を含んでいない他の評判情報に比べて大きく評価される。

このように、端末の異同や、評判情報の内容に基づいて、ユーザＸの評判情報の優先度が、ユーザ１及びユーザ２の各々に対して決定される。図示の例の場合、ユーザＸの評判情報は、ユーザ１に対しては高い優先度を有し、ユーザ２に対してはそれほど高くない優先度を有する。その結果、ユーザ１に提示される評判情報のリストでは、ユーザＸの評判情報がリストの上位にランキングされる。ユーザ２に提示される評判情報のリストでは、ユーザＸの評判情報はリストの下位にランキングされる。このように、各ユーザに相応しい順序で評判情報が提示される。

＜＜２．３ 動作例−その１＞＞
図５は、アプリ検索サーバ３０で行われる動作例の詳細を示す。ステップＳ５０１において、アプリ検索サーバ３０は、評判情報を取得することを求める要求信号を受信する。要求信号は、対象とするアプリケーションを特定するアプリＩＤと、評判情報の提示を受ける通信端末の端末ＩＤとを少なくとも含む。

ステップＳ５０３において、アプリ検索サーバ３０は、端末ＩＤから機種（例えば、ＵＥ＿Ｘｐ）を判別する。

ステップＳ５０５において、アプリ検索サーバ３０は、要求信号に含まれていたアプリＩＤを用いて、そのアプリＩＤに対する評判情報をデータベースから抽出する。そのような評判情報は、一般的には多数存在する。説明の便宜上、評判情報１、評判情報２、...評判情報Ｎのように、Ｎ個の評判情報が抽出されたとする。

ステップＳ５０７において、アプリ検索サーバ３０は、特定のアプリケーションに対するＮ個の評判情報各々について、評判情報を作成したユーザの機種と、ステップＳ５０３で判別した機種（ＵＥ＿Ｘｐ）との異同を判別する。双方の機種が一致していた場合、評判情報に対する重み変数が増やされる（例えば、１ポイント加算される。）。重み変数は、評判情報各々について存在し、最終的には、評判情報をリスト化する際の優先度に関連する。重み変数の増やし方は、１ポイント加算するだけでなく、他の方法で加算されてもよい。例えば、双方の機種同士が、厳密には一致していないが、仕様が共通していた場合には１ポイント加算し、双方の機種同士が、厳密に一致していた場合には２ポイント加算するようなことが考えられる。

一般に、アプリケーションは、使用される動作環境の影響を強く受ける。動作環境は、通信端末におけるＣＰＵの処理速度、画面サイズ、オペレーティングシステム等のような製品仕様によって決まる。したがって、機種が同一であったり、製品仕様が同じである通信端末を使用しているユーザの評判情報は、アプリケーションをダウンロードするか否かを決定する際に参考になる可能性が高い。このような観点から、ステップＳ５０７では、機種の異同の観点から評判情報の重み変数を設定している。

ステップＳ５０９において、アプリ検索サーバ３０は、評判情報中の文字を解析（テキスト解析）し、評判情報が、所定の複数の言葉を含んでいるか否かを判定する。所定の複数の言葉は、所定の複数の言葉は、通信端末に依存する言葉として予め決定されている。例えば、「操作性」、「画面」、「動作が速い」、「動作が遅い」等のような言葉が、通信端末に依存する言葉として決定されている。

ステップＳ５１１において、評判情報が、所定の複数の言葉を含んでいた場合、フローはステップＳ５１３に進む。評判情報が、所定の複数の言葉を含んでいなかった場合、フローはステップＳ５１９に進む。

ステップＳ５１３において、アプリ検索サーバ３０は、ステップＳ５０３で判別した機種と、評判情報を作成したユーザの機種との異同を判別する。同じであった場合、フローはステップＳ５１５に進み、同じでなかった場合、フローはステップＳ５１７に進む。

ステップＳ５１５において、アプリ検索サーバ３０は、評判情報の重み変数に「（所定の複数の言葉に合致した言葉の数）×α」の値を加算する。αは、正の定数である。したがって、ステップＳ５１５では、評判情報の重み変数が、合致している言葉の数に応じて増やされる。

ステップＳ５１７において、アプリ検索サーバ３０は、評判情報の重み変数から、「（所定の複数の言葉に合致した言葉の数）×β」の値を減算する。βは、正の定数である。したがって、ステップＳ５１７では、評判情報の重み変数が、合致している言葉の数に応じて減らされる。フローがステップＳ５１７に至る場合は、ステップＳ５１３において、通信端末の機種が同一でなかった場合である。上述したように、通信端末の機種が異なっていた場合、アプリケーションにとって動作環境は大きく異なる。したがって、評判情報が、所定の言葉を含んでいたとしても、評判情報の提示を受けるユーザにとって有意義な情報である可能性は低い。このような観点から、ステップＳ５１７において、重み変数が大きく減らされている。

ステップＳ５１９において、未検討の評判情報が残っているか否かが確認される。残っていた場合、フローはステップＳ５０９に戻り、評判情報のテキスト解析が行われ、説明済みの手順が実行される。Ｎ個全ての評判情報について、重み変数の調整が完了した場合、フローはステップＳ５２１に進む。このようにして得られた評判情報毎の重み変数は、各評判情報の優先度として決定される。

ステップＳ５２１において、アプリ検索サーバ３０は、重み変数（すなわち、優先度）にしたがって、Ｎ個の評判情報を並べ替える。

ステップＳ５２３において、アプリ検索サーバ３０は、並べ替えられた評判情報のリストを、ステップＳ５０３で判別した通信端末（ＵＥ＿Ｘｐ）に送信する。

＜＜２．４ 動作例−その２＞＞
図６は、アプリ検索サーバ３０で行われる別の動作例の詳細を示す。図５の動作例の場合、同じ通信端末を有するユーザが、通信端末に依存する言葉を使って、アプリケーションに対する意見を述べていたとすると、その評判情報の優先度は高く設定され、リストの上位にランキングされる。しかしながら、評判情報を作成したユーザは、対象のアプリケーションや通信端末の操作に精通しているユーザかもしれない反面、不慣れなユーザかもしれない。評判情報の提示を受けるユーザにとって有意義な評判情報は、情報の質や正確さの観点からは、対象のアプリケーションや通信端末に精通しているユーザの評判情報である。しかしながら、評判情報の提示を受けるユーザが、例えば通信端末に不慣れなユーザであった場合、精通したユーザの複雑な評判情報が直ちに有意義であるとは言えない。以下に説明する別の動作例は、このような問題に対処しようとする。

ステップＳ６１において、アプリ検索サーバ３０は、評判情報を取得することを求める要求信号を受信する。要求信号は、対象とするアプリケーションを特定するアプリＩＤと、評判情報のリストの送信先である通信端末の端末ＩＤとを少なくとも含む。

ステップＳ６２において、アプリ検索サーバ３０は、要求信号に含まれていたアプリＩＤを用いて、そのアプリＩＤに対する評判情報をデータベースから抽出する。そのような評判情報は、一般的には多数存在する。説明の便宜上、評判情報１、評判情報２、...評判情報Ｎのように、Ｎ個の評判情報が抽出されたとする。ここまでは、図５のステップＳ５０５、Ｓ５０５と同様である。

ステップＳ６３において、アプリ検索サーバ３０は、評判情報の提示を受けるユーザの通信端末の利用期間と、評判情報を作成したユーザの通信端末の利用期間との差分を算出し、差分の絶対値Ｐを求める。通信端末の利用期間は、各ユーザがアプリ検索サーバ３０に定期的に又は非定期的に報告している利用履歴情報から求めることができる。あるいは、ユーザの通信端末に対する契約情報から導出することもできる。

ステップＳ６４において、評判情報の重み変数に、１／Ｐを加算する。Ｐは、ユーザ同士の利用期間の差分であるので、利用期間が同程度であれば、Ｐは小さくなり、１／Ｐは大きくなる。逆に、利用期間が異なっていた場合、Ｐは大きくなり、１／Ｐは小さくなる。したがって、対象のユーザと同程度の利用期間の経験を有するユーザが作成した評判情報の重み変数（又は優先度）は大きい。逆に、対象のユーザと異なる利用期間の経験を有するユーザが作成した評判情報の重み変数（又は優先度）は小さい。

ステップＳ６５において、アプリ検索サーバ３０は、重み変数（すなわち、優先度）にしたがって、Ｎ個の評判情報を並べ替える。

ステップＳ６６において、アプリ検索サーバ３０は、並べ替えられた評判情報のリストを、対象のユーザの通信端末（ＵＥ＿Ｘｐ）に送信する。

図６で説明した優先度の決定法は、図５で説明した優先度の決定法の代わりに使用されてもよいし、図５で説明した優先度の決定法と組み合わせて使用されてもよい。組み合わせる場合、端末が一致するか否か、所定の言葉を含んでいるか否か及び利用期間が同程度であるか否かの全ての観点から、重み変数が調整され、調整後の重み変数が優先度として決定される。

上記の説明では、ステップＳ６３において、通信端末の利用期間が比較されている。通信端末の利用期間に代えて、又はそれに加えて、同一カテゴリのアプリケーションの利用期間が使用されてもよい。例えば、あるアプリケーションＡをユーザ１に勧めるために、アプリケーションＡの評判情報を適切にリスト化する場合を考える。この場合において、ユーザ１がアプリケーションＡと同じカテゴリのアプリケーションを利用した利用期間と、評判情報を作成したユーザがそのカテゴリのアプリケーションを利用した利用期間との差分が算出され、その差分の絶対値が上記のＰとして使用されてもよい。このように、同程度の習熟度のユーザの評判情報を高く評価するために、通信端末の利用期間や、アプリケーションの利用期間を使用することができる。

＜３．アプリケーションの利用経験に基づく優先度決定＞
次に、評判情報の優先度を、アプリケーションの利用経験に基づいて決定する場合について説明する。

＜＜３．１ 端末及びサーバ＞＞
図７は、通信端末１１及びアプリ検索サーバ３０の機能ブロック図を示す。図７には、通信端末１１及びアプリ検索サーバ３０に備わる様々な機能要素の内、本実施例に特に関連するものが示されている。通信端末１１については、図２に関して説明したものと同様であるため、説明を省略する。アプリ検索サーバ３０は、アプリＤＢ４１に記憶されているアプリケーションを検索し、移動通信網を介してユーザにアプリケーションを提供する。さらに、アプリ検索サーバ３０は、アプリ評判情報ＤＢに記憶されている評判情報を抽出し、後述の優先度にしたがって並んだ評判情報のリストをユーザに提供する。図示のアプリ検索サーバ３０は、評判情報取得要求受信部７０１、評判情報読み込み部７０２、アプリ起動履歴記録部７０３、アプリ利用時間比較部７０４、類似アプリ判定部７０５、類似アプリ利用時間比較部７０６、及び優先度算出部７０７を少なくとも有する。

評判情報取得要求受信部７０１は、評判情報を取得することを求める要求信号を受信する。この要求信号は、アプリケーションを特定するアプリＩＤ、通信端末を特定する端末ＩＤを少なくとも含む。この通信端末に評判情報が提示される。

評判情報読み込み部７０２は、アプリ評判情報ＤＢ４２から評判情報を読み込む。

アプリ起動履歴記録部７０３は、各ユーザから受信した利用履歴情報を保存する。本実施例では、利用履歴情報の内、特に、アプリケーションの起動の履歴が使用される。

アプリ利用時間比較部７０４は、あるユーザがアプリケーションを利用した利用期間と、別のユーザがアプリケーションを利用した利用期間とが比較される。あるユーザ及び別のユーザは、評判情報の提示を受けるユーザや、評判情報を作成したユーザである。

類似アプリ判定部７０５は、あるアプリケーションと類似するアプリケーションが何であるかを特定する。アプリケーションの類否は、例えば、アプリケーションのカテゴリが一致するか否かで判断されてもよい。あるいは、アプリケーションのメタデータ同士の類否に基づいて判断されてもよい。この場合におけるメタデータは、アプリケーションの説明文や、アプリケーション名等のような情報を含む。

類似アプリ利用時間比較部７０６は、類似アプリ判定部７０５で類似すると判定された全てのアプリケーションについて、利用期間をユーザ毎に算出し、あるユーザの利用期間の合計と、別のユーザの利用期間の合計とがどの程度似ているかを比較する（あるいは、類似度を算出する。）。

優先度算出部７０７は、アプリケーションの利用期間、又は類似するアプリケーション全体に対する利用期間の合計に基づいて、評判情報の優先度を決定する。一例として、アプリケーションの利用時間が長いほど大きな優先度が与えられる。

＜＜３．２ 動作概要＞＞
図８は、「３．アプリケーションの利用経験に基づく優先度決定」を行う場合の動作概要を示す。ユーザＸは、アプリケーションＡをダウンロードして使用し、アプリケーションＡに対する評判情報を投稿する。ユーザＹも、アプリケーションＡをダウンロードして使用し、アプリケーションに対する評判情報を投稿する。ユーザ１は、アプリケーションＡのダウンロードを行うか否かを検討している。ユーザＸはアプリケーション（Ａだけでなくそれ以外も含む）を通算で１０時間使用している。ユーザＹはアプリケーション（Ａだけでなくそれ以外も含む）を通算で１００時間使用している。したがって、ユーザＹはユーザＸよりも高度な評判情報を作成することが予想される。そこで、本方法では、ユーザＸの評判情報の重み変数（すなわち、優先度）を低く設定し、ユーザＹの評判情報の重み変数（すなわち、優先度）を高く設定する。その結果、ユーザ１に提示される評判情報のリストでは、ユーザＹの評判情報がリストの上位にランキングされ、ユーザＹの評判情報はリストの下位にランキングされる。このようにして、客観的に信頼性の高い評判情報を、上位にランキングすることができる。

＜＜３．３ 動作例＞＞
図９は、アプリ検索サーバ３０で行われる動作例の詳細を示す。ステップＳ９１において、アプリ検索サーバ３０は、評判情報を取得することを求める要求信号を受信する。要求信号は、対象とするアプリケーション（アプリケーションＡ）を特定するアプリＩＤと、評判情報のリストの送信先である通信端末の端末ＩＤとを少なくとも含む。

ステップＳ９２において、アプリ検索サーバ３０は、要求信号に含まれていたアプリＩＤを用いて、そのアプリＩＤに対する評判情報をデータベースから抽出する。そのような評判情報は、一般的には多数存在する。説明の便宜上、評判情報１、評判情報２、...評判情報Ｎのように、Ｎ個の評判情報が抽出されたとする。

ステップＳ９３において、アプリ検索サーバ３０は、Ｎ個の評判情報各々について、評判情報を作成したユーザの通信端末におけるアプリ利用履歴ｙ_ｉ（ｉ＝１，...，Ｎ）をデータベースから読み込む。この場合におけるアプリ利用履歴ｙ_ｉは、ｉ番目の評判情報を作成したユーザが、アプリケーション（Ａだけでなくそれ以外も含む）をどの程度長く利用しているかを示す利用期間である。

ステップＳ９４において、アプリ利用履歴ｙ_ｉが示す利用期間を比較し、利用期間が長いほど優先度を高く設定する。

ステップＳ９５において、アプリ検索サーバ３０は、利用期間（すなわち、優先度）にしたがって、Ｎ個の評判情報を並べ替える。

ステップＳ９６において、アプリ検索サーバ３０は、並べ替えられた評判情報のリストを、対象の通信端末に送信する。

図１０は、アプリ検索サーバ３０で行われる別の動作例の詳細を示す。概して、図９と同様であるが、ステップＳ１０４及びＳ１０５における処理が主に異なる。ステップＳ１０１、Ｓ１０２、Ｓ１０３における処理は、図９のステップＳ９１、Ｓ９２、Ｓ９３における処理とそれぞれ同じである。

ステップＳ１０４において、アプリ検索サーバ３０は、対象のアプリケーション（アプリケーションＡ）と類似するアプリケーションを決定する。

ステップＳ１０５において、アプリ検索サーバ３０は、対象のアプリケーションと類似する全てのアプリケーションについて、評判情報を作成したユーザの利用履歴を算出し、合計する。例えば、アプリケーションＡに類似するアプリケーションが、アプリケーションａ１、アプリケーションａ２、アプリケーションａ３であったとする。アプリ検索サーバ３０は、評判情報１を作成したユーザの利用履歴を調べ、アプリケーションＡを利用した利用期間、アプリケーションａ１を利用した利用期間、アプリケーションａ２を利用した利用期間、及びアプリケーションａ３を利用した利用期間を求め、それらの利用期間を合計することで、評判情報１に対する優先度を決定する。同様に全ての評判情報２−Ｎについても優先度が決定される。

ステップＳ１０６、Ｓ１０７における処理は、図９のステップＳ９５、Ｓ９６とそれぞれ同じである。

このように図１０に示す例の場合、特定のアプリケーションＡだけでなく、それに類似するアプリケーションの利用期間をも考慮するので、対象のユーザにとって有意義な評判情報を洩れなく活用できる。

＜４．アプリケーションの利用傾向の類似度に基づく優先度決定＞
次に、評判情報の優先度を、アプリケーションの利用傾向の類似度に基づいて決定する場合について説明する。

＜＜４．１ 端末及びサーバ＞＞
図１１は、通信端末１１及びアプリ検索サーバ３０の機能ブロック図を示す。図１１には、通信端末１１及びアプリ検索サーバ３０に備わる様々な機能要素の内、本実施例に特に関連するものが示されている。通信端末１１については、図２に関して説明したものと同様であるため、説明を省略する。アプリ検索サーバ３０は、アプリＤＢ４１に記憶されているアプリケーションを検索し、移動通信網を介してユーザにアプリケーションを提供する。さらに、アプリ検索サーバ３０は、アプリ評判情報ＤＢに記憶されている評判情報を抽出し、後述の優先度にしたがって並んだ評判情報のリストをユーザに提供する。図示のアプリ検索サーバ３０は、評判情報取得要求受信部１１１、評判情報読み込み部１１２、アプリ起動履歴記録部１１３、アプリ利用時間判定部１１４、アプリ利用履歴類似度判定部１１５、類似アプリ判定部１１６、類似アプリ利用時間判定部１１７及び優先度算出部１１８を少なくとも有する。

評判情報取得要求受信部１１１は、評判情報を取得することを求める要求信号を受信する。この要求信号は、アプリケーションを特定するアプリＩＤ、通信端末を特定する端末ＩＤを少なくとも含む。この通信端末に評判情報が提示される。

評判情報読み込み部１１２は、アプリ評判情報ＤＢ４２から評判情報を読み込む。

アプリ起動履歴記録部１１３は、各ユーザから受信した利用履歴情報を保存する。本実施例では、利用履歴情報の内、特に、アプリケーションの起動の履歴が使用される。

アプリ利用時間判定部１１４は、各ユーザの利用履歴情報から、アプリケーションに対する利用期間を判定する。

アプリ利用履歴類似度判定部１１５は、特定のアプリケーションに対する利用期間をユーザ毎に比較することで、ユーザ同士の類似度を算出する。ユーザ同士の類似度は当該技術分野において既知の適切な如何なる方法で算出されてもよい。例えば、第１、第２、第３のユーザのアプリケーションの利用期間が１０時間、１０時間、１００時間であったとする。この場合、第１及び第２のユーザの利用期間が共通しているので、両者の類似度は高い。これに対して、第１及び第３のユーザの利用期間はかなり異なっているので、両者の類似度は低い。ユーザ同士の類似度を算出する別の例として、例えば、第１のユーザの通信端末にも、第２のユーザの通信端末にも、ダウンロードされているアプリケーションの数が多いほど、第１及び第２のユーザの類似度は高いと判断されてもよい。ユーザ同士の類似度を算出するさらに別の例として、アプリケーションを使用する時刻に基づいて類似度が算出されてもよい。例えば、ユーザ１が、朝８時から９時までの間に何らかのアプリケーションを使用するが、その後はほとんど使用しない傾向を持っていたとする。このような傾向を有するユーザは、ユーザ１との類似度は高いと判断されてもよい。ユーザ同士の類否判断は、これらの方法に限定されず、適切な如何なる方法が使用されてもよい。何れの方法においても、特定のアプリケーションのみに対する利用期間が使用されてもよいし、特定のアプリケーションとカテゴリが共通する複数のアプリケーションに対する利用期間が使用されてもよいし、全てのアプリケーションに対する利用期間が使用されてもよい。

類似アプリ判定部１１６は、あるアプリケーションと類似するアプリケーションが何であるかを特定する。アプリケーションの類否は、例えば、アプリケーションのカテゴリが一致するか否かで判断されてもよい。あるいは、アプリケーションのメタデータ同士の類否に基づいて判断されてもよい。この場合におけるメタデータは、アプリケーションの説明文や、アプリケーション名等のような情報を含む。

類似アプリ利用時間比較部１１７は、類似アプリ判定部１１６で類似すると判定された全てのアプリケーションについて、利用期間をユーザ毎に算出し、あるユーザの利用期間と、別のユーザの利用期間とがどの程度似ているかを比較する。

優先度算出部１１８は、類似度の高いユーザのアプリケーションの利用傾向に基づいて、評判情報の優先度を決定する。

＜＜４．２ 動作概要＞＞
図１２は、「４．アプリケーションの利用傾向の類似度に基づく優先度決定」を行う場合の動作概要を示す。ユーザＸは、アプリケーションＡをダウンロードして使用し、アプリケーションＡに対する評判情報を投稿する。ユーザＹも、アプリケーションＡをダウンロードして使用し、アプリケーションＡに対する評判情報を投稿する。ユーザ１は、アプリケーションＡのダウンロードを行うか否かを検討している。ユーザＸはアプリケーション（Ａだけでなくその他も含む）を通算で１０時間使用している。ユーザＹはアプリケーション（Ａだけでなくその他も含む）を通算で１００時間使用している。ユーザ１は、アプリケーション（Ａ以外のダウンロード済みのアプリケーション）を８時間使用している。本方法では、ユーザ同士の類似度が計算され、より似ているユーザの評判情報の優先度が高く設定される。上記の例の場合、ユーザ１は、アプリケーションの利用期間の観点からは、利用傾向がユーザＸと類似している。ユーザ１は、アプリケーションの利用期間の観点からは、ユーザＹと利用傾向が類似していない。その結果、アプリ検索サーバは、ユーザ１に提示する評判情報について、ユーザＸの評判情報の優先度を高く設定し、ユーザＹの評判情報の優先度を低く設定する。その結果、ユーザ１に提示される評判情報のリストでは、ユーザＸの評判情報がリストの上位にランキングされ、ユーザＹの評判情報はリストの下位にランキングされる。

＜＜４．３ 動作例＞＞
図１３は、アプリ検索サーバ３０で行われる動作例の詳細を示す。ステップＳ１３１において、アプリ検索サーバ３０は、評判情報を取得することを求める要求信号を受信する。要求信号は、対象とするアプリケーション（アプリケーションＡ）を特定するアプリＩＤと、評判情報のリストの送信先である通信端末の端末ＩＤとを少なくとも含む。

ステップＳ１３２において、アプリ検索サーバ３０は、要求信号に含まれていたアプリＩＤを用いて、そのアプリＩＤに対する評判情報をデータベースから抽出する。そのような評判情報は、一般的には多数存在する。説明の便宜上、評判情報１、評判情報２、...評判情報Ｎのように、Ｎ個の評判情報が抽出されたとする。

ステップＳ１３３において、アプリ検索サーバ３０は、評判情報の提示を受ける通信端末に対するアプリ利用履歴ｘを読み込む。この場合におけるアプリ利用履歴ｘは、この通信端末のユーザが、過去にどのようにアプリケーションを利用したかを示す。原則として、評判情報の提示を受けるユーザが、過去に利用した全てのアプリケーションについて、利用傾向が読み込まれる。

ステップＳ１３４において、アプリ検索サーバ３０は、Ｎ個の評判情報各々を作成したユーザについて、アプリ利用履歴ｙ_ｉを読み込む（ｉ＝１，...，Ｎ）。このアプリ利用履歴ｙ_ｉも、評判情報を作成したユーザが、過去にどのようにアプリケーションを利用したかを示す。原則として、評判情報を作成したユーザが、過去に利用した全てのアプリケーションについて、利用傾向が読み込まれる。

ステップＳ１３５において、評判情報の提示を受けるユーザのアプリ利用履歴ｘと、評判情報を作成したユーザ各自のアプリ利用履歴ｙ_ｉとの類似度が判定され、類似度が高いほど優先度が高く設定される。

ステップＳ１３６において、アプリ検索サーバ３０は、類似度（すなわち、優先度）にしたがって、Ｎ個の評判情報を並べ替える。

ステップＳ１３７において、アプリ検索サーバ３０は、並べ替えられた評判情報のリストを、対象の通信端末に送信する。

上記の様々な優先度決定法において説明された重み変数や優先度の決定法は、単なる一例にすぎず、他の観点から重み変数や優先度が決定されてもよい。例えば、重み変数や優先度を決定する際に、評判情報が作成された時刻が考慮されてもよい。一般的には、最新の評判情報ほど重み変数又は優先度を高く設定することが考えられるが、これに限定されない。例えば、多少古かったとしても、特定の期間内に作成された評判情報の優先度が高く設定されてもよい。

上記の様々な優先度決定法は、各自単独に使用されてもよいし、組み合わせて使用されてもよい。

以上、本発明は特定の実施例を参照しながら説明されてきたが、それらは単なる例示に過ぎず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。例えば、本発明は、アプリケーションをユーザに推薦する適切な如何なる移動通信システムに適用されてもよい。例えば本発明は、W−CDMA方式のシステム、HSDPA／HSUPA方式のW−CDMAシステム、LTE方式のシステム、LTE−Advanced方式のシステム、IMT−Advanced方式のシステム、WiMAX、Wi−Fi方式のシステム等に適用されてもよい。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。発明の理解を促すため具体的な数式を用いて説明がなされたが、特に断りのない限り、それらの数式は単なる一例に過ぎず適切な如何なる数式が使用されてもよい。実施例又は項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。説明の便宜上、本発明の実施例に係る装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。ソフトウェアは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に用意されてもよい。本発明は上記実施例に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。

１１ 通信端末
１２ 通信端末
２０ 移動通信網
２０１ 通信部
２０２ 利用履歴取得部
２０３ 評判情報閲覧部
３０ アプリ検索サーバ
３０１ 評判情報取得要求受信部
３０２ 端末機種情報読み込み部
３０３ 機種情報の一致性による評判情報重み付け処理部
３０４ 評判情報読み込み部
３０５ 評判情報の機種依存性判別部
３０６ 機種依存性に基づく評判情報の重み付け処理部
３０７ 端末利用期間判定部
３０８ 優先度算出部
４１ アプリＤＢ
４２ アプリ評判情報ＤＢ
７０１ 評判情報取得要求受信部
７０２ 評判情報読み込み部
７０３ アプリ起動履歴記録部
７０４ アプリ利用時間比較部
７０５ 類似アプリ判定部
７０６ 類似アプリ利用時間比較部
７０７ 優先度算出部
１１１ 評判情報取得要求受信部
１１２ 評判情報読み込み部
１１３ アプリ起動履歴記録部
１１４ アプリ利用時間判定部
１１５ アプリ利用履歴類似度判定部
１１６ 類似アプリ判定部
１１７ 類似アプリ利用時間判定部
１１８ 優先度算出部

Claims (8)

1. 特定のアプリケーションを使用した複数のユーザが作成した複数の評判情報を、データベースから読み込む読込部と、
   所定の判断基準にしたがって、前記複数の評判情報各々について優先度を決定する優先度決定部と、
   前記優先度にしたがって並べられた前記複数の評判情報のリストを、特定のユーザに送信する送信部と
   を有し、前記所定の判断基準は、
   評判情報を作成したユーザの通信端末と、前記特定のユーザの通信端末とが共通していた場合、該評判情報の優先度を高くする第１の基準、
   評判情報が、所定の複数の言葉を１つ以上含んでいた場合、含まれていた言葉の数が多いほど、該評判情報の優先度を高くする第２の基準、
   評判情報を作成したユーザが、アプリケーションを利用した期間が長いほど、該評判情報の優先度を高くする第３の基準、及び
   評判情報を作成したユーザによるアプリケーションの利用傾向と、前記特定のユーザによるアプリケーションの利用傾向との類似度が高いほど、該評判情報の優先度を高くする第４の基準
   の内の１つ以上により規定されている、サーバ。
2. 前記第１の基準において、評判情報を作成したユーザによる通信端末及び／又はアプリケーションの利用期間が長いほど、該評判情報の優先度を高くする基準が併用される、請求項１記載のサーバ。
3. 前記第２の基準において、前記所定の複数の言葉は、通信端末の機種に依存する言葉から選択されている、請求項１又は２に記載のサーバ。
4. 前記第４の基準において、前記アプリケーションの利用傾向は、前記特定のアプリケーションと少なくともカテゴリが共通するアプリケーションに対する利用履歴から決定される、請求項１ないし３の何れか１項に記載のサーバ。
5. 前記アプリケーションの利用履歴が、アプリケーションを利用した期間の長さを表す、請求項４記載のサーバ。
6. 前記アプリケーションの利用履歴が、アプリケーションを利用した時刻を表す、請求項４記載のサーバ。
7. 前記第１ないし第４の基準の何れかにおいて、評判情報が新しいほど該評判情報の優先度を高くする基準が併用される、請求項１記載のサーバ。
8. 特定のアプリケーションを使用した複数のユーザが作成した複数の評判情報を、データベースから読み込み、
   所定の判断基準にしたがって、前記複数の評判情報各々について優先度を決定し、
   前記優先度にしたがって並べられた前記複数の評判情報のリストを、特定のユーザに送信するステップ
   を有し、前記所定の判断基準は、
   評判情報を作成したユーザの通信端末と、前記特定のユーザの通信端末とが共通していた場合、該評判情報の優先度を高くする第１の基準、
   評判情報が、所定の複数の言葉を１つ以上含んでいた場合、含まれていた言葉の数が多いほど、該評判情報の優先度を高くする第２の基準、
   評判情報を作成したユーザが、アプリケーションを利用した期間が長いほど、該評判情報の優先度を高くする第３の基準、及び
   評判情報を作成したユーザによるアプリケーションの利用傾向と、前記特定のユーザによるアプリケーションの利用傾向との類似度が高いほど、該評判情報の優先度を高くする第４の基準
   の内の１つ以上により規定されている、方法。

Images