【実施例1】
【0017】
<情報選択装置>
【0018】
図3は、第1実施例における情報選択装置10の構成を示すブロック図である。本図に
示すように情報選択装置10は、アイテム属性格納部101と、利用履歴格納部102と
、価格情報格納部103と、関連度算出部104と、関連集合格納部105と、情報選択
部107と、推薦情報格納部108と、送受信部109と、制御部110とを備えて構成
されている。また、情報選択装置10には、情報選択装置10の管理者向けに必要な情報
を表示するための表示装置120と、管理者が操作を行なうためのキーボード、マウス等
の入力装置130とが接続されている。
【0019】
情報選択装置10は、CPU、RAM、ROM、HDD(ハードディスクドライブ)、
ネットワークインタフェース等を備える一般的なコンピュータを用いて構成することがで
きる。すなわち、一般的なコンピュータは、以下で説明するような処理を行なうためのコ
ンピュータプログラムを実行することにより、情報選択装置10として機能することがで
きるようになる。
【0020】
また、上述のように、情報選択装置10を複数台のコンピュータを用いて構成してもよ
い。例えば、負荷分散をするために、情報選択装置10のある処理ブロックに相当するコ
ンピュータを複数台用いて、すなわち、同じ処理ブロックを備える複数台のコンピュータ
を用いて分散処理を行なうようにしてもよい。また、情報選択装置10の一部の処理ブロ
ックをあるコンピュータで実施し、他の処理ブロックを別のコンピュータで実施する形態
で分散処理を行なってもよい。
【0021】
アイテム属性格納部101は、アイテムに関する情報が記録されたアイテム情報テーブ
ル101Aと、カテゴリに関する情報が記録されたカテゴリ情報テーブル101Bとを格
納している。
【0022】
図4(a)は、アイテム情報テーブル101Aの一例を示している。本図に示すように
、アイテム情報テーブル108Aは、アイテム識別子(アイテムID)と、アイテム属性
情報とを対応させたテーブルである。アイテム属性情報は、アイテムの「タイトル(名称
)」「カテゴリ識別子」「説明情報」「アイテム時期情報」などで構成されている。
【0023】
図4(b)は、カテゴリ情報テーブル101Bの一例を示している。本図に示すように
、カテゴリ情報テーブル108Bは、カテゴリ識別子(カテゴリID)とカテゴリ属性情
報とを対応させたテーブルである。カテゴリ属性情報は、「カテゴリ名」「カテゴリ説明
」などで構成されている。2つのテーブルに存在する「カテゴリ識別子」を介して、アイ
テム情報テーブル101Aのアイテム情報とカテゴリ情報テーブル101Bのカテゴリ情
報とを関連付けることができる。
【0024】
ここで、カテゴリとは、アイテムを所定の基準で分類した情報であり、1つのアイテム
について1個以上設定される。カテゴリは、例えば、アイテムの「クリエイター(作成者
)」とすることができる。なお「クリエイター」は、アイテムの制作者、監督、プロデュ
ーサー、執筆者、作曲者、作詞者、演奏者、出演者等である。
【0025】
また、アイテムが音楽コンテンツの場合、「ロック」「ジャズ」「クラシック」「フォ
ーク」等のジャンル情報をカテゴリとすることができ、アイテムが映画の場合、「SF」
「アクション」「コメディ」「アニメ」「サスペンス」等のジャンル情報をカテゴリとす
ることができる。さらには、「日本」「アメリカ」「イギリス」など作成者の国や地域を
用いた分類情報や、「癒し系」「エキサイティング」「ドラマティック」といったアイテ
ムの雰囲気やムードを示す情報をカテゴリとして用いてもよい。
【0026】
アイテム属性情報の「説明情報」は、アイテムのあらすじや要約、制作された背景説明
などの情報である。「アイテム時期情報」は、アイテムの作成された時期(時点)を示す
情報である。ただし、アイテム提供サーバ20にアイテムが登録された時期や、アイテム
が提供開始された時期を用いてもよい。本実施形態では、時期(時点)の表現形式として
、「2010年1月1日」などの日付を用いるが、他の表現形式を用いてもよい。例えば
、「2010年1月1日 10時15分20秒」などの秒単位までの日時でもよいし、ミ
リ秒単位までの日時でもよい。あるいは、「2010年1月」などの月単位の表現形式で
も、「2010年 1Q」などの四半期単位の表現形式でも、「2010年」などの年単
位の表現形式でも、「2000年代」などの年単位より大まかな年代の表現形式でもよい
。
【0027】
アイテム情報テーブル101Aのアイテム属性情報においては、1つのアイテムに同じ
種類の属性項目が複数存在していてもよい。例えば、1つのアイテムに、「クリエイター
1」「クリエイター2」「クリエイター3」「ジャンル1」「ジャンル2」の合計5つの
カテゴリが設定されていてもよい。もちろん、ここで挙げたアイテム属性情報とカテゴリ
属性情報は、あくまでも例示であり、上記に限定される訳ではない。例えば、アイテム属
性情報に「サイズ」や「色」などの属性項目を用いてもよい。
【0028】
なお、情報選択装置10が、必要に応じてアイテム提供サーバ20の後述するアイテム
格納部202からアイテム情報およびカテゴリ情報を取得できるようにして、アイテム属
性格納部101を省略することも可能である。
【0029】
送受信部109は、ネットワーク40(
図2の構成の場合は、さらにネットワーク42
)を介して、アイテム提供サーバ20または端末装置30との間でデータを送受信する処
理を行なう。
【0030】
制御部110は、情報選択装置10の全体の制御を行なうための種々の処理を行なう。
例えば、後述するように、アイテム提供サーバ20または端末装置30から送信される利
用リクエストを、送受信部109を介して受信し、利用リクエストに含まれるユーザ識別
子とアイテム識別子とを対応させて、利用履歴情報として利用履歴格納部102に格納さ
せる。
【0031】
利用履歴格納部102は、ユーザのアイテム利用履歴情報を記録するアイテム利用履歴
テーブル102Aを格納している。アイテム利用は、ユーザからの利用リクエストに対し
てアイテム提供サーバ20がアイテムを提供することにより実行される。ただし、アイテ
ム利用は、購入を伴う提供に限られず、アイテムに関する情報の閲覧、視聴等を含めるよ
うにしてもよい。
【0032】
アイテム利用履歴テーブル102Aは、利用履歴情報の格納形態として、種々の格納形
態を採用することができる。例えば、
図5(a)のアイテム利用履歴テーブル102A−
1に示すように、利用主体識別子とアイテム識別子とを関連付けて格納することができる
。ここで、「利用主体識別子」は、端末装置30を利用するユーザを一意に識別するユー
ザ識別子、または端末装置30を一意に識別するための端末識別子であり、ユーザ識別子
と端末識別子とを合わせた概念である。本実施形態では、ユーザ識別子を用いてユーザを
識別するものとするが、端末装置30として携帯電話を用いた場合等には、端末装置30
との接続時に取得可能な端末識別子を用いるようにしてもよい。
【0033】
本例では、1つの利用リクエストが、テーブルの1行に対応している。テーブルの1行
目と4行目がともに「UserID−1」と「ItemID−3」の組み合わせであるこ
とから分かるように、利用主体識別子とアイテム識別子の組み合わせが同じであっても、
利用リクエストごとにテーブル行のデータを追加して格納している。このため、アイテム
識別子が示すアイテムごとの利用回数、およびアイテムごとの利用ユーザ数を他の処理部
が容易にカウントすることができる。なお、1つの利用リクエストに複数のアイテム識別
子が含まれている場合は、アイテム識別子の数だけのテーブル行を割り当てて格納する。
【0034】
図5(b)に示すアイテム利用履歴テーブル102A−2は、利用主体識別子とアイテ
ム識別子と利用時期情報とを関連付けて格納する格納形態例である。
図5(a)に示した
アイテム利用履歴テーブル102A−1と同様に、1つの利用リクエストが、テーブルの
1行に対応している。利用リクエストに利用時期情報が含まれている場合は、その情報を
取り出して利用時期情報として格納する。利用リクエストに利用時期情報が含まれていな
い場合は、制御部110に内蔵等されている時計を用いて、情報選択装置10が利用リク
エストを受信した時期(時点)を利用時期情報として格納する。
【0035】
本実施形態では、利用時期情報の表現形式として、「2010年1月1日 10時15
分20秒」などの秒単位までの日時を用いるが、それ以外にも、ミリ秒単位までの日時、
日単位までの日付、月単位、年単位など種々の形式を用いることができる。なお、利用リ
クエストの中に、ユーザのアイテムに対する評価値(好き=3、どちらでもない=2、嫌
い=1、などの好き嫌いの度合いを示す数値)を含ませた上で、利用主体識別子とアイテ
ム識別子と利用時期情報と評価値とを関連付けてアイテム利用履歴テーブル102A−2
に格納するようにしてもよい。
【0036】
図5(c)に示すアイテム利用履歴テーブル102A−3は、利用時期情報を省略し、
利用主体識別子とアイテム識別子と利用回数とを関連付けた格納形態例である。後述する
ように、関連度算出部104において、利用時期情報を用いない場合は、アイテム利用履
歴テーブル102A−3を用いることで利用履歴格納部102の記憶容量を削減すること
ができる。また、利用リクエストの中に、ユーザのアイテムに対する評価値が含まれる場
合は、利用主体識別子とアイテム識別子と利用回数と最新の評価値とを関連付けてアイテ
ム利用履歴テーブル102A−3に格納するようにしてもよい。
【0037】
なお、
図5(c)に示すアイテム利用履歴テーブル102A−3では、利用時期情報を
格納していないが、あるユーザがあるアイテムを利用した最新の利用時期情報を格納して
もよい。すなわち、利用主体識別子とアイテム識別子と利用回数と最新の利用時期情報と
を関連付けて格納してもよい。あるいは、利用主体識別子とアイテム識別子と利用回数と
最初の(最も古い)利用時期情報とを関連付けて格納してもよい。
【0038】
また、利用履歴格納部102には、アイテム利用履歴テーブル102Aに加え、
図5(
d)に示すようなカテゴリ利用履歴テーブル102Bを格納するようにしてもよい。カテ
ゴリ利用履歴テーブル102Bは、利用主体識別子とカテゴリ識別子と利用時期情報とを
関連付けたテーブルである。この場合、制御部110は、ユーザからの利用リクエストに
際し、アイテム属性格納部101のアイテム情報テーブル101Aを参照して、利用リク
エストのアイテム識別子に対応するカテゴリ識別子を特定し、カテゴリ利用履歴テーブル
102Bに格納する。カテゴリ利用履歴テーブル102Bを格納しておくと、後述するよ
うに、アイテム推薦形式およびカテゴリ推薦形式に対応する関連集合を作成する際(
図1
4のステップS400)に、効率よく処理が行なえる場合がある。
【0039】
価格情報格納部103は、アイテムの価格情報を記録したアイテム価格情報テーブル1
03Aと、カテゴリの価格情報を記録したカテゴリ価格情報テーブル103Bとを格納し
ている。
図6(a)は、アイテム価格情報テーブル103Aの一例を示している。本図に
示すように、アイテム価格情報テーブル103Aは、アイテム識別子と、価格情報とを対
応付けて格納する。アイテムの価格情報は、そのアイテムの価格である。ただし、必ずし
も円、ドル、ユーロといった実際の通貨に基づく価格である必要はない。例えば、本実施
形態に係るアイテム提供サービスや、提携している関連サービスで使用できる独自のポイ
ントサービスの値であってもよい。なお、本図の例から分かるように、価格情報(価格)
が「0円」である無料のアイテムが存在してもよい。また本図に示すように、価格の安い
順にアイテムを格納してもよいし、高い順に格納してもよい。もちろんアイテム識別子の
順番に格納してもよい。
【0040】
図6(b)は、カテゴリ価格情報テーブル103Bの一例を示している。本図に示すよ
うに、カテゴリ価格情報テーブル103Bは、カテゴリ識別子と、価格情報とを対応付け
て格納する。カテゴリの価格情報は、そのカテゴリに属する各アイテムの価格の合計値ま
たは代表値とすることができる。価格の代表値は、例えば、そのカテゴリに属するアイテ
ムの価格の平均値、中央値、最頻値、四分位値、最大値、最小値などである。
【0041】
図6(b)に示したカテゴリ価格情報テーブル103Bでは、そのカテゴリに属するア
イテムの価格の合計値をカテゴリの価格情報としている。なお本図から分かるように、価
格が「0円」であるカテゴリ(そのカテゴリに属するアイテムがすべて無料)が存在して
もよい。またカテゴリ識別子を格納する場合も、価格の安い順または高い順にアイテムを
格納してもよい。なお、価格情報をアイテム属性格納部101に記録するようにして、価
格情報格納部103を省略してもよい。
【0042】
推薦情報格納部108は、情報選択部107で選択された推薦情報を記録する推薦情報
テーブルを格納する。推薦情報は、利用主体識別子と、それに関連する識別子(以下「関
連識別子」と称する)とを対応させた情報である。ここで、関連識別子としては、アイテ
ム識別子またはカテゴリ識別子を用いることができる。すなわち、推薦情報格納部108
は、
図7(a)、
図7(b)に示すような2種類の推薦情報テーブルを格納する。
【0043】
図7(a)は、関連識別子をアイテム識別子(関連アイテム識別子)とし、利用主体識
別子と関連アイテム識別子と推薦順位とを対応させて格納したアイテム推薦情報テーブル
108Aの例を示している。関連アイテム識別子は、利用主体識別子と関連するアイテム
の識別子である。以下では、利用主体識別子に対して関連アイテム識別子に対応するアイ
テムを推薦する形式を「アイテム推薦形式」と称する。
【0044】
アイテム推薦情報テーブル108Aでは、1つの利用主体識別子に、1つ以上の関連ア
イテム識別子が対応付けられている。「UserID−1」に対応する関連アイテムはN
1個格納されており、「UserID−2」に対応する関連アイテムはN2個格納されてい
る。ここで、N1とN2は同じであっても、異なっていてもよい。すなわち、利用主体識別
子ごとの関連識別子の個数がすべて同じであってもよいし、利用主体識別子ごとに関連識
別子の個数が異なっていてもよい。
【0045】
推薦順位は、利用主体識別子ごとに関連アイテムを推薦する順位を示しており、ここで
は番号が小さいほど優先順位が高く、優先的にユーザに提示されるものとする。本図では
、各々の利用主体識別子に対して、推薦順位の高い順に関連識別子(関連アイテム識別子
)を格納しているが、推薦順位と対応付けて関連識別子を格納する場合は、適当な順序で
格納してもよい。
【0046】
なお、推薦順位の代わりに、数値が大きいほど優先順位が高く、優先的にユーザに提示
されるような推薦度を格納するようにしてもよい。また、各推薦情報テーブルにおいて推
薦順位を省略してもよい。この場合は、各推薦情報テーブルにおいて、利用主体識別子ご
とに推薦順位の高い順、または推薦順位の低い順に関連識別子を格納すればよい。すなわ
ち、ある利用主体識別子に対する関連識別子の推薦順位の情報を、関連識別子の格納順序
(格納位置)に持たせてもよい。あるいは、記録された関連識別子をすべて同じ順位とし
て扱ったり、各推薦情報テーブルを読み出す際に、ランダムに推薦順位を付与してもよい
。
【0047】
図7(b)は、関連識別子をカテゴリ識別子(関連カテゴリ識別子)とし、利用主体識
別子と関連カテゴリ識別子と推薦順位とを対応させて格納したカテゴリ推薦情報テーブル
108Bの例を示している。関連カテゴリ識別子は、利用主体識別子と関連するカテゴリ
の識別子である。以下では、利用主体識別子に対して関連カテゴリ識別子に対応するカテ
ゴリを推薦する形式を「カテゴリ推薦形式」と称する。カテゴリ推薦形式は、例えば、ユ
ーザにクリエイター(アイテムの作成者)やジャンルに関する推薦情報を提供する場合に
用いることができる。
【0048】
推薦順位は、アイテム推薦情報テーブル108Aと同様な意味であり、同様に推薦順位
の格納を省略することも可能である。
【0049】
以下では、アイテム推薦情報テーブル108Aを用いた情報提供(アイテム推薦形式)
とカテゴリ推薦情報テーブル108Bを用いた情報提供(カテゴリ推薦形式)とを両方実
施する場合を例にして説明するが、これらのうちの一方のみを実施するようにしてもよい
。その場合、必要な種類の推薦情報テーブルのみ格納すればよい。
【0050】
関連度算出部104は、利用履歴格納部102に格納されたデータを用いて、上述した
「アイテム推薦形式」「カテゴリ推薦形式」に対応する2種類の関連度を算出して関連集
合を作成し、関連集合格納部105に格納させる。
【0051】
関連集合格納部105は、利用主体識別子と、関連識別子と、関連度とを対応させた関
連度テーブル105A/105Bを格納する。関連度とは、利用主体識別子と関連識別子
との関連性の高さを示す数値であり、利用主体識別子に対応するユーザが関連識別子に係
るアイテムまたはカテゴリを好む程度を予測した数値である。
【0052】
図8は、関連度テーブル105A/105Bの一例を示している。関連度テーブル10
5A、105Bに格納されている、ある1つの利用主体識別子に対応する関連識別子の集
合をその利用主体識別子の関連集合と称する。
【0053】
上述したように、関連識別子は、アイテム識別子またはカテゴリ識別子であり、それぞ
れに応じて、2種類の格納形式があるが、本図では簡略化して示している。以下では、利
用主体識別子と関連アイテム識別子との関連度を関連度テーブル105Aに記録し、利用
主体識別子と関連カテゴリ識別子との関連度を関連度テーブル105Bに記録するものと
する。
【0054】
本図の例では、利用主体識別子「UserID−1」に対応する関連識別子をL1個、
利用主体識別子「UserID−2」に対応する関連識別子をL2個格納している。ここ
で、L1とL2は同じであっても、異なっていてもよい。すなわち、すべての利用主体識別
子に対して同じ数の関連識別子を格納してもよいし、利用主体識別子ごとに異なる数の関
連識別子を格納してもよい。また、関連度算出部104で関連度が算出された利用主体識
別子と関連識別子の組み合わせをすべて格納してもよいし、利用主体識別子との関連度の
高い関連識別子のみを関連集合として格納してもよい。一部のみを格納することにより、
関連集合格納部105記憶容量を削減することができる。また、本図に示すように、利用
主体識別子ごとに、関連度の大きい順に関連識別子を格納してもよい。
【0055】
関連集合の要素数(関連識別子の数)は、基本的には複数であるが、要素数が「1」の
関連集合が存在していてもよい。ただし、少なくとも1つ以上の関連集合の要素数は「2
」以上である必要がある。なお、情報選択装置10以外の他の装置で算出された関連集合
および関連度を関連度テーブル105A、105Bに記録してもよく、その場合は関連度
算出部104を省略することができる。
【0056】
情報選択部107は、価格情報格納部103のアイテム価格情報テーブル103A、カ
テゴリ価格情報テーブル103Bに格納された価格情報と、関連集合格納部105の関連
度テーブル105A、105Bに格納された関連度とを用いて、関連集合格納部105の
関連度テーブル105A、105Bに格納された利用主体識別子ごとに関連識別子を選択
し、その選択された関連識別子と利用主体識別子との組み合わせを推薦情報として、推薦
情報格納部108の各推薦情報テーブル108A、108Bに格納する。
<アイテム提供サーバ>
【0057】
アイテム提供サーバ20は、端末装置30からの要求に応じて、アイテムおよびアイテ
ムに関する情報を提供する装置である。
図9は、アイテム提供サーバ20の構成を示すブ
ロック図である。本図に示すように、アイテム提供サーバ20は、ユーザ管理部201と
、アイテム格納部202と、データ格納部203と、送受信部204と、制御部205と
を備えて構成されている。
【0058】
アイテム提供サーバ20は、CPU、RAM、ROM、HDD(ハードディスクドライ
ブ)、ネットワークインタフェース等を備える一般的なコンピュータを用いて構成するこ
とができる。すなわち、一般的なコンピュータは、以下で説明するような処理を行なうた
めのプログラムを実行することにより、アイテム提供サーバ20として機能することがで
きるようになる。
【0059】
送受信部204は、ネットワーク40(
図2の構成の場合は、さらにネットワーク42
)を介して情報選択装置10および端末装置30との間でデータを送受信する処理を行な
う。制御部205は、アイテム提供サーバ20の全体の制御を行なう。
【0060】
ユーザ管理部201は、端末装置30を利用するユーザを一意に識別するユーザ識別子
、または端末装置30を一意に識別するための端末識別子である利用主体識別子を少なく
とも格納している。 アイテム提供サーバ20は、例えば、ユーザにアイテム利用を開始
させるに先立ち、入会処理等を行なって、入会処理の終了した利用主体識別子をユーザ管
理部201に格納する。また、必要に応じて、利用主体識別子に対応させて、ログイン名
、パスワード、氏名、生年月日、連絡先、決済方法等のユーザ属性情報をユーザ管理部2
01に格納するようにしてもよい。
【0061】
アイテム格納部202は、アイテム提供サーバ20が提供するアイテムに関する情報を
格納する。アイテム格納部202は、情報選択装置10のアイテム属性格納部101と同
様な情報を格納する。ただし、アイテムが有体の物品ではなく、デジタルコンテンツ等で
あって、ネットワーク40を介して端末装置30に配信可能である場合には、アイテム属
性格納部101のデータに加えて、アイテム識別子と、アイテム本体(デジタルコンテン
ツ等のデータ)とを対応させて格納する。
【0062】
なお、制御部205は、アイテム格納部202が更新されるごと、または所定のスケジ
ュールに基づいて、アイテム格納部202のデータを、送受信部204を介して情報選択
装置10に送信し、アイテム属性格納部101に格納させるようにしてもよい。また逆に
制御部205は、情報選択装置10から送信されるアイテム属性格納部101のデータを
受信し、アイテム格納部202に格納させるようにしてもよい。あるいは、情報選択装置
10からアイテム提供サーバ20にアイテム属性情報を要求するメッセージを送信するよ
うにし、制御部205が、それに応じたデータをアイテム格納部202から読み出して、
送受信部204を介して情報選択装置10に送信するようにしてもよい。
【0063】
データ格納部203は、様々なデータを格納することができる。例えば、情報選択装置
10の推薦情報格納部108に格納されたデータをコピーしてデータ格納部203に格納
することができる。この場合、端末装置30は、アイテム提供サーバ20から推薦情報を
受信することができるので、情報選択装置10の処理負荷を低減することができる。また
、情報選択装置10の利用履歴格納部102と同様なデータを格納してもよい。この場合
、情報選択装置10からデータ格納部203を参照できるようにして、情報選択装置10
の利用履歴格納部102を省略することも可能である。
<端末装置>
【0064】
端末装置30は、ユーザが使用する装置である。
図10は、端末装置30の構成を示す
ブロック図である。本図に示すように、端末装置30は、制御部301と、送受信部30
2と、ブラウザ部303と、アプリケーション部304とを備えて構成されている。端末
装置30は、CPU、RAM、ROM、HDD(ハードディスクドライブ)、ネットワー
クインタフェース等を備える一般的なコンピュータ等を用いることができる。すなわち、
一般的なコンピュータは、以下で説明するような処理を行なうためのプログラムを実行す
ることにより、端末装置30として機能することができるようになる。また、端末装置3
0は、Webブラウザ機能等を備えた携帯電話や、携帯端末装置等を用いて構成すること
もできる。
【0065】
端末装置30には、Webブラウザに代表されるWebページにアクセスしてその情報
を表示するプログラムがインストールされており、ブラウザ部303を構成している。ま
た、種々のアプリケーションプログラムを実行することにより、アプリケーション部30
4が構成される。
【0066】
端末装置30としてコンピュータを用いた場合には、ディスプレイ等の表示装置320
や、キーボード、マウス、トラックボール、リモコン等のユーザからの操作指示を受け付
けるための入力装置330が接続される。端末装置30として携帯電話や、携帯端末装置
等を用いた場合は、表示装置、入力装置は内蔵されているが、以下では、便宜的に表示装
置320、入力装置330が接続されているものとして説明する。
<システム動作>
<システム全体の動作>
【0067】
図11のフローチャートを参照して、ネットワークシステム全体の基本的な動作を説明
する。この基本的な動作は、多少の変更はあるがすべての実施例で共通である。まず、ス
テップS100において、端末装置30は、ブラウザ部303を用いて、アイテム提供サ
ーバ20のURL(Uniform Resource Locator)にアクセスする。具体的には、アイテム
提供サーバ20の提供する所定のWebページへのリクエスト(利用開始リクエスト)を
アイテム提供サーバ20に送信する。
【0068】
端末装置30としてパーソナルコンピュータ等を用いる場合は、端末装置30を利用す
るユーザに、事前に設定させたログイン名(ユーザID)とパスワードとを入力させ、こ
れらを利用開始リクエストに含めて送信する。あるいは、Cookie等の技術を用いて
、端末装置30を利用するユーザを識別可能なデータを利用開始リクエストに含めて送信
すれば、ログイン名とパスワードの送信を省略できる。ログイン名とパスワードを利用開
始リクエストに含めて送信する場合は、ステップS100の前に、アイテム提供サーバ2
0から端末装置30に、ログイン名とパスワードの入力を受け付けるためのHTML(Hy
per Text Markup Language)データ等を送信しておけばよい。
【0069】
また、端末装置30として携帯電話等を用いる場合は、端末固有の端末識別子を利用開
始リクエストに含めて送信すればよい。この場合は、ログイン名とパスワードの送信を省
略することができる。
【0070】
ステップS110において、アイテム提供サーバ20の制御部205は、送受信部20
4を介して端末装置30からの利用開始リクエストを受信し、ユーザ管理部201を参照
しながら、登録済のユーザか否かを判定する。具体的には、利用開始リクエストにログイ
ン名とパスワードが含まれている場合は、それらをユーザ管理部201に格納されている
ログインおよびパスワードと照合する。また、利用開始リクエストに端末識別子が含まれ
る場合は、それがユーザ管理部201に格納されている利用主体識別子と一致するか判定
する。登録済のユーザである場合(Yes)は、ステップS130に進み、そうでない場
合(No)は、ステップS120に進む。
【0071】
ステップS120において、アイテム提供サーバ20の制御部205は、送受信部20
4を介して、端末装置30に入会処理を行なうためのWebページ(HTML)を送信す
る。本図には示していないが、端末装置30を利用するユーザは、入力装置330を利用
して入会処理のWebページに必要な情報を入力し、アイテム提供サーバに送信する等の
操作を行ない、アイテム提供サーバ20は、その情報をユーザ管理部201に格納する等
の入会処理が行われる。端末装置30は、入会処理完了後に、改めて利用開始リクエスト
を送信することができる。
【0072】
ステップS130において、アイテム提供サーバ20の制御部205は、アイテム格納
部202を参照しながら、利用開始リクエストに対応するWebページの応答データであ
り、アイテムまたは/およびカテゴリを紹介する情報を含む応答データを作成し、送受信
部204を介して端末装置30に送信する。応答データは、HTMLデータ、画像データ
、映像データ、音声データなどで構成されており、複数回に分けて端末装置30に送信さ
れる場合がある。また、応答データには、あるアイテム(またはカテゴリ)に関連する関
連アイテム(または関連カテゴリ)をユーザに表示するための情報と、ユーザにアイテム
を利用させるための情報とが含まれている。またCookie等の技術を用いて、応答デ
ータにユーザや端末装置30を識別するための情報を含めてもよい。
【0073】
ステップS140において、端末装置30は、アイテム提供サーバ20から応答データ
を受信し、表示装置320にその情報を表示する。表示画面の例を
図12に示す。
図12
は、応答データにアイテムを紹介する情報が含まれる場合の表示例である。本図の例は、
アイテム提供サーバ20が最近提供を開始した「新着アイテム」を紹介する表示画面であ
る。ただし、本図に示すようなアイテムを紹介する情報は、種々のタイミングで端末装置
30に送信することができる。
【0074】
本図において「アイテムABC」は1番目のアイテムのタイトルであり、「SF」は1
番目のアイテムのカテゴリ名であり、「このアイテムは、2001年に制作された映画で
…」という表示は1番目のアイテムの説明情報である。また、各々のアイテムごとに、そ
のアイテムを利用するためのボタンやリンク等(利用リンク)が表示される。2番目以降
のアイテムについても同様な表示がされる。
【0075】
また
図12に示すように、端末装置30を利用するユーザに対して、そのユーザとの関
連度の高い(そのユーザの嗜好や興味に合う可能性の高い)アイテム情報を表示するため
のボタンやリンク等(関連アイテムリンク)と、そのユーザとの関連度の高いカテゴリ情
報を表示するためのボタンやリンク等(関連カテゴリリンク)とが表示される。以下では
、関連アイテムリンクと関連カテゴリリンクを合わせて、関連リンクと称する。
【0076】
図12の関連アイテムリンクは、「関連アイテム表示」ボタンに対応付けられており、
上述したアイテム推薦形式の推薦情報を表示させるためのリンクである。
図12の関連カ
テゴリリンクは、「関連カテゴリ表示」ボタンに対応付けられており、カテゴリ推薦形式
の推薦情報を表示させるためのリンクである。ユーザは、入力装置330を使用したクリ
ック等の操作により、関連リンクまたは利用リンクを選択することができる。なお表示画
面には表示されないが、応答データには、各々のアイテムのアイテム識別子、および端末
装置30を利用するユーザに係る利用主体識別子が含まれている。
【0077】
図11のフローチャートの説明に戻って、ステップS150において、端末装置30は
、関連リンク(関連アイテムリンクまたは関連カテゴリリンク)がユーザから入力装置3
30を介して選択されたか否かを判定する。関連リンクが指定された場合(Yes)は、
ステップS160に進み、指定されていない場合(No)は、ステップS190に進む。
【0078】
ステップS160において、端末装置30は、関連リンクに対応するURLにリクエス
ト(推薦リクエスト)を送信する。本実施形態では、関連リンクが情報選択装置10の所
定のURLに対応する場合を説明するが、関連リンクをアイテム提供サーバ20の所定の
URLに対応させてもよい。推薦リクエストには、利用主体識別子(端末装置30を利用
するユーザのユーザ識別子または端末装置30の端末識別子)と、関連アイテムリンクで
あるか関連カテゴリリンクであるかを示すリンク種別情報とが含まれている。以下では、
この推薦リクエストに含まれる利用主体識別子を「リクエスト利用主体識別子」(情報選
択に係る利用主体識別子)と称する。
【0079】
ステップS170において、情報選択装置10の制御部110は、送受信部109を介
して、推薦リクエストを受信し、それに含まれるリクエスト利用主体識別子に対応する表
示用推薦データを作成して端末装置30に送信する。このとき、制御部110は、以下に
説明する「アイテム推薦形式」と「カテゴリ推薦形式」とに対応する2種類の処理を行な
う。
【0080】
<アイテム推薦形式>
【0081】
図7(a)に示した推薦情報格納部108のアイテム推薦情報テーブル108Aを参照
しながら、リクエスト利用主体識別子に一致する利用主体識別子を特定し、それに対応す
る関連アイテム識別子と推薦順位とを読み出す。さらに、その関連アイテム識別子に対応
するアイテム属性情報をアイテム属性格納部101のアイテム情報テーブル101Aから
読み出す。そして、関連アイテム識別子と、推薦順位と、アイテム属性情報とを対応させ
た表示用推薦データを作成する。
【0082】
例えば、
図7(a)に示した例において、リクエスト利用主体識別子が「UserID
−1」である場合は、それと同じ利用主体識別子に対応した関連アイテム識別子である「
ItemID−1000」「ItemID−1020」…「ItemID−1035」と
、その推薦順位「1」「2」…「N1」を読み出す。ただし、特定した利用主体識別子に
対応する関連アイテム識別子をすべて読み出してもよいし、推薦順位の高い順に所定個数
読み出してもよい。また推薦リクエストの中に、読み出す推薦情報の個数が含まれている
場合は、推薦順位の高い順にその個数だけを読み出す。
【0083】
このとき、利用履歴格納部102のアイテム利用履歴テーブル102Aを参照しながら
、リクエスト利用主体識別子に対応するユーザが過去に利用したアイテム識別子(利用済
みアイテム識別子)を特定し、利用済みアイテム識別子(利用済みアイテム)を推薦情報
に含めない処理(利用済み除外処理)を行なってもよい。このような処理を行なうことで
、ユーザが1回しか同じアイテムを購入しない性質を持つようなアイテム提供サービスに
おいて、精度の高い推薦が可能になる。例えば、1度購入したデジタルコンテンツは、端
末装置30で繰り返し利用(再生)できる、といったサービスに適している。
【0084】
また、過去の利用回数が所定数以上のアイテムを推薦情報に含めない処理や、最近3ヶ
月以内等の所定期間内に利用したアイテムを推薦情報に含めない処理を行なってもよい。
このような処理を行なうことで、ユーザが利用しない可能性の高いアイテムが推薦情報に
入り難くなるので、推薦情報に対するユーザの信頼感や興味の度合いを高めることができ
る。
【0085】
そして制御部110は、アイテム属性格納部101を参照しながら、読み出した関連ア
イテム識別子に対応する「タイトル」「説明情報」などのアイテム属性情報と、「カテゴ
リ名」などのカテゴリ属性情報とを読み出し、関連アイテム識別子と2つの属性情報と推
薦順位とを合わせて表示用推薦データを作成する。
【0086】
<カテゴリ推薦形式>
【0087】
図7(b)に示した推薦情報格納部108のカテゴリ推薦情報テーブル108Bを参照
しながら、リクエスト利用主体識別子に一致する利用主体識別子を特定し、それに対応す
る関連カテゴリ識別子と推薦順位とを読み出す。ここで、特定した利用主体識別子に対応
する関連カテゴリ識別子をすべて読み出してもよいし、推薦順位の高い順に所定個数読み
出してもよい。さらに、その関連カテゴリ識別子に対応するカテゴリ属性情報(カテゴリ
名およびカテゴリ説明情報)をアイテム属性格納部101から読み出す。そして、関連カ
テゴリ識別子と、推薦順位と、カテゴリ属性情報とを対応させた表示用推薦データを作成
する。
【0088】
このとき、ユーザが過去に利用したカテゴリを除外して表示用推薦データを作成しても
よい。具体的には、利用履歴格納部102のアイテム利用履歴テーブル102Aとアイテ
ム情報テーブル101Aとを参照しながら、リクエスト利用主体識別子に対応するユーザ
が、過去に利用したアイテムについてのカテゴリ識別子(利用済みカテゴリ識別子)を特
定する。なお、カテゴリ利用履歴テーブル102Bを用いている場合は、カテゴリ利用履
歴テーブル102Bを参照すればよい。
【0089】
そして、カテゴリ推薦情報テーブル108Bから関連カテゴリ識別子を読み出す際に、
利用済みカテゴリ識別子を除外する処理を行なう。このような処理を行なうことで、ユー
ザが1回しか同じカテゴリのアイテムを購入しない性質を持つようなアイテム提供サービ
スにおいて、精度の高い推薦が可能になる。
【0090】
また、過去の利用回数が所定数以上のカテゴリを推薦情報に含めない処理や、最近3ヶ
月以内等の所定期間内に利用したカテゴリを推薦情報に含めない処理を行なってもよい。
このような処理を行なうことで、ユーザが利用しない可能性の高いカテゴリが推薦情報に
入り難くなるので、推薦情報に対するユーザの信頼感や興味の度合いを高めることができ
る。
【0091】
なお、アイテム提供サーバ20のユーザ管理部201に、ユーザの氏名やログイン名な
どのユーザ属性情報が格納されている場合には、上述した「アイテム推薦形式」、「カテ
ゴリ推薦形式」の表示用推薦データを作成する際にこれらを読み出して、表示用推薦デー
タの中に、リクエスト利用主体識別子と、リクエスト利用主体識別子に対応するユーザ属
性情報とを含めてもよい。
【0092】
また、推薦リクエストの種別に対応する推薦情報テーブルにおいて、推薦順位が格納さ
れておらず、関連識別子の格納順序が推薦順位の情報を持っている場合は、その格納順序
に従って、表示用推薦データにおける関連識別子の順序を決めればよい。例えば、格納順
序が1番目の関連アイテム識別子を表示用推薦データの1番目にし、格納順序が2番目の
関連アイテム識別子を表示用推薦データの2番目にすればよい。また、表示用推薦データ
を作成する際に、ランダムな推薦順位を生成して付与したり、表示用推薦データにおける
関連識別子の順序をランダムに決定してもよい。
【0093】
図11のフローチャートの説明に戻って、ステップS180において、端末装置30は
、ステップS170で情報選択装置10から送信された表示用推薦データを受信し、例え
ば、
図13に示す形式で表示装置120に推薦リストとして表示する。
図13(a)は、
「アイテム推薦形式」に対応する処理が行われた場合に、推薦リクエストを発行したユー
ザとの関連度が高いアイテムを「○○○さんへのおすすめアイテム」として表示する画面
の一例である。
【0094】
「○○○」には、リクエスト利用主体識別子に対応するユーザの氏名やログイン名が表
示される。このような表示を行なうことにより、他のユーザに対する推薦情報と共通のも
のではなく、そのユーザ専用に作成された推薦情報であることをユーザに明確に伝えるこ
とができるので、推薦情報に対するユーザの信頼感や興味の度合いを高めることができる
。なお、氏名やログイン名を表示しなくても、「あなただけにお知らせする、とっておき
アイテムです」など、そのユーザ専用に作成された推薦情報であることが分かる表示を行
なうことで、同様の効果を得ることができる。
【0095】
アイテムの表示順序は、推薦順位に従って決められており、推薦順位が上位のアイテム
ほど、ユーザの目に留まりやすい位置に表示される。例えば、本図に示すように上下方向
に各々のアイテムの情報を配置する場合は、推薦順位が上位のアイテムの表示画面の上側
に表示するとよい。また、左右方向に各々のアイテムの情報を配置する場合は、表示画面
の左側に表示するとよい。「アイテムOPQ」は1番目のアイテム(推薦順位が「1」の
アイテム)のタイトルであり、「サスペンス」は1番目のアイテムのカテゴリ名であり、
「このアイテムは、目が離せない…」という表示は、1番目のアイテムの説明情報である
。
図12に示した表示例と同様に、各々のアイテムに対して、利用リンクに対応付けられ
た「アイテム利用」ボタンが表示される。2番目以降のアイテムについても同様な表示が
される。
【0096】
図13(b)は、表示用推薦データ作成・送信処理(ステップS170)で「カテゴリ
推薦形式」に対応する処理が行われた場合に、推薦リクエストを発行したユーザとの関連
度が高いカテゴリを「○○○さんへのおすすめカテゴリ」として表示する画面の一例であ
る。
【0097】
カテゴリの表示順序は、推薦順位に従って決められている。「カテゴリRST」は1番
目のカテゴリ(推薦順位が「1」のカテゴリ)のカテゴリ名であり、「このカテゴリは、
最近非常に注目され…」という表示は、1番目のカテゴリの説明情報である。各々のカテ
ゴリに対して、「アイテム一覧表示」ボタンが表示される。ユーザが「アイテム一覧表示
」ボタンを押すと、この画面あるいは別の画面に、そのカテゴリに属するアイテムの一覧
と、それを利用するための利用ボタン(利用リンク)が表示される。なお、
図13(b)
に示す画面に、各々のカテゴリに属する代表的なアイテムのタイトル等をあらかじめ表示
してもよい。2番目以降のアイテムについても同様な表示がされる。
【0098】
図11のフローチャートの説明に戻って、ステップS190において、端末装置30は
、利用リンクがユーザから入力装置330を利用して選択されたか否かを判定する。この
利用リンクは、代表的には、アイテムの購入要求とすることができるが、アイテムの再生
、アイテムのプレビュー、アイテムの詳細情報の表示、アイテムに対する評価情報(評価
値)の登録などの種々の要求を含めることができる。利用リンクが選択された場合(Ye
s)は、ステップS200に進み、そうでない場合(No)はステップS250に進む。
【0099】
ステップS200において、端末装置30は、利用リンクに対応するURLにリクエス
ト(利用リクエスト)を送信する。本実施形態では、利用リンクがアイテム提供サーバ2
0の所定のURLに対応する場合を説明する。なお端末装置30は、利用リクエストをア
イテム提供サーバ20に加えて、情報選択装置10に直接送信してもよい。
【0100】
各々の利用リンクには、選択対象となるアイテムのアイテム識別子が付与されており、
利用リクエストには、ユーザが選択したアイテムのアイテム識別子と、そのユーザまたは
端末装置30を識別する利用主体識別子とが含まれている。なお、ユーザが一度に複数の
アイテムを利用する場合は、1つの利用リクエストに複数のアイテムのアイテム識別子を
含めてもよいし、複数の利用リクエストを送信してもよい。
【0101】
ステップS210において、アイテム提供サーバ20の送受信部204は、端末装置3
0から受信した利用リクエストを情報選択装置10に送信し中継する。このとき、アイテ
ム提供サーバ20の制御部205が、利用リクエストからアイテム識別子や利用主体識別
子などの情報を取り出し、利用情報として、データ格納部203に格納させるようにして
もよい。
【0102】
ステップS220において、情報選択装置10の制御部110が、送受信部109を介
して、利用リクエストを受信し、利用履歴情報として利用履歴格納部102に格納させる
。そして、制御部110は、送受信部109を介して、利用履歴情報の格納を終了したこ
とを示すメッセージをアイテム提供サーバ20に送信する。
【0103】
ステップS230において、アイテム提供サーバ20の制御部205が、送受信部20
4を介して情報選択装置10からの格納終了メッセージを受信した後、端末装置30にア
イテムを提供する処理を行なう。例えば、提供対象のアイテムがデジタルコンテンツであ
る場合には、アイテム格納部202から、利用リクエストに含まれるアイテム識別子に対
応するアイテム本体を読み出して、送受信部204を介して端末装置30に送信する。ま
た、アイテムが物品である場合には、配送事業者のシステムに配送依頼の情報を送る配送
処理などを行なう。このとき必要に応じて、課金処理などを行なう。また、アイテムの詳
細情報が要求された場合には、アイテム格納部202から「説明情報」などを読み出して
、端末装置30に送信する。
【0104】
ステップS240において、端末装置30は、アイテム提供サーバ20から提供された
アイテムの利用に係る処理を行なう。例えば、アイテムがデジタルコンテンツである場合
には、アイテムの再生、表示などを行なう。また、アイテムが物品である場合には、配送
処理を受付した旨のメッセージ等を画面に表示する。
【0105】
ステップS250において、端末装置30は、ユーザがブラウザを終了する等の操作終
了指示があるか否かを判定する。操作終了指示がある場合(Yes)は、端末装置30の
処理を終了し、操作終了指示がない場合(No)は、ステップS150に戻って処理を継
続する。
【0106】
以上がシステム全体の動作の説明である。なお、本実施形態においては、ステップS1
60で、端末装置30から情報選択装置10に推薦リクエストを送信しているが、これ以
外の方法を用いてもよい。例えば、端末装置30からアイテム提供サーバ20に推薦リク
エストを送信し、アイテム提供サーバ20が情報選択装置10に推薦リクエストを中継し
てもよい。また、適当なタイミングで、情報選択装置10の制御部110が、送受信部1
09を介して、推薦情報格納部108に格納されたデータをアイテム提供サーバ20に送
信すると共に、アイテム提供サーバ20の制御部205が、送受信部204を介して、そ
のデータを受信し、データ格納部203に格納させておいてもよい。そして、ステップS
160において、端末装置30からアイテム提供サーバ20に推薦リクエストを送信し、
ステップS170に相当する処理として、アイテム提供サーバ20の制御部205が、デ
ータ格納部203から推薦データを読み出し、表示用推薦データを作成して、端末装置3
0に送信するようにしてもよい。この場合は、表示用推薦データ作成とその送信に伴う情
報選択装置10の処理負荷を減らすことができる。
【0107】
また、本実施形態においては、ステップS210で、アイテム提供サーバ20が端末装
置30からの利用リクエストを情報選択装置10に中継しているが、これ以外の方法を用
いてもよい。例えば、ステップS200の利用リクエストの送信と同時、あるいは適当な
タイミングで、端末装置30から情報選択装置10に直接、利用リクエストを送信しても
よい。
【0108】
また、ステップS220において、情報選択装置10は、利用履歴情報の格納に加えて
、利用リクエストに含まれる利用主体識別子に対応する表示用推薦データをステップS1
70と同様な方法で作成し、表示用推薦データをアイテム提供サーバ20に送信してもよ
い。そして、ステップS230において、アイテム提供サーバ20が、アイテム提供処理
に加えて、表示用推薦データを端末装置30に送信してもよい。すなわちこの場合、端末
装置30は、利用リクエストを送信するごとに、利用リクエストに含まれるアイテム識別
子に対応する推薦情報を受信することができる。
【0109】
また、携帯電話等の端末識別子を利用することができ、特別なユーザ登録処理が不要な
アイテム提供サービスにおいて、ステップS200で送信される利用リクエストに、利用
主体識別子を含めることができる場合であれば、ステップS110の登録済ユーザ確認処
理と、ステップS120の入会処理に必要なデータの送信とを省略することも可能である
。
<情報選択装置の動作>
<推薦情報作成動作>
【0110】
第1実施例における情報選択装置10の処理動作について説明する。まず、情報選択装
置10が推薦情報を作成する動作について
図14のフローチャートを参照して説明する。
【0111】
情報選択装置10の制御部110は、所定のタイミングで情報選択装置10の各処理部
に指示を出し、推薦情報を作成する処理を開始する。推薦情報作成のタイミングとして、
次の3種類を用いることができる。
【0112】
推薦情報作成の第1のタイミングは、所定の日時または所定の時間間隔である。例えば
、「毎日午前6時と午後6時」「毎週月曜の午前10時30分」「12時間ごと」「24
時間ごと」などである。このとき、「平日は午前6時、土日は午前6時と午後6時」「平
日は3時間ごと、土曜日は6時間ごと、日曜日は12時間ごと」などのように時間間隔が
変動してもよい。また、夏は時間間隔を短くして、冬は時間間隔を長くするなど、季節に
応じて時間間隔を変えてもよい。この第1のタイミングを用いると、他のタイミングを用
いた場合より情報選択装置10の処理負荷を減らすことができる。特に、推薦リクエスト
数が少ない時間帯に推薦情報を作成するように設定すれば、情報選択装置10の処理負荷
の低減に効果的である。
【0113】
推薦情報作成の第2のタイミングは、端末装置30の推薦リクエスト送信処理(
図11
ステップS160)による端末装置30からの推薦リクエストを所定回数受信するごとで
ある。この場合は、基本的には所定回数を1として、推薦リクエストを受信するごとに推
薦情報を作成するのがよい。以下の説明では、所定回数を1とするが、所定回数を2以上
にすることも可能である。所定回数を1とする場合は、まず推薦リクエストに含まれる利
用主体識別子(リクエスト利用主体識別子)に対する推薦情報を作成し、その後に表示用
推薦データ作成・送信処理(ステップS170)を行なう。このようにすれば、リクエス
ト利用主体識別子に対して、常に最新の推薦情報を提供することができる。
【0114】
推薦情報作成の第3のタイミングは、アイテム提供サーバ20を中継して送られる(ス
テップS210)、端末装置30の利用リクエスト送信(ステップ200)による利用リ
クエストを所定回数受信するごとである。この所定回数を調整することにより、情報選択
装置10の処理負荷の大きさと、推薦情報の新しさとのバランスを調整することができる
。
【0115】
通常は、所定回数をある程度大きな値として、情報選択装置10の処理負荷があまり大
きくならないようにするのがよい。一般的には、ある程度の数の利用履歴が追加されない
と、新たな推薦情報を作成しても前回の推薦情報と似た内容になることが多いので、所定
数を適切な値に設定すれば、情報選択装置10の処理負荷を抑えながら、比較的新しい利
用状況を反映させた推薦情報を提供することができる。特に、利用リクエストの数が季節
、曜日、時間帯などにより大きく変動する場合や、利用リクエスト数の増減パターンを事
前に予測するのが難しい場合には、第1のタイミングで推薦情報を作成するよりも、情報
選択装置10の処理負荷の軽減と、比較的新しい利用状況を推薦情報に反映させることと
を両立させやすい。
【0116】
以下の説明において、推薦情報を作成する対象となる利用主体識別子の集合を「推薦基
準集合」と称する。第1のタイミングおよび第3のタイミングで推薦情報を作成する場合
は基本的に、推薦基準集合の要素数が多数となる。第2のタイミングで推薦情報を作成す
る場合は、推薦基準集合の要素数は基本的に1つであるが、複数の場合もある。
【0117】
まず、ステップS400において、制御部110の指示を受けた関連度算出部104が
、「アイテム推薦形式」および「カテゴリ推薦形式」に対応する2種類の関連度を算出し
、これに基づき関連集合を作成し、関連集合を関連集合格納部105に格納させる。 ス
テップS410において、制御部110の指示を受けた情報選択部107が、ステップS
400で算出された関連度、および価格情報格納部103のアイテム価格情報テーブル1
03A、カテゴリ価格情報テーブル103Bに格納された価格情報を用いて、アイテムま
たはカテゴリを選択して、推薦情報格納部108に格納させる情報選択処理を行なう。そ
して、推薦情報作成処理が終了した旨を制御部110に通知する。以上が推薦情報作成動
作の概要である。
【0118】
「アイテム推薦形式」および「カテゴリ推薦形式」に対応する関連集合作成処理(ステ
ップS400)について
図15のフローチャートを参照して説明する。
【0119】
ステップS500において、関連度算出部104は、利用履歴格納部102のアイテム
利用履歴テーブル102Aに記録されている利用履歴を読み出す。ここでは、すべての利
用履歴を読み出してもよいし、所定の条件を満たす利用履歴を読み出してもよい。例えば
、
図6(b)に示したアイテム利用履歴テーブル102A−2のように利用時期情報を記
録した上で、「利用時期が過去4ヶ月以内」「利用時期と現在との差が3日以上かつ30
日未満」などのように、「利用履歴の利用時期情報が所定の範囲にある」という条件を満
たす利用履歴を読み出してもよい。
【0120】
また、ユーザ(利用主体識別子)ごとに利用時期が新しい順に所定個数以内の利用履歴
を読み出してもよい。例えば、所定個数を20個とした場合、利用回数が20回以上のユ
ーザに対しては、利用時期が新しい順に20個ずつの利用履歴を読み出し、利用回数が2
0回未満のユーザに対しては、そのアイテムに関するすべての利用履歴を読み出すように
する。このようにすれば、利用頻度が少なく、最近アイテムを利用していないようなユー
ザに対しても効率よく関連集合を作成することができる。
【0121】
そして、このステップS500で読み出した利用履歴に含まれるユーザ(利用主体識別
子)の集合σを作成する。以下では、このステップで読み出した利用履歴に含まれるアイ
テムの数(アイテム識別子の種類数)をMs、ユーザの数(利用主体識別子の種類数)を
Usとする。
【0122】
ステップS510において、関連度算出部104は、推薦基準集合K1を作成する。上
述したように、第2タイミングで推薦情報を作成する場合には、リクエスト利用主体識別
子を推薦基準集合K1に入れる。第1および第3のタイミングで推薦情報を作成する場合
は、ステップS500で作成したアイテムの集合σを推薦基準集合K1とする。この場合
は、所定条件を満たす利用履歴に含まれる利用主体識別子それぞれに対して関連アイテム
集合が作成されることになる。なお、ここで作成された推薦基準集合K1は、情報選択部
107、制御部110などの他の処理部から参照することができる。
【0123】
ステップS520において、関連度算出部104は、ステップS510で作成された推
薦基準集合K1の中から未処理のユーザを1つ選択する。この処理対象となるユーザを基
準ユーザxとする。
【0124】
ステップS530において、関連度算出部104は、ステップS500で読み出された
利用履歴を用いて、基準ユーザxと、ユーザ集合σに属する他ユーザy(y∈σ、x≠y
)との類似度を算出する。
【0125】
具体的には、基準ユーザxと他のユーザyとが共に利用したことのあるアイテムの数|
I[x]∩I[y]|を算出し、これを類似度とすることができる。また、ユーザxが利
用したアイテムの集合をI[x]、ユーザyが利用したアイテムの集合をI[y]、ユー
ザxとユーザyとが共に利用したことのあるアイテムの数を|I[x]∩I[y]|、ユ
ーザxとユーザyの少なくとも一方が利用したことのあるアイテムの数を|I[x]∪I
[y]|としたとき、[数1]に示すように、ジャカード(Jaccard)係数を用い
てユーザxとユーザyの類似度D[x][y]を算出することができる。
【数1】
【0126】
また、ステップS500で読み出された利用履歴から、利用回数に関する情報やユーザ
がユーザに対して行なった評価の情報(評価値)が得られる場合は、コサイン尺度やピア
ソン積率相関係数を用いて類似度を算出してもよい。例えば、ユーザxのアイテムzに対
する利用回数または評価値をE[x][z]、ユーザyのアイテムzに対する利用回数ま
たは評価値をE[y][z]としたとき、[数2]に示すように、コサイン尺度を用いて
ユーザxとユーザyとの類似度D[x][y]を算出することができる。ここで、Msは
、ステップS500で読み出された利用履歴に含まれるアイテムの数である。
【数2】
【0127】
また、[数3]に示すように、ピアソン積率相関係数を用いて、類似度D[x][y]
を算出してもよい。
【数3】
【0128】
ここで、Ic[x][y]は、ユーザxとユーザyとが共に利用または評価したアイテ
ムの集合であり、Ea[x]は、Ic[x][y]に属するアイテムをユーザxが利用し
た回数の平均値、または評価した評価値の平均値である。Ea[y]は、Ic[x][y
]に属するアイテムをユーザyが利用した回数の平均値または評価値の平均値である。ま
た、E[x][z]とE[y][z]とのユークリッド距離あるいはその他の距離を用い
て、類似度D[x][y]を算出してもよい。
【0129】
また、利用履歴格納部102に利用時期情報が格納されている場合は、E[x][z]
などを算出する際に、利用時期が古い利用履歴より、新しい利用履歴の重みを大きくして
算出してもよい。
【0130】
さらに、ユーザxのアイテムzに対する利用回数または評価値であるE[x][z](
x=1〜Us、z=1〜Ms)を行列要素とする行列に対して、主成分分析や数量化3類
などの多変量解析を適用し、次元数を削減したベクトルを生成し、そのベクトルのコサイ
ン尺度やユークリッド距離などを用いてユーザ間の類似度を算出してもよい。また、上記
以外にも、ユーザ間の類似性を表わす指標であれば、どのような方法を用いてもよい。
【0131】
このようにして算出されたユーザxと、ユーザy(y∈σ、x≠y)との類似度は、関
連度算出部104内部のメモリ(図示せず)に格納される。なお、ステップS520〜S
570のループ(繰り返し)処理において、ユーザxと、ユーザyとの類似度が既に算出
され、関連度算出部104内部のメモリに格納されている場合は、新たな算出を行なわず
に格納されている値を利用してもよい。
【0132】
ステップS540において、関連度算出部104は、基準ユーザxとアイテムzとの関
連度W[x][z]を算出する。
【0133】
関連度算出の第1の方法は、ステップS530で算出された類似度D[x][y]が高
い「類似ユーザ」を特定し、類似ユーザに多く利用されたアイテムほど関連度が高くなる
ように算出する方法である。
【0134】
具体的にはまず、類似度D[x][y]が所定値以上のユーザ、あるいは類似度D[x
][y]が高い順に所定数のユーザを類似ユーザとして特定する。次に、ステップS50
0で読み出された利用履歴を対象にして、類似ユーザが利用したアイテムを特定し、アイ
テムごとに利用回数をカウントし、この利用回数を関連度とする。あるいは利用回数の平
方根や対数値などを用いて関連度を算出してもよい。第1の方法によれば、類似ユーザに
利用されたアイテムの関連度が算出される。類似ユーザに利用されていないアイテムの関
連度は「0」とすればよい。
【0135】
この第1の方法は、ユーザがアイテムを気に入った場合に、そのアイテムを複数回利用
(購入)する性質を持つようなアイテム提供サービスに適している。例えば、端末装置3
0に保存できない形式のデジタルコンテンツや、消耗品の物販などである。
【0136】
関連度算出の第2の方法は、多くの類似ユーザに利用されたアイテムほど関連度が高く
なるように算出する方法である。第1の方法と同様に、類似ユーザを特定した後、ステッ
プS500で読み出された利用履歴を対象にして、類似ユーザが利用したアイテムを特定
し、アイテムごとに利用した人数をカウントし、この利用人数を関連度とする。
【0137】
第2の方法は、ユーザが基本的に同じアイテムを1度しか利用(購入)しない性質のア
イテム提供サービスに適している。例えば、アイテムが端末装置30に保存して何回でも
再生できる形式のデジタルコンテンツであれば、ユーザが再度購入するのは、ユーザが端
末装置30から間違って消去したような例外的なケースが想定され、基本的には同じアイ
テムを1回しか購入しないので、この第2の方法が有効である。また、第1および第2の
方法によれば、類似ユーザの数を適切に設定することにより、少ない計算量で、精度よく
関連度を算出することができる。
【0138】
関連度算出の第3の方法は、ユーザ間の類似度を直接用いて関連度を算出する方法であ
る。具体的にはまず、ステップS500で読み出された利用履歴を対象にして、ユーザy
(y∈σ、x≠y)がアイテムzを利用した回数C[y][z]をカウントする。そして
、[数4]に示すように、類似度D[x][y]と利用回数C[y][z]との積を加算
した値を用いてユーザxとアイテムzとの関連度W[x][z]を算出する。第3の方法
では、アイテムzの利用回数が多く、かつ利用したユーザの類似度が高いほど、関連度が
高く算出される。
【数4】
【0139】
なお[数4]では、類似度D[x][y]が算出されたすべてのユーザの情報を用いて
関連度を算出しているが、類似ユーザを対象にして[数4]の計算を行なってもよい。ま
た[数4]において、ユーザyがアイテムzを利用した場合にC[y][z]=1、利用
していない場合にC[y][z]=0として計算してもよい。このようにすれば、アイテ
ムzを利用したユーザ数が多く、かつ利用したユーザの類似度が高いほど、関連度が高く
算出される。この第3の方法によれば、基準ユーザとアイテムとの関連度をさらに精度よ
く算出することができる。
【0140】
さらに関連度算出の第1〜第3の方法において、アイテム属性格納部101のアイテム
情報テーブル101Aからアイテム時期情報を読み出し、これを用いて処理を行なっても
よい。具体的には、アイテム時期情報が新しいアイテムほど大きな値となる重み係数を算
出し、利用回数や利用ユーザ数を算出する際に、この重み係数を乗じる等の演算を行なう
。このようにすれば、ユーザにとって一般的に価値の高い「新作」アイテムの関連度を高
くして、優先的に推薦情報に入れることができる。
【0141】
ステップS550において、関連度算出部104は、基準ユーザxに関する関連アイテ
ム集合Ω[x]を作成し、関連集合格納部105に格納させる。関連アイテム集合Ω[x
]は、関連識別子がすべてアイテム識別子であるような関連集合である。
【0142】
関連アイテム集合作成の第1の方法は、ステップS540において基準ユーザxとの関
連度を算出したすべてのアイテム(関連度が「0」より大きいすべてのアイテム)を関連
アイテム集合Ω[x]に入れる方法である。この方法は、なるべく多くの推薦結果を出力
したい場合に適している。
【0143】
関連アイテム集合作成の第2の方法は、基準ユーザxとの関連度が高いアイテムを選出
して関連アイテム集合Ω[x]に入れる方法である。具体的には、ステップS540にお
いて関連度を算出したすべてのアイテムの中から、関連度が閾値以上のアイテムを選出す
る。または、関連度が大きい順に所定値を超えない範囲でアイテムを選出してもよい。例
えば、基準ユーザxとの関連度が算出されたアイテムの数が所定数に満たない場合は、関
連度が算出されたすべてのアイテムを選出し、そうでない場合は、関連度が大きい順に所
定数のアイテムを選出すればよい。
【0144】
さらに、基準ユーザxとの関連度が所定値以上のアイテムの中から、関連度が大きい順
に所定数を超えない範囲でアイテムを選出し、それらを関連アイテム集合Ω[x]として
もよい。また関連アイテム集合Ω[x]の要素が所定数以上得られるように、関連度の閾
値を基準ユーザxごとに調整して選出してもよい。この第2の方法によれば、関連集合格
納部105に必要な記憶容量を削減でき、さらにステップS410の処理を効率よく行な
うことができる。
【0145】
そして、関連度算出部104は、基準ユーザxの利用主体識別子と、関連アイテム集合
Ω[x]の各アイテム識別子と、その関連度とを対応させて、関連集合格納部105の関
連度テーブル105Aに記録する。具体的には、基準ユーザxの利用主体識別子を
図8に
示した関連度テーブル105Aの利用主体識別子に対応させ、関連アイテム集合Ω[x]
の各アイテム識別子を関連度テーブル105Aの関連アイテム識別子に対応させて記録す
る。
【0146】
ステップS560において、関連度算出部104は、基準ユーザxに関する関連カテゴ
リ集合Φ[x]を作成し、関連集合格納部105に格納させる。関連カテゴリ集合Φ[x
]は、関連識別子がすべてカテゴリ識別子であるような関連集合である。
【0147】
関連度算出部104は、
図4(a)に示したアイテム情報テーブル101Aを参照しな
がら、ステップS550で作成された関連アイテム集合Ω[x]を用いて、関連カテゴリ
集合Φ[x]を作成する。
【0148】
関連カテゴリ集合Φ[x]作成の第1の方法では、関連アイテム集合Ω[x]の各要素
に対応するカテゴリ識別子を特定し、特定されたカテゴリ識別子ごとの要素数をカウント
し、この要素数をユーザxとカテゴリとの関連度とする。そして、この要素数が所定数以
上のカテゴリ識別子を関連カテゴリ集合Φ[x]に入れる。なお、この所定数を「1」と
して、特定されたカテゴリ識別子をすべて関連カテゴリ集合Φ[x]に入れてもよい。
【0149】
関連カテゴリ集合Φ[x]作成の第2の方法では、関連アイテム集合Ω[x]の各要素
に対応するカテゴリ識別子を特定し、特定されたカテゴリ識別子ごとに、関連アイテム集
合Ω[x]の各要素に対応する関連度の合計値を算出し、この合計値を関連度とする。そ
して、この合計値が所定値以上のカテゴリ識別子を選出して、関連カテゴリ集合Φ[x]
に入れる。例えば、関連アイテム集合に、A、B、Cの3つの要素(関連アイテム)が存
在し、各々の関連度が「1.0」、「0.8」、「0.4」であり、要素Aはカテゴリ1
に対応し、要素Bがカテゴリ2に対応し、要素Cもカテゴリ2に対応する場合、基準ユー
ザとカテゴリ1との関連度を「1.0」、基準ユーザとカテゴリ2との関連度を「0.8
+0.4=1.2」とすればよい。
【0150】
ある要素に対応するカテゴリ識別子が複数存在する場合は、各要素に対応する関連度を
そのまま用いて合計値を算出してもよいし、各要素に対応する関連度をカテゴリ識別子の
数で割った値を用いて合計値を算出してもよい。例えば、基準ユーザと要素A(関連アイ
テムA)との関連度が「1.0」であり、要素Aに、カテゴリ1とカテゴリ3の2つのカ
テゴリが対応する場合、基準ユーザとカテゴリ1との関連度の要素Aに係る部分を「1.
0」としてもよいし、「1.0÷2=0.5」としてもよい。
【0151】
なお、この所定値を十分小さな値にして、特定されたカテゴリ識別子をすべて関連カテ
ゴリ集合Φ[x]に入れてもよい。また、合計値の大きい順に所定数を越えない数のカテ
ゴリ識別子を選出し、関連カテゴリ集合Φ[x]に入れてもよい。
【0152】
そして、関連度算出部104は、基準ユーザxのアイテム識別子と、関連カテゴリ集合
Φ[x]の各カテゴリ識別子と、その関連度とを対応させて、関連集合格納部105の関
連度テーブル105Bに記録する。具体的には、基準ユーザxの利用主体識別子を
図8に
示した関連度テーブル105Bの利用主体識別子に対応させ、関連カテゴリ集合Φ[x]
の各カテゴリ識別子を関連度テーブル105Bの関連カテゴリ識別子に対応させて記録す
る。
【0153】
なお、上述したユーザとアイテムとの関連度、およびユーザとカテゴリとの関連度、そ
れぞれの算出工程において、関連度の最大値や合計値が所定値(例えば「1」)になるよ
うに、正規化処理を行なってもよい。
【0154】
ステップS570において、関連度算出部104は、他の基準ユーザを選択可能か判定
する。ステップS510で作成された推薦基準集合K1の中で、まだ処理を行なっていな
いユーザが存在する場合に「Yes」と判定し、未処理のユーザが存在しない場合は、「
No」と判定する。「Yes」と判定した場合は、ステップS520に戻って処理を繰り
返し、「No」と判定した場合は、関連度算出処理を終了する。
【0155】
この結果、関連集合格納部105の関連度テーブル105A、Bには、ステップS51
0で作成された推薦基準集合K1の利用主体識別子それぞれに対応し、「アイテム推薦形
式」および「カテゴリ推薦形式」に対応する関連集合が格納される。
【0156】
なお、利用履歴格納部102に、
図5(d)に示すようなカテゴリ利用履歴テーブル1
02Bが格納されている場合には、上述のステップS500〜ステップS550の処理に
おけるアイテム識別子をカテゴリ識別子に置き換えて同様の処理を行なうことにより、「
カテゴリ推薦形式」に対応する関連集合を作成することができる。この方法では、ステッ
プS550に相当する処理により関連カテゴリ集合が作成されるため、ステップS560
を実行する必要がない。このため、「アイテム推薦形式」を実施せず、「カテゴリ推薦形
式」のみ実施する場合には、効率的に処理を行なうことができる。
<情報選択処理>
【0157】
ステップS410における情報選択処理を
図16のフローチャートを参照して詳細に説
明する。情報選択処理において、制御部110の指示を受けた情報選択部107は、ステ
ップS400により関連集合格納部105に格納された関連度テーブル105A、105
Bの利用主体識別子および関連集合(関連識別子)を読み出し、価格情報格納部103の
価格情報テーブル103A、103Bを参照しながら、利用主体識別子ごとに関連識別子
を選択する。
【0158】
具体的には、まずステップS900において、情報選択部107は、ステップS510
で作成された推薦基準集合K1の中から未処理の利用主体識別子を選択する。以下ではこ
れを利用主体識別子iとし、これに対応する関連集合をZ[i]とする。また、関連集合
Z[i]の要素である関連識別子jの関連度をW[i][j]、価格情報をX[j]とす
る。
【0159】
情報選択部107は、ステップS910において、利用主体識別子iに関する処理の繰
り返し数を管理するループ変数m(選択集合の順番を示す変数)に初期値「1」をセット
し、ステップS920において、変数Nzに初期値として所定値Q1をセットして初期化
する。変数Nzは、推薦情報の個数(件数)をカウントするための変数であり、推薦結果
として必要なアイテム(カテゴリ)の個数を所定値Q1に設定しておく。例えば、初期値
を「20」とすれば、20個を超えないアイテム(カテゴリ)が推薦結果に入るようにな
る。
【0160】
ステップS930において、情報選択部107は、関連しきい値θ[m]の初期値であ
る関連しきい値θ[1]の値を設定する。関連しきい値θ[m]は、判定対象の関連識別
子をm番目の選択集合Y[i][m]に入れる条件として用いるしきい値であり、関連集
合格納部105に格納された関連度テーブル105A、105Bの関連度に関するしきい
値である。関連しきい値θ[m]の初期値である関連しきい値θ[1]には比較的大きな
値を用いるのがよい。
【0161】
ステップS940において、情報選択部107は、価格しきい値η[m]の初期値であ
る価格しきい値η[1]の値を設定する。価格しきい値η[m]は、判定対象の関連識別
子をm番目の選択集合Y[i][m]に入れる条件として用いるしきい値であり、価格情
報格納部103に格納された価格情報テーブル103A、Bの価格情報に関するしきい値
である。価格しきい値η[m]の初期値である価格しきい値η[1]には比較的大きな値
を用いるのがよい。
【0162】
ステップS950において、情報選択部107は、関連度に関する関連度条件と、価格
情報に関する価格情報条件とを満たす関連識別子を抽出し、利用主体識別子iおよび変数
mに対応する選択集合Y[i][m]を作成する。具体的にはまず、関連集合Z[i]の
要素であり、かつ利用主体識別子iに関するいずれの選択集合にも入っていない関連識別
子を対象にして、「関連度W[i][j]が関連しきい値θ[m]以上」である関連度条
件を満たし、かつ「価格情報が価格しきい値η[m]以上」である価格情報条件を満たす
関連識別子をm番目の選択集合に入れる候補として抽出する。すなわち、「W[i][j
]≧θ[m] ∩ X[j]≧η[m]」である関連識別子を抽出する。ここで、「∩」
はAND条件を示す。m=1の場合は、まだ選択集合が存在しないので、関連集合Z[i
]のすべての要素が対象になるが、例えば、m=3の場合には、それ以前に作成された選
択集合であるY[i][1]および選択集合Y[i][2]の要素である関連識別子を除
外して抽出する。
【0163】
そして、選択集合の候補として抽出された関連識別子の中から、変数Nzを超えない数
の関連識別子を選択し、m番目の選択集合Y[i][m]に入れる。例えば、条件を満た
す関連識別子がNzに満たない場合は、特定した関連識別子をすべて選択集合Y[i][
m]に入れ、条件を満たす関連識別子がNz以上である場合は、関連度が大きい順、また
は価格情報が大きい順の上位Nz件を選択集合Y[i][m]に入れるとよい。あるいは
、関連度と価格情報とを用いて指標を作成し、その指標の大きい順に上位Nz件を選択し
てもよい。例えば、関連度と価格情報との乗算値または重み付き加算値を用いて、そのよ
うな指標を算出してもよい。
【0164】
なお、利用履歴格納部102の利用履歴テーブル102A、102Bを参照しながら、
利用主体識別子iが既に利用したアイテムおよびカテゴリを特定し、それらを除外して(
利用済み除外処理を行なって)選択集合を作成してもよい。ユーザが1回しか同じアイテ
ム(カテゴリ)を購入しない性質を持つようなアイテム提供サービスでは、このステップ
S950において利用済みのものを選択集合から除外しておくと、推薦情報格納部108
の記憶容量を節約できる。
【0165】
ステップS950において利用済み除外処理を行なう場合、ステップS170での利用
済み除外処理を省略してもよいし、再度行なってもよい。ステップS950を実行した後
、ステップS170を実行するまでの間に、新たな利用履歴が格納される可能性がある場
合は、両方のステップで利用済み除外処理を行なう方が、推薦精度の向上の面では確実で
ある。
【0166】
ステップS960において、情報選択部107は、変数Nzの値から選択集合Y[i]
[m]の要素数を減算し、変数Nzの新たな値とする。例えば、変数Nzの値が「20」
で、選択集合Y[i][1]の要素数が「8」である場合は、この差の「20−8=12
」を変数Nzの新たな値とする。
【0167】
ステップS970において、情報選択部107は、変数Nzの値が0より大きいか否か
を判定する。変数Nzの値が0より大きい場合(Yes)は、ステップS980に進み、
そうでない場合(No)は、ステップS1010に進む。
【0168】
ステップS980において、情報選択部107は、選択集合の順番を示すループ変数m
の値をインクリメント(値を「1」大きく)して更新する。
【0169】
ステップS990において、情報選択部107は、変数mに対応する関連しきい値θ[
m]を設定する。ここで、θ[m−1]>θ[m]となるように関連しきい値θ[m]を
設定する。例えば、m=2の場合、θ[1]>θ[2]として、2番目の関連しきい値θ
[2]が、1番目の関連しきい値θ[1]よりも小さくなるようにする。
【0170】
なお、1つ前の関連しきい値との差分Dθ[m](Dθ[m]=θ[m−1]−θ[m
])をmによらずに一定値にしてもよいし、mによって変化させてもよい。また、今後新
たに選択集合に追加が必要な個数である変数Nzの値に応じて、差分Dθ[m]を決定し
、それに従って関連しきい値θ[m]を設定してもよい。例えば、変数Nzの値が大きい
場合には差分Dθ[m]を大きくし、変数Nzの値が小さい場合には差分Dθ[m]を小
さくすることができる。
【0171】
ステップS1000において、情報選択部107は、変数mに対応する価格しきい値η
[m]を設定する。ここで、η[m−1]>η[m]となるように設定する。例えば、m
=2の場合、η[1]>η[2]として、2番目の価格しきい値η[2]が、1番目の価
格しきい値η[1]よりも小さくなるようにする。
【0172】
なお、1つ前の価格しきい値との差分Dη[m](Dη[m]=η[m−1]−η[m
])をmによらずに一定値にしてもよいし、mによって変化させてもよい。また、今後新
たに選択集合に追加が必要な個数である変数Nzの値に応じて、差分Dη[m]を決定し
、それに従って価格しきい値η[m]を設定してもよい。例えば、変数Nzの値が大きい
場合には差分Dη[m]を大きくし、変数Nzの値が小さい場合には差分Dη[m]を小
さくすることができる。そして、ステップS950に戻り、以降の処理を繰り返す。
【0173】
ステップS1010において、情報選択部107は、利用主体識別子iに対応するすべ
ての選択集合であるY[i][n](n=1〜Na[i])に含まれるすべての要素(関
連識別子)に対して、推薦順位を付与する。ここで、Na[i]は、利用主体識別子iに
対応する選択集合の数であり、ループ処理を終了した後のステップ1010における変数
mの値である。以下では、選択集合Y[i][n]の要素数をNv[i][n]とし、利
用主体識別子iに対応する選択集合に含まれるすべての関連識別子の数をNb[i]とす
る。推薦順位の付与は、例えば、以下のような方法を用いることができる。
【0174】
推薦順位付与の第1の方法は、Nb[i]個の関連識別子を関連度の大きい順、または
価格情報が大きい順にソートし、関連度または価格情報が大きいほど、高い推薦順位を付
与する方法である。あるいは、関連度と価格情報とを用いて指標を作成し、その指標が大
きいほど、高い推薦順位を付与してもよい。例えば、関連度と価格情報との乗算値または
重み付き加算値を用いて、そのような指標を算出してもよい。第1の方法は、関連識別子
が何番目の選択集合に属しているかは考慮しない。
【0175】
推薦順位付与の第2の方法は、順番の早い選択集合(Y[i][n]のnが小さい選択
集合)ほど推薦順位を高くする方法である。例えば、1番目の選択集合Y[i][1]の
要素数をNv[i][1]とすると、選択集合Y[i][1]に属する関連識別子には、
1〜Nv[i][1]の推薦順位を付与する。Nv[i][1]個の関連識別子を関連度
の大きい順、または価格情報が大きい順にソートし、関連度または価格情報が大きいほど
、高い推薦順位を付与すればよい。あるいは、関連度と価格情報とを用いて指標を作成し
、その指標が大きいほど、高い推薦順位を付与してもよい。そして、2番目の選択集合に
は、1番目の選択集合に付与した最大の番号より大きな番号を付与すればよい。すなわち
、(Nv[i][1]+1)〜(Nv[i][1]+Nv[i][2])の番号を付与す
ればよい。2番目の選択集合の中での推薦順位は、上述した1番目の選択集合の中での推
薦順位付与と同様な方法で決めればよい。3番目以降の選択集合についても同様な処理を
行なう。この方法によれば、関連度が大きく、かつ価格情報が大きいアイテム(カテゴリ
)をより上位の推薦順位とすることができる。
【0176】
なお、上述した第1および第2の方法では、関連度または価格情報を用いてソート処理
を行なっているが、これ以外のデータを用いてソートしてもよい。例えば、第1の方法に
おいて、アイテム属性格納部101のアイテム情報テーブル101Aに格納されているア
イテム時期情報を用い、アイテム時期情報が新しいほど推薦順位を高く(番号を小さく)
してもよい。第2の方法において、選択集合ごとにソートする場合も同様である。また、
関連度と価格情報とアイテム時期情報とを用いて総合的な指標を算出し、それを用いてソ
ート処理を行なってもよい。例えば、関連度が大きく、かつ価格情報が大きく、かつアイ
テム時期情報が新しいほど大きな値となる傾向の指標を算出し、それを用いてもよい。
【0177】
ステップS1020において、利用主体識別子iと、選択集合Y[i][n](n=1
〜Na[i])に属する関連識別子と、ステップS1010で作成された推薦順位とを対
応させて、
図7(a)〜(d)に示す形式で、推薦情報格納部108に格納させる。
【0178】
ステップS1030において、情報選択部107は、未処理の別の利用主体識別子が選
択可能か判定する。ステップS510で作成された推薦基準集合K1の中に、未処理の別
の利用主体識別子が存在し選択可能である場合(Yes)は、ステップS900に戻って
、未処理の利用主体識別子のいずれかを選択して新たな利用主体識別子iとし、以降の処
理を繰り返す。未処理の別の利用主体識別子が存在しない場合(No)は、情報選択処理
を終了する。
【0179】
図17(a)は、m=1からm=3で抽出される関連識別子の範囲を模式的に示してい
る。すなわち、図中で第1選択集合と示された領域は、m=1で抽出される選択集合Y[
i][1]を示しており、価格情報が価格しきい値η[1](第1価格しきい値)以上で
あり、かつ、関連度が関連しきい値θ[1](第1関連しきい値)以上である関連識別子
が抽出される。また、図中で第2選択集合と示された領域は、m=2で抽出される選択集
合Y[i][2]を示しており、第1選択集合に含まれない関連識別子を対象に、価格情
報が価格しきい値η[2](第2価格しきい値)以上であり、かつ、関連度が関連しきい
値θ[2](第2関連しきい値)以上である関連識別子が抽出される。このため、図中の
第1選択集合と示された領域と第2選択集合と示された領域とは重複しない。
【0180】
さらに、図中で第3選択集合と示された領域は、m=3で抽出される選択集合Y[i]
[3]を示しており、第1選択集合および第2選択集合に含まれない関連識別子を対象に
、価格情報が価格しきい値η[3](第3価格しきい値)以上であり、かつ、関連度が関
連しきい値θ[3](第3関連しきい値)以上である関連識別子が抽出される。
【0181】
なお、ステップS990およびS1000のうちのいずれか一方を省略して、関連しき
い値θ[m]および価格しきい値η[m]のうちいずれか一方のみを更新するようにして
もよい。また、ループ変数mの値に応じて、関連しきい値θ[m]と価格しきい値η[m
]とを両方更新するか、いずれか一方のみを変更するかを決めるようにしてもよい。例え
ば、m=2の場合には、関連しきい値θ[2]と価格しきい値η[2]とを両方更新し、
m=3の場合には、関連しきい値θ[3]のみ更新し、価格しきい値η[3]は更新せず
(η[3]=η[2])、m=4の場合には、価格しきい値η[4]のみ更新し、関連し
きい値θ[4]は更新しないようにしてもよい。
【0182】
図17(b)は、関連しきい値θ[m]のみを更新する場合に、m=1からm=3で抽
出される関連識別子の範囲を模式的に示している。すなわち、図中で第1選択集合と示さ
れた領域は、m=1で抽出される選択集合Y[i][1]を示しており、価格情報が価格
しきい値η[1](第1価格しきい値)以上であり、かつ、関連度が関連しきい値θ[1
](第1関連しきい値)以上である関連識別子が抽出される。また、図中で第2選択集合
と示された領域は、m=2で抽出される選択集合Y[i][2]を示しており、第1選択
集合に含まれない関連識別子を対象に、価格情報が価格しきい値η[1](第1価格しき
い値)以上であり、かつ、関連度が関連しきい値θ[2](第2関連しきい値)以上であ
る関連識別子が抽出される。さらに、図中で第3選択集合と示された領域は、m=3で抽
出される選択集合Y[i][3]を示しており、第1選択集合および第2選択集合に含ま
れない関連識別子を対象に、価格情報が価格しきい値η[1](第1価格しきい値)以上
であり、かつ、関連度が関連しきい値θ[3](第3関連しきい値)以上である関連識別
子が抽出される。
【0183】
以上、詳細に説明した方法により、関連度が大きく、かつ価格情報が大きいアイテム(
カテゴリ)、すなわちアイテム提供サービスの売上増大を図る上で最も効果的なアイテム
(カテゴリ)を優先的に推薦情報に入れることができる。また、所定値Q1を超えない数
のアイテム(カテゴリ)を精度よく絞り込んで推薦情報に入れることができるので、端末
装置30の表示装置320に表示できる推薦情報の数が少ない場合でも、精度よい推薦が
できる。
【0184】
なお、上述した情報選択処理では、関連度を用いたが、関連度に代えて関連度に応じた
順位(関連順位)を用いるようにしてもよい。例えば、関連集合格納部105の関連度テ
ーブル105A、105Bに、関連度が大きいほど順位が高くなる(値が小さくなる)関
連順位を格納しておく。そしてステップS930において、関連順位に関するしきい値を
セットし、ステップS950において、関連順位が関連順位に関するしきい値以下であり
、かつ価格情報が価格しきい値以上である関連識別子を特定してもよい。
【0185】
また、上述した情報選択処理では、選択集合の順番(ループ変数m)に応じて、関連し
きい値θ[m]を変えているが、他の方法を用いてもよい。例えば、関連しきい値を一定
にしておき、ループ変数mが大きくなるに従って小さくなる値を、関連度を用いて算出し
、この値と関連しきい値の大小関係を判定して、選択集合を作成してもよい。具体的には
、関連度をループ変数mで割った値、関連度をループ変数mを用いた対数値や累乗値で割
った値、などを用いればよい。また、価格情報条件についても同様に、価格しきい値を一
定にしておき、価格情報から選択集合の順番に応じて異なる値を算出し、その値と価格し
きい値との大小関係を判定してもよい。
【0186】
また、上述した情報選択処理では、1回のループ処理において、1つの関連しきい値θ
[m]と、1つの価格しきい値η[m]とを用いて処理を行なっているが、複数の関連し
きい値または/および複数の価格しきい値を用いて処理を行なってもよい。例えば、m=
2のループ処理において、「(W[i][j]≧θ[2] ∩ X[j]≧η[1])∪
(W[i][j]≧θ[1] ∩ X[j]≧η[2])」という条件を満たす関連識別
子を選択集合に入れてもよい。ここで、「∪」はOR条件であり、θ[1]はm=1のル
ープ処理で用いた第1関連しきい値、η[1]はm=1のループ処理で用いた第1価格し
きい値である。また、θ[1]>θ[2]、η[2]>η[1]である。すなわち、m=
1で作成された選択集合に含まれない関連識別子を対象にして、関連度が第1関連しきい
値よりも小さな第2関連しきい値以上でありかつ価格情報が第1価格しきい値以上である
関連識別子の集合と、関連度が第1関連しきい値以上でありかつ価格情報が第1価格しき
い値よりも小さな第2価格しきい値以上である関連識別子の集合とを求め、その2つの集
合の和集合をm=2に対応する選択集合としてもよい。以上、情報選択処理について説明
した。
【0187】
次に、
図18を参照して、推薦情報の具体例を説明する。関連集合格納部105の関連
度テーブル105Aには
図18(a)に示すような「アイテム推薦形式」のデータが格納
されているものとする。本図に示すように、「UserID−1」の関連集合は、「It
emID−3」〜「ItemID−7」の5つのアイテムである。また「UserID−
2」の関連集合もまったく同じ5つのアイテムであるが、各々の関連度は異なっている。
【0188】
価格情報格納部103のアイテム価格情報テーブル103Aには、
図18(b)に示す
「ItemID−1」〜「ItemID−7」の7つのアイテムの価格情報が格納されて
いるものとし、情報選択部107は、ユーザごとに3つのアイテムを選択して推薦情報を
作成するものとする。また、関連しきい値θ[m]を各々、θ[1]=0.60、θ[2
]=0.50、θ[3]=0.40とし、価格しきい値η[m]を各々、η[1]=12
00円、η[2]=500円、η[3]=100円とする。また、推薦順位付与の第2の
方法を用い、同じ選択集合の中では、価格情報に従って推薦順位を付与するものとする。
【0189】
仮に、価格情報を使わずに関連度だけでアイテムを選択したとすると、
図18(a)か
ら明らかなように、「UserID−1」に対応する推薦アイテムは、1位が「Item
ID−3」、2位が「ItemID−4」、3位が「ItemID−5」になる。これら
の価格は各々「1000円」、「200円」、「400円」である。
【0190】
一方、上述した方法で利用主体識別子「UserID−1」に対応する推薦情報を作成
する場合、まず、関連しきい値θ[1]および価格しきい値η[1]の条件に合致する「
ItemID−6」が1番目の選択集合に入る。次に、関連しきい値θ[2]および価格
しきい値η[2]の条件に合致する「ItemID−3」が2番目の選択集合に入る。最
後に、関連しきい値θ[3]および価格しきい値η[3]の条件に合致する「ItemI
D−5」が3番目の選択集合に入る。
【0191】
この結果、
図18(c)に示すように、推薦順位の1位が「ItemID−6」、2位
が「ItemID−3」、3位が「ItemID−5」となる。各々の価格は「1500
円」、「1000円」、「400円」である。このように、本実施例の方法によれば、関
連度だけでアイテムを選択する場合に比べて、価格の高いアイテムを推薦結果に入れるこ
とができる。
【0192】
また、価格情報を使わずに関連度だけでアイテムを選択したとすると、「UserID
−2」に対応する推薦アイテムは、1位が「ItemID−4」、2位が「ItemID
−5」、3位が「ItemID−7」になる。これらの価格は各々「200円」、「40
0円」、「800円」である。
【0193】
一方、上述した方法で利用主体識別子「UserID−2」に対応する推薦情報を作成
する場合、まず関連しきい値θ[1]および価格しきい値η[1]の条件に合致するアイ
テムは存在しないので、1番目の選択集合は空集合になる。次に関連しきい値θ[2]お
よび価格しきい値η[2]の条件に合致する「ItemID−7」が2番目の選択集合に
入る。最後に関連しきい値θ[3]および価格しきい値η[3]の条件に合致する「It
emID−5」および「ItemID−4」が3番目の選択集合に入る。3番目の選択集
合では、価格情報の大きい「ItemID−5」の方が、推薦順位が高くなる。
【0194】
この結果、
図18(c)に示すように、推薦順位の1位が「ItemID−7」、2位
が「ItemID−5」、3位が「ItemID−4」となる。各々の価格は「800円
」、「400円」、「200円」である。この場合は3つのアイテムの価格の合計は、関
連度のみを用いた場合と同じになるが、価格の高いアイテムが上位の推薦順位となり、ユ
ーザの目に留まりやすくなる。
【0195】
また、「UserID−1」に対する推薦結果には、価格の高い「ItemID−6」
と「ItemID−3」が入るが、「UserID−2」に対する推薦結果には、これら
が入らない。このことからも分かるように、本実施例では、ユーザと推薦アイテム/カテ
ゴリとの関連度が高い場合、すなわちそのユーザが推薦アイテム/カテゴリを気に入る可
能性が高い場合にのみ価格の高いアイテムが推薦されるので、ユーザに不自然な印象を与
えることが少なく、価格の高いアイテムの推薦によって、ユーザの購入意欲が低下してし
まうリスクを従来技術よりも減らすことができる。このため、アイテム提供サービスの売
上を増大させることが期待できる。
【0196】
従来技術では、推薦アイテムの価格が所定の範囲(所定の価格帯)に制限されてしまう
ため、推薦結果のバリエーション(多様性)が少なかったり、推薦アイテム数が少ない場
合があった。しかしながら、上記の例で、「ItemID−1」の推薦アイテムの価格が
、「1500円」、「1000円」、「400円」となり、これらの間の「800円」が
抜けていることからも分かるように、本実施例の方法では、推薦アイテム/カテゴリの価
格が所定の範囲に制限されていないため、従来よりも推薦結果のバリエーションが多くな
り(多様性があり)、長期間にわたり同じユーザに推薦情報を提供する場合であっても、
ユーザが推薦情報に飽きてしまうことが少なく、継続的に推薦情報を利用してもらうこと
ができる。
【0197】
また従来技術では、所定の価格帯のアイテムが無い場合や、少ししか存在していない場
合には、十分な数の推薦情報を提供することができなかった。一方、第1実施例の方法に
よれば、所定の価格帯のアイテムが無い場合や、少ししか存在していない場合であっても
、十分な数の推薦情報を精度良く選択して提供することができる。
【0198】
また、従来技術では、価格が所定の範囲にある推薦アイテムが多数存在する場合、それ
らを精度良く絞り込むことができず、推薦情報が多くなり過ぎる場合があった。推薦情報
は本来、多くの情報の中からユーザに有用な情報を絞り込んで提供するものであり、端末
装置30の表示装置320において、推薦情報が表示できる領域にも限りがあることから
、推薦情報を必要十分な数にすることは非常に重要である。本実施例の方法によれば、必
要十分な数のアイテムを精度良く絞り込んで、適切な数(量)の推薦情報をユーザに提供
できるため、推薦システムに対するユーザの満足度や信頼感を高めることができる。
【0199】
アイテム提供サービスを行なう事業者にとって、推薦情報を提供する目的は、推薦情報
によってアイテム利用が促進され、アイテム提供サービスの売上を増大させることである
。すなわち、売上増大につながる実効性のある推薦情報が要求される。この目的を達成す
るためには、ある程度の数の推薦情報が必要であり、多過ぎず、少な過ぎでもない適切な
数(量)の推薦情報をユーザに提供する必要がある。第1実施例の方法によれば、適切な
数(量)の推薦情報を精度良く選択してユーザに提供できるので、アイテム提供サービス
の売上を増大させる実効性が期待できる。
【0200】
なお、第1実施例では、情報選択装置10が、情報選択処理を行なって推薦情報を作成
するようにしていたが、情報選択処理を端末装置30側で行なうようにしてもよい。
【0201】
この場合、端末装置30のアプリケーション部304に、情報選択部107に相当する
動作を行なわせるようにする。例えば、ステップS160に先立つ適当なタイミングで、
アプリケーション部304が、アイテム提供サーバ20を経由して、あるいは直接情報選
択装置10から、アイテム情報テーブル101A、カテゴリ情報テーブル101B、関連
度テーブル105A、105B、およびアイテム価格情報テーブル103A、カテゴリ価
格情報テーブル103Bのデータを取得する。このとき、各々のテーブルの全部のデータ
を取得してもよいし、リクエスト利用主体識別子に関係するデータ等の必要なデータのみ
を取得するようにしてもよい。
【0202】
そして、ステップS160において、推薦リクエストを送信する代わりに、上述の手順
に従って推薦情報を作成する。具体的には、ステップS410、S170に相当する処理
をアプリケーション部304が実行すればよい。この場合、アプリケーション部304に
、データ取得部、情報選択部が形成されることになる。以下の実施例においても同様に、
情報選択装置10の一部の動作を端末装置30で行なうようにしてもよい。
【実施例3】
【0237】
本実施形態に係るネットワークシステムの第3実施例について説明する。第3実施例で
は、端末装置30を利用するユーザが過去に利用したアイテムの価格に基づいて、価格情
報が推薦結果に及ぼす影響をユーザごとに変えることができるようになっている。第3実
施例において、アイテム提供サーバ20および端末装置30は、第1実施例と同様とする
ことができる。
【0238】
図23は、第3実施例における情報選択装置10cの構成を示すブロック図である。本
図に示すように、情報選択装置10cは、アイテム属性格納部101と、利用履歴格納部
102と、価格情報格納部103と、関連度算出部104と、関連集合格納部105と、
情報選択部107cと、推薦情報格納部108と、送受信部109と、制御部110cと
、利用価格情報算出部111と、利用価格情報格納部112とを備えて構成されている。
また、情報選択装置10には、情報選択装置10の管理者向けに必要な情報を表示するた
めの表示装置120と、管理者が操作を行なうためのキーボード、マウス等の入力装置1
30とが接続されている。
【0239】
すなわち、第3実施例の情報選択装置10cは、第1実施例の情報選択装置10に利用
価格情報算出部111および利用価格情報格納部112を追加し、情報選択部107、制
御部110の動作が一部異なる構成となっている。
【0240】
制御部110cは、第1実施例と同様に、所定のタイミングで推薦情報作成動作を開始
する。ただし本実施形態では、
図14のフローチャートにおいてステップS400の後に
、図示しないステップS415を実行し、ステップS415が終了した段階で推薦情報作
成動作を終了する。情報選択処理を行なうステップS410に相当する処理は、後述する
ステップS170cにおいて、表示用推薦データを作成する際に行なう。
【0241】
ステップS415において、制御部110cの指示を受けた利用価格情報算出部111
は、利用履歴格納部102を参照しながら、ユーザが利用したアイテムの価格に関する情
報である利用価格情報をユーザごとに算出する。なお、利用価格情報における利用は、情
報閲覧、視聴等を含めずに、実際に購入した場合とすることが望ましい。
【0242】
利用価格情報算出部111は、利用履歴格納部102に格納されたすべての利用履歴を
読み出してもよいし、
図15のステップS500で説明した利用履歴読出処理と同様な方
法で、所定の条件を満たす利用履歴を読み出してもよい。
【0243】
そして、読み出した利用履歴に対応するユーザを対象にして、それぞれのユーザの利用
価格情報を算出する。利用価格情報として、例えば、ユーザが過去に利用したアイテムの
価格の高さを指標化した価格水準値と、ユーザの利用したアイテムの価格のばらつき度合
いを指標化した価格分散値とを用いることができる。ここでは、利用価格情報算出部11
1は、以下に示す第1〜第6の利用価格情報のうち、1つ以上の値を算出するものとする
。
【0244】
第1の利用価格情報である第1の価格水準値は、ユーザの利用したアイテムの価格の合
計値(合計額)を価格水準値とするものである。第1の価格水準値を算出する場合、利用
価格情報算出部111は、読み出した利用履歴を参照しながら、ある利用主体識別子(あ
るユーザ)が利用したアイテムを特定する。そして、価格情報格納部103を参照しなが
ら、特定したアイテムの価格の合計値を算出し、その利用主体識別子に対応する第1の価
格水準値とする。第1の価格水準値が大きいユーザは、購買能力の高いユーザと推測でき
る。なお、合計値そのものではなく、合計値に所定の値を乗じた値や、合計値を所定の値
で割った値を第1の価格水準値としてもよい。例えば、合計値の桁数が大きくなるような
場合に、所定の値で割って扱いやすい桁数の値にしたり、この第1の価格水準値を含めて
、以下で説明する各々の利用価格情報の最大値が「1」になるような正規化を行なっても
よい。
【0245】
第2の利用価格情報である第2の価格水準値は、ユーザの利用したアイテム1つあたり
の価格の高さを示す値(代表値)を価格水準値とするものである。第2の価格水準値を算
出する場合、利用価格情報算出部111は、読み出した利用履歴を参照しながら、ある利
用主体識別子(あるユーザ)が利用したアイテムを特定する。そして、価格情報格納部1
03を参照しながら、特定したアイテムの価格の分布を求め、その代表値を算出し、その
利用主体識別子に対応する第2の価格水準値とする。代表値としては、平均値、中央値、
最頻度、四分位値、最大値、最小値などを用いることができる。また、利用回数の多いア
イテムに大きな重みを付ける等、利用回数に応じた重みづけ行なって代表値を算出しても
よい。
【0246】
第2の価格水準値が大きいユーザは、高額アイテムや高級アイテムを好むユーザと推測
できる。また、第2の価格水準値は、アイテムの価格が広い範囲に分布している場合に適
している。
【0247】
第3の利用価格情報である第3の価格水準値は、ユーザの利用したアイテムの価格の所
定期間ごとの合計額に関する代表値を価格水準値とするものである。この第3の価格水準
値は、ユーザの利用したアイテムの価格の合計額を用いた値であり、所定期間としては、
1日間、1週間、1ヶ月間などを用いればよい。また、1回の購入において、複数のアイ
テムをまとめて利用(購入)できるようなアイテム提供サービスでは、所定期間の合計額
の代わりに、1回の利用の合計額に関する代表値を用いてもよい。
【0248】
第3の価格水準値を算出する場合、利用価格情報算出部111は、読み出した利用履歴
を参照しながら、ある利用主体識別子(あるユーザ)が利用したアイテムを所定期間ごと
に特定する。そして、価格情報格納部103を参照しながら、特定したアイテムの価格の
合計額を所定期間ごとに算出し、その代表値を算出して、その利用主体識別子に対応する
第3の価格水準値とする。代表値としては、第2の価格水準値と同様なものを用いること
ができる。
【0249】
第3の価格水準値は、ユーザがアイテム提供サービスを利用している期間の長さの影響
を受けずに、ユーザの購買能力を判断するのに適している。また第3の価格水準値は、ア
イテムの価格が狭い範囲に分布していたり、価格の範囲は広くても多くのアイテムの価格
がほぼ同じような場合に適している。
【0250】
第4の利用価格情報である第1の価格分散値は、ユーザの利用したアイテム1つあたり
の価格のばらつきの大きさ(ばらつき度)を示す値を価格分散値とするものである。第1
の価格分散値を算出する場合、利用価格情報算出部111は、読み出した利用履歴を参照
しながら、ある利用主体識別子(あるユーザ)が利用したアイテムを特定する。そして、
価格情報格納部103を参照しながら、特定したアイテムの価格の分布を求め、そのばら
つき度を示す値を算出し、その利用主体識別子に対応する第1の価格分散値とする。具体
的には、ばらつき度を示す値として、分散、標準偏差、範囲(最大値−最小値)、四分位
範囲(第3四分位値−第1四分位値)などを用いることができる。
【0251】
第1の価格分散値が大きいユーザは、様々な価格のアイテムを利用するユーザと推測で
きる。また、第1の価格分散値は、アイテムの価格が広い範囲に分布している場合に適し
ている。
【0252】
第5の利用価格情報である第2の価格分散値は、ユーザの利用したアイテムの価格の合
計額に関するばらつきの大きさ(ばらつき度)を示す値を価格分散値とするものである。
この合計額として、例えば、所定期間ごとの合計額を用いることができる。具体的には、
第2の価格分散値を算出する場合、利用価格情報算出部111は、読み出した利用履歴を
参照しながら、ある利用主体識別子(あるユーザ)が利用したアイテムを所定期間ごとに
特定する。そして、価格情報格納部103を参照しながら、特定したアイテムの価格の合
計額を所定期間ごとに算出し、そのばらつき度を示す値を算出して、その利用主体識別子
に対応する第2の価格分散値とする。ばらつき度を示す値は、第1の価格分散値と同様で
ある。また、1回の利用(購入)あたりの合計額を算出し、そのばらつき度を示す値を算
出して、第2の価格分散値としてもよい。
【0253】
この第2の価格分散値は、アイテムの価格が狭い範囲に分布していたり、価格の範囲は
広くても多くのアイテムの価格がほぼ同じような場合に適している。第2の価格分散値が
小さいユーザは、コンスタントに安定してアイテムを利用するユーザと推測できる。
【0254】
上述した方法では、ある利用主体識別子(あるユーザ)が利用したアイテム(あるユー
ザの利用履歴)のみを用いて、第1〜第5の利用価格情報を算出するが、あるユーザおよ
び他のユーザの利用履歴を用いて算出してもよい。すなわち、あるユーザおよび他のユー
ザが利用したアイテムの価格に基づいて、あるユーザの利用価格情報を算出してもよい。
【0255】
例えば、利用価格情報算出部111が利用履歴格納部102から読み出した利用履歴に
、Nu人の利用主体識別子が含まれているとして、利用主体識別子ごとにアイテム価格の
合計値Ps[u](u=1〜Nu)を算出し、Ps[u]の平均値Paと標準偏差Pbと
を算出する。そして[数5]に従ってユーザuの標準得点S[u]、または偏差値等を算
出し、第1の利用価格情報に相当する情報である第6の利用価格情報として用いることが
できる。
【数5】
【0256】
この第6の利用価格情報は、あるユーザ(ユーザu)が利用したアイテム価格の合計値
が、ユーザ集団の中でどの位置にあるかを相対的に示す情報である。第2〜第5の利用価
格情報についても、同様にユーザ集団の中での相対値を算出することができる。
【0257】
また利用価格情報算出部111は、ある利用主体識別子に対して、アイテム区分ごとに
利用価格情報を算出してもよい。ここで、アイテム区分とは、アイテムを所定の基準で分
類した情報であり、通常はカテゴリよりも上位の概念の分類である。例えば、アイテム提
供サービスにおいて、種々のコンテンツを提供する場合、「音楽」「映画」「書籍」とい
った上位の階層の分類をアイテム区分とし、アイテム区分が「音楽」のアイテムに対して
は、「ロック」「ジャズ」「クラシック」「フォーク」等のジャンル情報をカテゴリとす
ることができる。アイテム区分が「映画」のアイテムに対しては、「SF」「アクション
」「コメディ」「アニメ」「サスペンス」等のジャンル情報をカテゴリとすればよい。
【0258】
この場合は、アイテム属性格納部101に、各アイテムまたは各カテゴリと、各アイテ
ム区分とを対応させたアイテム区分情報を格納しておく。そして、利用価格情報算出部1
11はアイテム区分情報を参照しながら、ユーザが利用したアイテムのアイテム区分を特
定し、アイテム区分ごとに利用価格情報を算出する。上記の例では、「音楽」に対応する
利用価格情報と、「映画」に対応する利用価格情報と、「書籍」に対応する利用価格情報
とを算出する。ただし、カテゴリをそのままアイテム区分とするようにしてもよい。
【0259】
利用価格情報算出部111は、算出した利用価格情報を利用価格情報格納部112に格
納させる。利用価格情報格納部112は、
図24に示すような形式で、利用主体識別子と
、利用価格情報とを対応させて格納する。
図24(a)は、アイテム区分を用いない場合
の格納形式である利用価格情報テーブル112Aを示している。複数種類(Np個)の利
用価格情報が格納されているが、1種類の利用価格情報を格納するようにしてもよい。
【0260】
図24(b)は、アイテム区分を用いる場合の格納形式である利用価格情報テーブル1
12Bを示している。アイテム区分1に対応するNp1個の利用価格情報と、アイテム区
分2に対応するNp2個の利用価格情報を格納している。ここで、Np1≠Np2として、
アイテム区分ごとに異なる数の利用価格情報を算出して格納するようにしてもよい。Np
1およびNp2は、1つであっても複数個であってもよい。以上がステップS415の説明
である。
【0261】
第3実施例におけるシステム全体の動作は、処理ステップ間の関係において
図11に示
したフローチャートと同様であり、ステップS160とS170の具体的内容において第
1実施例と一部異なる。第3実施例におけるこれらの処理ステップは、末尾に「c」を付
加して表記する。
【0262】
ステップSl60cにおいて、端末装置30は、関連リンクに対応するURLに推薦リ
クエストを送信する。
【0263】
ステップS170cにおいて、情報選択装置10cの制御部110cは、送受信部10
9を介して、推薦リクエストを受信し、それに含まれるリクエスト利用主体識別子に対応
する表示用推薦データを作成して端末装置30に送信する。
【0264】
このステップS170cの全体の流れは第2実施例のステップS170bと同様であり
、ステップS410cの後に、図示しないステップS430を実行する。また、ステップ
S410cの全体の流れは、第2実施例のステップS410bと同様であり、リクエスト
利用主体識別子の集合である集合Ψを対象にして処理が行われるが、第2実施例と異なる
処理ステップを以下で詳細に説明する。通常は集合Ψの要素数は1つである。
【0265】
第3実施例では、利用価格情報格納部112に格納された利用価格情報を用いて、情報
選択処理を行なう。以下の説明では、利用価格情報格納部112の利用価格情報テーブル
112Aには、
図24(a)に示す形式でユーザuの価格水準値L[u]が1つ、ユーザ
uの価格分散値V[u]が1つ格納されており、これらを読み出して利用することとする
。ただし、価格水準値と価格分散値のどちらか一方を利用してもよいし、3つ以上の利用
価格情報を利用してもよい。
【0266】
ステップS900c〜S920cは、各々ステップS900b〜S920bと同じであ
る。
【0267】
次にステップS930cにおいて、情報選択部107cは、関連しきい値θ[m]の初
期値として関連しきい値θ[1]に値をセットする。第3実施例では、利用価格情報格納
部112を参照しながら、推薦リクエストに含まれる利用主体識別子に対応する利用価格
情報に応じて、この初期値を変更する。
【0268】
関連しきい値θ[m]の初期値設定の第1の方法は、ユーザuの価格水準値L[u]に
応じて、異なる初期値を用いる方法である。例えば、価格水準値L[u]に関するしきい
値δ5とδ6(δ5<δ6)と、初期値θ1〜θ3(θ1>θ2>θ3)を用意しておき、L[u
]<δ5であれば、標準より大きいθ1、δ5≦L[u]<δ6であれば、標準であるθ2、
δ6≦L[u]であれば、標準より小さいθ3を選択して初期値とする。
【0269】
すなわち、価格水準値L[u]が小さいほど、関連しきい値θ[m]が大きくなる規則
を用いて、関連しきい値の初期値を設定する。価格水準値L[u]の小さいユーザは、購
買能力の低いユーザであったり、低額アイテムをよく利用するユーザと想定されるため、
関連度が低く価格の高いアイテム(カテゴリ)の受容可能性が特に小さいと考えられる。
この第1の方法により、このようなユーザの推薦情報には、関連度が低く価格の高いアイ
テム(カテゴリ)が入りにくくなるので、ユーザが推薦情報を受容する可能性を高くする
ことができる。なお、上述した例において、価格水準値が共にδ5未満である2人のユー
ザがいる場合、各々の価格水準値が異なっていても、その2人の関連しきい値の初期値は
共にθ1となる。この例のように、価格水準値の変化に対して段階的(離散的)に関連し
きい値が変化する規則を用いてもよいし、連続的に変化する規則を用いてもよい。
【0270】
関連しきい値θ[m]の初期値設定の第2の方法は、ユーザuの価格分散値V[u]に
応じて、異なる初期値を用いる方法である。例えば、価格分散値V[u]関するしきい値
ε5とε6(ε5<ε6)と、初期値θ1〜θ3(θ1>θ2>θ3)を用意しておき、価格分散
値V[u]<ε5であれば、標準より大きいθ1、ε5≦V[u]<ε6であれば、標準であ
るθ2、ε6≦V[u]であれば、標準より小さいθ3を選択して初期値とする。
【0271】
すなわち、価格分散値V[u]が小さいほど、関連しきい値θ[m]が大きくなる規則
を用いて、関連しきい値の初期値を設定する。価格分散値V[u]が小さなユーザは、限
られた価格帯のアイテムを利用する傾向や、所定期間ごとの利用アイテムの合計額が安定
している傾向があると想定される。すなわち、自分なりの利用パターンが確立しているユ
ーザであるといえる。このようなユーザでは、関連度が低く価格が高いものを推薦した場
合に受容されないリスクが高いため、関連しきい値θ[m]の初期値を大きくして、それ
らが推薦情報に入りにくくする。
【0272】
一方、価格分散値V[u]が大きなユーザは、幅広い価格帯のアイテムを利用する傾向
や、所定期間ごとの利用アイテムの合計額の変化が大きい傾向があると想定される。すな
わち、価格に関して柔軟性があるといえる。このようなユーザでは、関連度が低く価格が
高いものを推薦した場合に受容されないリスクが相対的に低いと考えられるため、関連し
きい値θ[m]の初期値を小さくして、そのようなものも推薦情報に入れるようにする。
【0273】
ステップS940cにおいて、情報選択部107cは、価格しきい値η[m]の初期値
として価格しきい値η[1]に値をセットする。第3実施例では、利用価格情報格納部1
12を参照しながら、推薦リクエストに含まれる利用主体識別子に対応する利用価格情報
に応じて、この初期値を変更する。
【0274】
価格しきい値η[m]の初期値設定の第1の方法は、ユーザuの価格水準値L[u]に
応じて、異なる初期値を用いる方法である。例えば、価格水準値L[u]に関するしきい
値δ7とδ8(δ7<δ8)と、初期値η1〜η3(η1<η2<η3)を用意しておき、L[u
]<δ7であれば、標準より小さいη1、δ7≦L[u]<δ8であれば、標準であるη2、
δ8≦L[u]であれば、標準より大きいη3を選択して初期値とする。
【0275】
すなわち、価格水準値L[u]が大きいほど、価格しきい値η[m]が大きくなる規則
を用いて、価格しきい値の初期値を設定する。このようにすることで、価格水準値L[u
]の大きいユーザ、すなわち購買能力の高いユーザや高額アイテムをよく利用するユーザ
に対して、より価格の高いものを推薦情報に入れることができ、アイテム提供サービスの
売上増大に効果的となる。一方、価格水準値L[u]の小さいユーザ、すなわち購買能力
の低いユーザや低額アイテムをよく利用するユーザに対しては、推薦情報の中に価格が安
いものを含めることができるので、ユーザの受容性が低下するのを防ぐことができる。
【0276】
価格しきい値η[m]の初期値設定の第2の方法は、ユーザuの価格分散値V[u]に
応じて、異なる初期値を用いる方法である。例えば、価格分散値V[u]に関するしきい
値ε7とε8(ε7<ε8)と、初期値η1〜η3(η1<η2<η3)を用意しておき、V[u
]<ε7であれば、標準より小さいη1、ε7≦V[u]<ε8であれば、標準であるη2、
ε8≦V[u]であれば、標準より大きいη3を選択して初期値とする。
【0277】
すなわち、価格分散値V[u]が大きいほど、価格しきい値η[m]が大きくなる規則
を用いて、価格しきい値の初期値を設定する。この結果、価格分散値V[u]が小さいほ
ど、価格しきい値η[m]の初期値は小さい傾向となる。価格分散値V[u]が小さなユ
ーザは、限られた価格帯のアイテムを利用する傾向や、所定期間ごとの利用アイテムの合
計額が安定している傾向があると想定される。すなわち、自分なりの利用パターンが確立
しているユーザであるといえる。このようなユーザでは、価格が高いものを推薦した場合
に受容されないリスクが大きいため、価格しきい値η[m]の初期値を小さくして、価格
の安いものが推薦情報に入りやすくしている。
【0278】
ステップS950c〜S980cとして、ステップS950b〜S980bと同じ処理
を行なう。
【0279】
ステップS990cにおいて、情報選択部107cは、変数mに対応する関連しきい値
θ[m]を設定する。ここで、θ[m−1]>θ[m]となるように設定する。第1実施
例と同様に、1つ前の関連しきい値との差分Dθ[m]を様々な方法で設定することがで
きる。さらに、以下に示すような方法で利用価格情報に応じて、差分Dθ[m]を設定し
てもよい。
【0280】
差分Dθ[m]設定の第1の方法は、ユーザuの価格水準値L[u]を用いる方法であ
る。例えば、価格水準値L[u]がしきい値δ9より小さい場合は、差分Dθ[m]を標
準より小さくして、関連しきい値θ[m]があまり小さくならないようにする。このよう
にすることで、価格水準値L[u]の小さいユーザの推薦情報に、関連度が低くて価格が
高いものが入りにくくなる。一方、価格水準値L[u]がしきい値δ10(ただしδ9<δ1
0)以上の場合は、関連度が低く価格が高いものでも、ユーザに受容される可能性は多少
あるので、差分Dθ[m]を標準より大きくしてもよい。この第1の方法は、価格水準値
L[u]が小さいほど、関連しきい値θ[m]が大きくなる規則を用いて、次の選択集合
を作成するための関連しきい値を設定しているといえる。
【0281】
差分Dθ[m]設定の第2の方法は、ユーザuの価格分散値V[u]を用いる方法であ
る。例えば、価格分散値V[u]がしきい値ε9より小さい場合は、差分Dθ[m]を標
準より小さくして、θ[m]があまり小さくならないようにする。このようにすることで
、価格分散値V[u]の小さいユーザの推薦情報に、関連度が低くて価格が高いものが入
りにくくなる。また、価格分散値V[u]がしきい値ε10(ただしε9<ε10)以上であ
る場合に、Dθ[m]を標準より大きくしてもよい。この第2の方法は、価格分散値V[
u]が小さいほど、関連しきい値θ[m]が大きくなる規則を用いて、次の選択集合を作
成するための関連しきい値を設定しているといえる。
【0282】
ステップS1000cにおいて、情報選択部107cは、変数mに対応する価格しきい
値η[m]を設定する。ここで、η[m−1]>η[m]となるように設定する。第1実
施例と同様に、1つ前の関連しきい値との差分Dη[m]を様々な方法で設定することが
できる。さらに、以下に示すような方法で利用価格情報に応じて、差分Dη[m]を設定
してもよい。
【0283】
差分Dη[m]設定の第1の方法は、ユーザuの価格水準値L[u]を用いる方法であ
る。例えば、価格水準値L[u]がしきい値δ11より小さい場合は、差分Dη[m]を標
準より大きくして、価格しきい値η[m]を小さくする。このようにすることで、価格水
準値L[u]の小さいユーザの推薦情報に、価格の安いものが入りやすくなり、ユーザの
受容性を高くすることができる。一方、価格水準値L[u]がしきい値δ12(ただしδ11
<δ12)以上の場合は、差分Dη[m]を標準より大きくして、価格しきい値η[m]を
大きくする。このようにすることで、価格水準値L[u]の大きなユーザの推薦情報に、
より価格の高いものが入りやすくなる。この第1の方法は、価格水準値L[u]が大きい
ほど、価格しきい値η[m]が大きくなる規則を用いて、次の選択集合を作成するための
価格しきい値を設定しているといえる。
【0284】
差分Dη[m]設定の第2の方法は、ユーザuの価格分散値V[u]を用いる方法であ
る。例えば、価格分散値V[u]がしきい値ε11より小さい場合は、差分Dη[m]を標
準より大きくして、価格しきい値η[m]を小さくする。このようにすることで、価格分
散値V[u]の小さいユーザの推薦情報に、価格の安いものが入りやすくなり、ユーザの
受容性を高くすることができる。一方、格分散値V[u]がしきい値ε12(ただしε11<
ε12)以上の場合は、差分Dη[m]を標準より小さくして、価格しきい値η[m]を大
きくする。このようにすることで、価格分散値V[u]の大きなユーザの推薦情報に、よ
り価格の高いものが入りやすくなる。この第2の方法は、価格分散値V[u]が大きいほ
ど、価格しきい値η[m]が大きくなる規則を用いて、次の選択集合を作成するための価
格しきい値を設定しているといえる。そして、ステップS950cに戻り、以降の処理を
繰り返す。
【0285】
ステップS1010c〜S1030cとして、ステップS1010〜S1030と同じ
処理を行なう。
【0286】
なお上述した方法では、ステップS930cおよびS990において、利用価格情報に
応じた関連しきい値θ[m]を設定し、ステップS940cおよびS1000において、
利用価格情報に応じた価格しきい値η[m]を設定しているが、関連しきい値θ[m]お
よび価格しきい値η[m]のうち、いずれか一方を利用価格情報に応じて設定し、もう一
方に標準値を設定するようにしてもよい。
【0287】
また、ステップS930cにおいて、利用価格情報を用いて関連しきい値θ[1]を設
定し、ステップS990において、利用価格情報を用いずに差分Dθ[m](m≧2)を
設定してもよい。逆に、ステップS930cにおいて、利用価格情報を用いずに関連しき
い値θ[1]を設定し、ステップS990において、利用価格情報を用いて差分Dθ[m
](m≧2)を設定してもよい。すなわち、利用主体識別子iに対応するNa[i]個の
選択集合を作成する際に用いるNa[i]個の関連しきい値θ[m]のうち、一部のみを
利用価格情報を用いて設定してもよい。価格しきい値η[m]についても同様であり、N
a[i]個の価格しきい値η[m]のうち、一部のみを利用価格情報を用いて設定しても
よい。また、複数の利用価格情報を用いて総合的な指標を算出し、その指標に基づいて、
関連しきい値および/または価格しきい値を設定してもよい。例えば、複数の利用価格情
報の乗算値、または重み付き加算値を算出し、総合的な指標として用いてもよい。
【0288】
また、
図24(b)に示すように、利用価格情報格納部112にアイテム区分ごとに利
用価格情報が格納されている場合には、ステップS930cおよびステップS990cに
おいて、アイテム区分ごとに関連しきい値θ[m]を設定することができる。またステッ
プS940cおよびステップ1000cにおいて、アイテム区分ごとに価格しきい値η[
m]を設定することができる。この場合、ステップS950cにおいて、アイテム区分情
報を参照しながら、処理対象の関連識別子がどのアイテム区分に対応するか特定し、特定
したアイテム区分に対応する関連しきい値θ[m]および価格しきい値η[m]を用いて
、選択集合Yを作成することができる。以上、ステップS410cについて説明した。
【0289】
第3実施例によれば、価格の高いアイテムおよびカテゴリを推薦結果に多く入れること
が可能である等、第1実施例と同様な効果が得られるのに加えて、ユーザごとに利用価格
情報に応じて適切に情報選択処理を行なうようにしているため、ユーザに特別な操作をさ
せることなく、ユーザが受容しやすい推薦情報を提供することができる。例えば、価格の
安いアイテムだけを利用するユーザには、推薦情報の中に、価格の高いアイテムだけでな
く、価格の安いアイテムもある程度入れることができる。従って、ユーザが推薦情報を納
得して受け入れやすくなる。このため推薦情報に基づくアイテム利用が活発になり、アイ
テム提供サービスの売上をさらに増大させることが期待できる。
【0290】
また、第2実施例と第3実施例とを組み合わせて、ユーザごとに利用価格情報に応じて
価格影響関数を設定した上で、ユーザの好みに応じてこの特性を変更できるようにしても
よい。このようにすれば、さらに受容性の高い推薦情報を提供することができる。
【0291】
なお、上述の第3実施例では、ユーザの利用価格情報に基づいて、価格影響関数の特性
をユーザごとに変えているが、これとは異なる方法で、価格影響関数の特性をユーザごと
に変えてもよい。例えば、ユーザが過去に提供された推薦情報をどの程度受け入れたかに
応じて価格影響関数の特性を変更することができる。
【0292】
この場合、過去のある時点においてユーザに提供された推薦情報に含まれるアイテムの
うち、推薦情報提供後にそのユーザによって実際に利用されたアイテムの数を算出し、そ
の数に基づいてユーザの利用度を算出する。利用度を算出する処理を行なうために、利用
度算出部を情報選択装置10に設けるようにしてもよい。そして、価格影響度算出部10
6cは、算出された利用度に応じて価格影響関数F(X)の特性を変えればよい。
【0293】
具体的には、利用度の高いユーザほど、価格の高いアイテム(カテゴリ)が推薦されや
すくなるように処理すればよい。これは、価格水準値が大きいユーザほど、価格の高いア
イテム(カテゴリ)が推薦されやすくなるように処理したのと同様である。
【0294】
利用度の高いユーザは、過去の推薦情報を多く受容しているので、推薦システムに対す
る信頼感をある程度持っていると考えられる。このため、このようなユーザに価格の高い
アイテム(カテゴリ)をより多く推薦しても、ユーザの購買意欲の低下につながるリスク
が小さいと考えられるからである。
【0295】
一方、利用度の低いユーザに、価格の高いアイテム(カテゴリ)をより多く推薦すると
、ユーザの購買意欲の低下につながるリスクが大きいと考えられる。このため、利用度の
低いユーザには、価格の安いアイテムもある程度推薦されやすくなる処理を行なうように
する。
【0296】
このようにユーザの推薦情報に対する利用度に応じて、価格影響関数の特性を変化させ
ることにより、さらにユーザの購買意欲が減少するリスクを減らしつつ、価格の高いアイ
テム(カテゴリ)を推薦することができる。また、ユーザの推薦情報に対する利用度と、
ユーザの利用価格情報を両方用いて、価格影響関数の特性を変えてもよい。
【0297】
利用度の具体的な算出方法としては、例えば、1日に1回の頻度で推薦情報を作成して
おり、前回(前日)にユーザAに対して10個の推薦アイテムを提供している場合、次に
新たな推薦情報を作成(提供)するまでの期間(約1日間)で、ユーザAが10個の推薦
アイテムのうち何個を利用したかを、利用履歴格納部102とを推薦情報格納部108と
を参照しながらカウントし、これを利用度とすればよい。
【0298】
また、ユーザAが1つの推薦アイテムを2回以上利用した場合、その回数を考慮して利
用度を算出してもよいし、2回以上利用しても1回だけ利用しても同等に扱って利用度を
算出してもよい。あるいは、ユーザAが10個の推薦アイテムのうちの1つ以上利用した
場合に、利用度を「1」、1つも利用しない場合に利用度を「0」などとして、ユーザA
が推薦情報を1回以上利用したか否かの情報を利用度としてもよい。
【0299】
ユーザAが推薦アイテムを利用した場合に、
図13に示すような推薦画面(推薦ページ
)から直接利用したのか、他のページで推薦アイテムを偶然見つけて利用したのかを区別
可能な情報(アイテム利用ページ識別情報)を利用履歴格納部102に格納した上で、推
薦ページから直接利用された分だけを利用度に反映させるようにしてもよい。このように
すると、ユーザAの推薦情報に対する受容の度合いをより直接的に利用度に反映させるこ
とができる。ただし、ユーザAが推薦アイテムを推薦情報が表示された画面から直接利用
していない場合であっても、そのユーザの嗜好に合致した推薦アイテムを選択できたと考
えられるので、推薦アイテムが利用されたページの種類を区別せずに利用度を算出しても
よい。
【0300】
なお、推薦アイテムの利用回数を集計する期間は、その推薦アイテムの情報を提供した
時点以降であれば、どのような期間を設定してもよい。例えば、ある推薦アイテムが、推
薦情報として提供された期間以降の期間も集計期間に含めてもよい。これは、ユーザがブ
ラウザのブックマーク機能等を用いて、推薦ページのURL等を一時的に保存しておき、
推薦情報の提供が終了した後に利用したような場合を含めて利用回数をカウントするため
である。また、集計開始時点も推薦情報が提供された時点以降であれば、どのように設定
してもよい。