JP4492354B2 - 情報処理装置および方法、並びにプログラム - Google Patents

Description

本発明は、情報処理装置および方法、並びにプログラムに関し、特に、ユーザによる嗜好傾向が異なるアイテムの各性質を考慮することで、ユーザに推薦すべき推薦アイテムを適切に決定することができる情報処理装置および方法、並びにプログラムに関する。

近年、情報処理システムのひとつとして、ユーザにアイテムを推薦するシステム（以下、単に推薦システムと称する）が普及してきている（例えば特許文献１参照）。アイテムとは、例えばユーザが購入可能な商品等を指し、特許文献１ではコンテンツとされている。なお、アイテムの詳細については後述する。

この従来の推薦システムでは、ユーザの嗜好を表現する１本のベクトル（以下、ユーザ嗜好ベクトルと称する）と、推薦候補となるアイテムを表現する１本のベクトル（以下、アイテム特徴ベクトルと称する）とを比較して、その比較結果を一定の尺度（距離、角度等）で表現し、その尺度を類似度として、その類似度が所定の条件を満たす場合、そのアイテム特徴ベクトルに対応するアイテムを、ユーザに推薦すべき推薦アイテムとして決定していた。
特開２００４−１９４１０８号公報

しかしながら、特許文献１を含む従来の推薦システムでは、種類や分野等性質の異なるアイテムを推薦する場合であっても、各性質毎のユーザの嗜好傾向の違いを十分に考慮できていないという課題があった。

換言すると、ユーザが嗜好する性質を有していないアイテムや、或いは、その性質を有してはいてもユーザにとって適切でないアイテム（嗜好傾向が異なるアイテムである）が、推薦アイテムとしてユーザに呈示される場合があるという課題があった。また、複数の種類の性質にまたがって複数の推薦アイテムがユーザに呈示される場合、各種類の性質毎の推薦アイテムの呈示数等の配分比率を最適化または個人化することが非常に困難であるという課題があった。

なお、特許文献１に記載の推薦システムでは、正履歴ベクトルと負履歴ベクトルとがユーザ嗜好ベクトルとして利用されている。しかしながら、正履歴ベクトルと負履歴ベクトルとは、アイテムの性質は特に考慮せずに、ユーザが過去に操作したアイテムの履歴や、その操作自体の履歴等を正負の２種類に分類して、２種類毎にそれぞれ生成されるベクトルのことをいう。従って例えば、正負を好き嫌いと定義すると、所定のアイテムが、ユーザが過去に好きと判断したアイテムに類似しているのか、或いは、嫌いと判断したアイテムに類似しているのかといった内容を判断する場合等に、正履歴ベクトルと負履歴ベクトルとが利用される。このように、正履歴ベクトルと負履歴ベクトルとは、アイテムの性質を考慮したベクトルとは言えない。

また、特許文献１には、コンテンツ（テレビジョン番組）のジャンル毎や出演者毎の正履歴ベクトルや負履歴ベクトルを利用して、推薦アイテムを決定することが示唆されている。

しかしながら、ジャンル毎や出演者毎の正履歴ベクトルや負履歴ベクトルだけでは、ユーザによる各ジャンルや各出演者についての嗜好傾向の違いを必ずしも反映できていないことから、ただ単に、ジャンル毎や出演者毎の正履歴ベクトルや負履歴ベクトルを利用して推薦アイテムが決定された場合、その推薦アイテムは、ユーザが嗜好する性質自体をたとえ有していたとしても、ユーザにとって必ずしも適切なアイテムであるとは限らない（嗜好傾向とは異なる推薦アイテムである場合もある）、という上述した課題がそのまま発生してしまう。

さらに、複数のジャンルや複数の出演者にまたがる複数の推薦コンテンツがユーザに呈示される場合、それらの呈示数等の配分比率を如何にして決定するのかについては特許文献１には開示は勿論示唆もされていない。従って、特許文献１に記載の推薦システムでは、各ジャンル毎或いは各出演者毎の推薦コンテンツの呈示数等の配分比率を最適化または個人化することが非常に困難になる、という上述した課題がそのまま発生してしまう。

このように、特許文献１に記載の推薦システムでは、各性質毎のユーザの嗜好傾向の違いを十分に考慮できていない。

本発明は、このような状況に鑑みてなされたものであり、ユーザによる嗜好傾向が異なるアイテムの各性質を考慮することで、ユーザに推薦すべき推薦アイテムを適切に決定することができるようにするものである。なお、ここでいう「適切に決定する」とは、１種類の性質を推薦対象にして、その種類の性質を有する推薦アイテムを適切に決定することの他、さらに、複数の種類の性質を推薦対象にして、各種類の性質毎に推薦アイテムを適切に決定するとともに、各種類の性質毎の呈示数の比率等を適切に決定することも含む。

本発明の情報処理装置は、複数のアイテムを販売するためのウェブページに対するユーザの操作履歴を取得して、アイテムの種別毎に、ウェブページにおける、所定の種別のアイテムが属するカテゴリのページへの第１のアクセス数、所定の種別のアイテムのページへの第２のアクセス数、および所定の種別のアイテムの購入操作に伴うアクセスの回数である第３のアクセス数と、所定の種別の第１のアクセス数乃至第３のアクセス数を重み付き加算して得られる積算ポイントとを示す操作履歴管理情報を生成し、操作履歴管理情報を記憶する記憶手段と、アイテムの種別毎に、ユーザの操作履歴を用いて、種別のアイテムに関するユーザの嗜好傾向を示すユーザ嗜好ベクトルを生成する嗜好ベクトル生成手段と、複数の種別の中から推薦対象の複数の種別が指定された場合、全ての推薦対象の種別の積算ポイントの和と、推薦対象の種別の積算ポイントとの比を求めることで、ユーザに対する推薦対象の種別毎のアイテムの呈示の配分比を決定する配分比決定手段と、推薦対象の種別が指定された場合、推薦対象の種別毎に、種別のユーザ嗜好ベクトルと、推薦対象の種別のアイテムの特徴を示す特徴ベクトルとの類似度を余弦相関により演算し、演算された類似度が閾値以上である特徴ベクトルに対応するアイテムのうちの、推薦対象の種別の配分比により定まる数のアイテムを、ユーザに推薦すべき推薦アイテムとして決定する推薦手段とを備えることを特徴とする。

推薦アイテムを示す情報が、推薦アイテムの類似度の高い順に並べられた推薦リストを生成する推薦リスト生成手段をさらに設けることができる。

本発明の情報処理方法は、記憶手段が、複数のアイテムを販売するためのウェブページに対するユーザの操作履歴を取得して、アイテムの種別毎に、ウェブページにおける、所定の種別のアイテムが属するカテゴリのページへの第１のアクセス数、所定の種別のアイテムのページへの第２のアクセス数、および所定の種別のアイテムの購入操作に伴うアクセスの回数である第３のアクセス数と、所定の種別の第１のアクセス数乃至第３のアクセス数を重み付き加算して得られる積算ポイントとを示す操作履歴管理情報を生成し、操作履歴管理情報を記憶する記憶ステップと、嗜好ベクトル生成手段が、アイテムの種別毎に、ユーザの操作履歴を用いて、種別のアイテムに関するユーザの嗜好傾向を示すユーザ嗜好ベクトルを生成する嗜好ベクトル生成ステップと、配分比決定手段が、複数の種別の中から推薦対象の複数の種別が指定された場合、全ての推薦対象の種別の積算ポイントの和と、推薦対象の種別の積算ポイントとの比を求めることで、ユーザに対する推薦対象の種別毎のアイテムの呈示の配分比を決定する配分比決定ステップと、推薦手段が、推薦対象の種別が指定された場合、推薦対象の種別毎に、種別のユーザ嗜好ベクトルと、推薦対象の種別のアイテムの特徴を示す特徴ベクトルとの類似度を余弦相関により演算し、演算された類似度が閾値以上である特徴ベクトルに対応するアイテムのうちの、推薦対象の種別の配分比により定まる数のアイテムを、ユーザに推薦すべき推薦アイテムとして決定する推薦ステップとを含むことを特徴とする。

本発明のプログラムは、記憶制御手段が、複数のアイテムを販売するためのウェブページに対するユーザの操作履歴を取得して、アイテムの種別毎に、ウェブページにおける、所定の種別のアイテムが属するカテゴリのページへの第１のアクセス数、所定の種別のアイテムのページへの第２のアクセス数、および所定の種別のアイテムの購入操作に伴うアクセスの回数である第３のアクセス数と、所定の種別の第１のアクセス数乃至第３のアクセス数を重み付き加算して得られる積算ポイントとを示す操作履歴管理情報を生成し、操作履歴管理情報の記憶を制御する記憶制御ステップと、嗜好ベクトル生成手段が、アイテムの種別毎に、ユーザの操作履歴を用いて、種別のアイテムに関するユーザの嗜好傾向を示すユーザ嗜好ベクトルを生成する嗜好ベクトル生成ステップと、配分比決定手段が、複数の種別の中から推薦対象の複数の種別が指定された場合、全ての推薦対象の種別の積算ポイントの和と、推薦対象の種別の積算ポイントとの比を求めることで、ユーザに対する推薦対象の種別毎のアイテムの呈示の配分比を決定する配分比決定ステップと、推薦手段が、推薦対象の種別が指定された場合、推薦対象の種別毎に、種別のユーザ嗜好ベクトルと、推薦対象の種別のアイテムの特徴を示す特徴ベクトルとの類似度を余弦相関により演算し、演算された類似度が閾値以上である特徴ベクトルに対応するアイテムのうちの、推薦対象の種別の配分比により定まる数のアイテムを、ユーザに推薦すべき推薦アイテムとして決定する推薦ステップとを含むことを特徴とする。

本発明の情報処理装置および方法、並びにプログラムにおいては、複数のアイテムを販売するためのウェブページに対するユーザの操作履歴が取得されて、アイテムの種別毎に、ウェブページにおける、所定の種別のアイテムが属するカテゴリのページへの第１のアクセス数、所定の種別のアイテムのページへの第２のアクセス数、および所定の種別のアイテムの購入操作に伴うアクセスの回数である第３のアクセス数と、所定の種別の第１のアクセス数乃至第３のアクセス数が重み付き加算されて得られる積算ポイントとを示す操作履歴管理情報が生成され、操作履歴管理情報が記憶され、アイテムの種別毎に、ユーザの操作履歴が用いられて、種別のアイテムに関するユーザの嗜好傾向を示すユーザ嗜好ベクトルが生成され、複数の種別の中から推薦対象の複数の種別が指定された場合、全ての推薦対象の種別の積算ポイントの和と、推薦対象の種別の積算ポイントとの比を求めることで、ユーザに対する推薦対象の種別毎のアイテムの呈示の配分比が決定され、推薦対象の種別が指定された場合、推薦対象の種別毎に、種別のユーザ嗜好ベクトルと、推薦対象の種別のアイテムの特徴を示す特徴ベクトルとの類似度が余弦相関により演算され、演算された類似度が閾値以上である特徴ベクトルに対応するアイテムのうちの、推薦対象の種別の配分比により定まる数のアイテムが、ユーザに推薦すべき推薦アイテムとして決定される。

以上のごとく、本発明によれば、アイテムをユーザに対して推薦することができる。特に、アイテムの種類や分野とった性質を考慮して、ユーザに推薦すべき推薦アイテムを適切に決定することができる。

次に、本発明の実施の形態を説明する前に、本発明の原理について説明する。

なお、本明細書において、アイテムとは、ユーザに提供可能なソフトウエアまたはハードウエア（物品）をいう。例えば、いわゆるコンテンツ、即ち、テレビジョン放送番組、映画、写真、楽曲等（動画像、静止画像、若しくは音声、または、それらの組合せ等）といったソフトウエアも、本明細書でいうアイテムである。また、例えば、ワイン等の物品（ハードウエア）も、本明細書でいうアイテムである。その他、例えば、文章や会話等も、本明細書でいうアイテムである。

ただし、本発明の理解を容易なものとするために、以下、アイテムの具体例を挙げる必要がある場合、所定の容器（例えば750mlの瓶等）に詰められたワイン（葡萄酒）が採用されているとする。

はじめに、従来から一般的に行われているアイテムを推薦するまでの一連の処理（以下、単に推薦処理と称する）の一例について、その概略を説明する。

ただし、説明の簡略上、１台の情報処理装置が推薦処理の全てを実行するとする。

はじめに、従来の情報処理装置は、とあるアイテムの特徴を示すＮ個（Ｎは、１以上の整数値）の情報のそれぞれを基底ベクトルとして、そのアイテムをベクトル化する。その際、従来の情報処理装置は、必要に応じて、そのベクトルの各成分のそれぞれに対して、所定の重み付け手法を利用して重み付けを行う（重み値を与える）。

このようにしてアイテムがベクトル化された結果得られるベクトルが、上述したアイテム特徴ベクトルになる。なお、以下、アイテムの特徴を示す情報を属性情報と称し、属性情報の種類を、属性と称する。即ち、所定のアイテムに対して、Ｎ個の属性のそれぞれの属性情報が対応付けられている場合、Ｎ個の属性情報が数値化され（重み付けが行われ）、その結果得られるＮ個の数値を成分値として有するベクトルが、アイテム特徴ベクトルである。

なお、Ｎ個の属性のうちの所定の属性について、属性情報がアイテムに対応付けられていない場合、そのアイテムのアイテム特徴ベクトルのうちのその所定の属性に対応する成分には、０が代入されるとする。

従来の情報処理装置は、このようなアイテム特徴ベクトルを各アイテム毎にそれぞれ生成し、蓄積する。即ち、このようにして蓄積された各アイテム特徴ベクトルのそれぞれに対応するアイテムが、推薦候補の対象となる。

一方、従来の情報処理装置は、ユーザの過去の操作履歴や、ユーザ自身により入力された各種情報を利用して、ユーザの嗜好を示すベクトルを生成する。係るベクトルが、上述したユーザ嗜好ベクトルである。なお、以下、ユーザ嗜好ベクトルを、UPV(User Preference Vector)と適宜称する。

そして、従来の情報処理装置は、このUPVと、蓄積された複数のアイテム特徴ベクトルのそれぞれとの余弦相関などの類似度をそれぞれ求め（マッチング処理を行い）、例えば、類似度が閾値以上であるアイテム特徴ベクトルに対応するアイテムを、ユーザに推薦すべき推薦アイテムとしてユーザに呈示する。

以上、従来の推薦システムにおける推薦処理の概略について説明した。

ところで、推薦候補の対象となる複数のアイテムが複数の種類や分野にまたがっている場合、同一ユーザであっても、そのユーザの嗜好傾向は、アイテムの種類や分野に応じて自ずと変わってくることが多い。

例えば、アイテムがワインである場合、ワインというものは、赤ワイン、白ワイン、および、スパークリングワインといった３種類に分類できる。なお、より正確には、ロゼワイン（赤ワインに含めてもよい）や酒精強化ワイン等その他の種類も存在することから、実際には３種類よりも多い種類にワインは分類されるが、ここでは、説明の簡略上、３種類のみに言及する。この場合、一般的には、赤ワイン、白ワイン、およびスパークリングワインの３種類全てについて同一の嗜好傾向を示すユーザの数は少なく、３種類のそれぞれ毎に異なる嗜好傾向を示すユーザの数が多い。

具体的には例えば、同一ユーザであっても、その嗜好傾向は、「赤ワインならば、フルボディの渋めのブルゴーニュ」、「白ワインならば、甘めのドイツワイン」、および「スパークリングワインならば、辛口のシャンパーニュ」のそれぞれといったように全く異なる傾向になることが多い。即ち、「味」の属性だけに着目すると、このユーザの嗜好傾向は、赤ワインについては「フルボディの渋め」であり、白ワインについては「甘め」であり、またスパークリングワインについては「辛口」であるといったように、赤ワイン、白ワイン、およびスパークリングワインの３種類でまちまちである。同様に、「産地」の属性だけに着目すると、赤ワインについてはフランスの「ブルゴーニュ」地方であり、白ワインについては「ドイツ」であり、またスパークリングワインについてはフランスの「シャンパーニュ」地方であるといったように、赤ワイン、白ワイン、およびスパークリングワインの３種類でまちまちである。

しかしながら、従来の推薦システムでは、ワインの推薦を行う場合、赤ワイン、白ワイン、およびスパークリングワインの３種類のそれぞれについて、このように同一ユーザでも全く異なる嗜好傾向を示すにも関わらず、これらの３種類についてのユーザの嗜好の違いを考慮できていなかった、という上述した従来の課題が生じてしまう。即ち、従来の推薦システムでは、これらの３種類を１つにまとめた単なる「ワイン」についてのユーザ嗜好ベクトルを生成して、そのユーザ嗜好ベクトルを利用して推薦ワインを決定するだけであった、という従来の課題が生じてしまう。従って、このようにして決定された推薦ワインが、ユーザにとって必ずしも適切なワインでないという問題が生じることは自明である。

そこで、本発明人は、次のような手法を発明した。

即ち、例えばワインの推薦を行う場合には、赤ワインについてのユーザ嗜好ベクトル、白ワインについてのユーザ嗜好ベクトル、および、スパークリングワインについてのユーザ嗜好ベクトルのそれぞれを生成して、蓄積および管理を行う。そして、必要に応じて、赤ワインについてのユーザ嗜好ベクトルと、赤ワインのアイテム特徴ベクトルとの類似度を演算し、その類似度が所定の条件を満たすアイテム特徴ベクトルに対応する赤ワインを、推薦アイテムとして決定する。同様に、必要に応じて、白ワインについてのユーザ嗜好ベクトルと、白ワインのアイテム特徴ベクトルとの類似度を演算し、その類似度が所定の条件を満たすアイテム特徴ベクトルに対応する白ワインを、推薦アイテムとして決定する。必要に応じて、スパークリングワインについてのユーザ嗜好ベクトルと、スパークリングワインのアイテム特徴ベクトルとの類似度を演算し、その類似度が所定の条件を満たす特徴ベクトルに対応するスパークリングワインを、推薦アイテムとして決定する。以上の一連の処理に対応する手法が、本発明人により新たに発明された手法である。

より一般的な表現に改めると、本発明の手法とは、結局、次の第１の処理と第２の処理とを実現可能な手法である。

即ち、第１の処理とは、アイテムが取り得る複数の性質毎に、対応する性質を有する１以上のアイテムのそれぞれに関するユーザの過去の操作履歴を利用して、ユーザ嗜好ベクトルのそれぞれを生成する、といった処理である。

なお、対応する性質を有するアイテムに関するユーザの過去の操作履歴とは、例えばアイテムがワインであり、かつ、対応する性質が赤ワインの場合には、ユーザが、情報処理装置を利用して行う操作のうちの、所定の赤ワイン（例えばシャトー○○という名称の赤ワイン）を購入するまでに行った操作、シャトー○○の試飲結果（評価）の入力操作、インターネット上等に存在するシャトー○○の情報を入手するまでの操作、或いは、シャトー○○といった特定の１つの赤ワインではなく、赤ワイン全体についての左記の各種操作等をいう。さらに、アイテムが、ワインのような物品ではなく、コンテンツのように情報処理装置を利用して使用可能なソフトウエアである場合には、そのソフトウエアそのものの操作も、対応する性質を有するアイテムに関するユーザの過去の操作履歴の一例である。

また、上述したように、特許文献１には、ジャンルや出演者毎の正履歴ベクトルや負履歴ベクトルを生成することが記述されているが、ジャンルや出演者毎の正履歴ベクトルや負履歴ベクトルは、ユーザによる各性質の嗜好傾向の違いを必ずしも考慮できていない（反映していない）。即ち、特許文献１では、ただ単に、ジャンル自体または出演者自体の好き嫌いがあるという点から、ジャンルや出演者毎の正履歴ベクトルや負履歴ベクトルを生成することが提案されている。従って、例えば、特許文献１の手法に従って生成されたドラマの正履歴ベクトルでは、特許文献１にも記載されているように、特に好きな俳優でもないに関わらず、ただ単にドラマに頻繁に登場する出演者Ｂのポイント（成分値）が高ポイントになってしまう。しかしながら、ドラマが好きと一口にいっても、その好きな理由（嗜好傾向）は、出演者Ｂがドラマに頻繁に登場しているからではなく他の理由からであるが、この「他の理由」がドラマの正履歴ベクトルに必ずしも反映されない。従って、ただ単に特許文献１を参照しただけでは、赤ワイン、白ワイン、およびスパークリングワインの３種類の性質といった、ユーザの嗜好傾向の違いが考慮された（その違いが明確になる）各性質について個別にユーザ嗜好ベクトルを生成することを容易に思想することはできない。即ち、ここで言うアイテムの性質とは、ただ単に一般的に分類された性質を指すのではなく、ユーザの嗜好傾向の違いを考慮して分類し直した或いは選抜した性質を指す。即ち、ワインには、後述するように、その他の様々な性質、例えば、産地や価格等様々な性質が存在するが、これらの性質の全てについて個別にユーザ嗜好ベクトルを生成すればよいのではなく、ユーザの嗜好傾向の違いが考慮された（その違いが明確になる）各性質についてユーザ嗜好ベクトルを生成するとよい。

第２の処理とは、アイテムが取り得る各性質のうちの推薦対象の性質を決定し、推薦対象の性質についてのユーザ嗜好ベクトルと、推薦対象の性質を有する１以上のアイテムのアイテム特徴ベクトルのそれぞれとの類似度を演算し、演算された類似度が所定の条件を満たすアイテム特徴ベクトルに対応するアイテムを、推薦対象の性質を有する推薦アイテムとして決定する、という処理である。

この推薦対象として、複数の性質が決定された場合、第２の処理の結果、推薦対象となった複数の性質毎に、推薦アイテムが１以上決定されることになる。例えばアイテムがワインの場合であって、赤ワイン、白ワイン、およびスパークリングワインの全てが推薦対象とされた場合には、推薦アイテム（推薦ワイン）として、１以上の赤ワイン、１以上の白ワイン、および、１以上のスパークリングワインがそれぞれ決定されることになる。この場合、推薦アイテムを全てユーザに呈示することは、当然ながら可能であるが、その総数があまりにも多いとき、または、ユーザに推薦アイテムを画像として呈示するための表示画面が小型のとき（例えばユーザが携帯型端末を利用しているとき）等では不適である。

そこで、このようなとき、全ての推薦アイテムのうちの、幾つかの推薦アイテを選抜して、ユーザに呈示することが必要になる。この際の選抜手法は、特に限定されず、推薦対象とされた複数の性質の全てについて一律に、推薦度が上位ｍ個（ｍは、１以上の任意の数）の推薦アイテムを選抜するという手法、即ち、推薦対象の全性質とも呈示数の比率を一律にするという手法を採用してもよい。しかしながら、ユーザにとって、推薦対象とされた複数の性質は全て同一の重要度を持っているとは限らず、この手法を採用した場合、その呈示数の比率はユーザにとって必ずしも適切ではない、という新たな課題が発生してしまう。

そこで、本発明人は、この新たな課題も解決すべく、上述した本発明の手法に加えて、推薦アイテムをユーザに呈示する場合、第１の条件に従って呈示数の比率を決定する、という手法も発明した。この手法が適用されると、推薦対象の各性質毎に、対応する性質を有する複数の推薦アイテムの中から、対応する性質についての呈示数の比率と呈示総数とで決定される個数（この個数は、１以上の任意の整数値であり、性質毎に異なる値となることが多い）の推薦アイテムを、第２の条件に従ってそれぞれ選抜し、各性質毎にそれぞれ選抜された幾つかの個数の推薦アイテムをユーザに呈示することが可能になる。即ち、各性質毎に個数がまちまちの（配分比が異なることが多いため）推薦アイテムをユーザに呈示することが可能になる。

第１の条件は、特に限定されず、様々な条件を適用することができる。具体的には例えば、アイテムがワインとして、操作履歴として購入操作履歴に着目すると、赤ワイン、白ワイン、およびスパークリングワインのそれぞれを、７：２：１の比率で購入しているユーザに対しては、その購入数（操作履歴数）の比率を呈示数の比率とする条件を、第１の条件として適用することが可能である。この場合、呈示の配分比も７：２：１となる。即ち、赤ワインの呈示数の比率が７０％、白ワインの呈示数の比率が２０％、および、スパークリングワインの呈示数の比率が１０％となる。従って、１０本の推薦ワインが呈示可能であるとすると、７本の赤ワイン、２本の白ワイン、および、１本のスパークリングワインのそれぞれが推薦ワインとして、ユーザに呈示されることになる。なお、第１の条件のその他の具体例については、図２乃至図５を参照して後述する。

第２の条件も、特に限定されず、例えば、所定の性質についての呈示数がｎ（ｎは、０以上の任意の数である。ただし、ｎは、各性質毎に異なる値であることが多い）である場合、その所定の性質を有する推薦アイテムのうちの、推薦度が上位ｎ番目までの推薦アイテムを選抜する、という条件を採用してもよい。

なお、呈示数の比率の決定タイミングが、上述した例では、推薦アイテム決定後とされたため、所定の性質を有する複数の推薦アイテムの中から、例えばｎ個の推薦アイテムが選抜された。ただし、呈示数の比率の決定タイミングは、当然ながら、推薦アイテム決定前でもよい。この場合、所定の性質についての呈示数がｎ個であることが先に決定されていれば、所定の性質を有する複数のアイテム（推薦アイテムの候補）の中から、ｎ個丁度の推薦アイテムを単に決定すればよいことになる。

以上、本発明の原理（手法）について説明した。

次に、図面を参照して、本発明の実施の形態について説明する。

図１は、上述した本発明の手法が適用される推薦システム、即ち、本発明が適用される推薦システムの機能的構成例を表している。即ち、図１の推薦システムは、複数のアイテムの中からユーザに推薦すべき推薦アイテムを検索し、その検索結果をユーザに呈示する。

図１の例では、推薦システムは、推薦サーバ１、アプリケーションサーバ２、および、ユーザ機器３から構成されている。

なお、推薦サーバ１、アプリケーションサーバ２、および、ユーザ機器３のそれぞれは、図１の例では１台ずつ図示されているが、それらの台数は図１の例に限定されず任意の台数でよい。例えば、複数のユーザが存在する場合、複数のユーザのそれぞれが使用するユーザ機器３が存在することになり、当然ながら、ユーザ機器３の台数は必ずしも１台とはならない。

推薦サーバ１は、アプリケーションサーバ２との間で通信を行う。なお、その通信の形態は、特に限定されず、例えば、図１には図示していないが、１以上のネットワークを介在する形態でもよい。アプリケーションサーバ２は、推薦サーバ１の他、ユーザ機器３との間で通信を行う。なお、その通信の形態は、特に限定されず、図１の例ではネットワーク４を介在する形態とされているが、図１の例に限定されず、例えばネットワーク４を介在せずに直接通信を行う形態でもよい。また、ネットワーク４の形態も特に限定されない。ただし、本実施の形態では、ネットワーク４は、例えばインターネットであるとする。

推薦サーバ１は、上述した本発明の手法に対応する処理を主に実行する。このため、推薦サーバ１には、操作履歴管理部１１乃至推薦リスト生成部１４が設けられている。

操作履歴管理部１１は、ユーザがユーザ機器３の操作部３１を操作した場合、その操作内容をアプリケーションサーバ２を介して取得して、操作履歴として管理する。

ここで注目すべき点は、操作履歴管理部１１は、その操作内容を、アイテムの各性質毎に個別に管理する点である。具体的には例えば、本実施の形態ではアイテムは上述したようにワインとされているので、その性質として、上述した赤ワイン、白ワイン、および、スパークリングワインの３種類に着目した場合には、操作履歴管理部１１は、赤ワインについての操作内容、白ワインについての操作内容、および、スパークリングワインについての操作内容のそれぞれを個別に管理する。

操作履歴管理部１１の管理手法は、特に限定されないが、ここでは、各性質毎のユーザ嗜好ベクトル(UPV)の生成および更新、並びに、UPV管理表の生成および更新を行う手法が採用されているとする。

なお、操作履歴管理部１１は、UPVの生成または更新を行う場合、基本的に、アプリケーションサーバ２の操作履歴取得部２１から供給される情報（ユーザの操作履歴情報）を利用するが、この情報に特定のワインが含まれる場合、例えば、ユーザが特定のワインの詳細情報を見たといった操作内容や、ワインを購入したといった操作内容がこの情報に含まれる場合、アイテム特徴ベクトル記憶部１３に記憶されているアイテム特徴ベクトルのうちの、その特定のワインのアイテム特徴ベクトルも利用する。

この各性質毎のUPVとUPV管理表とが、UPV/UPV管理表記憶部１２にユーザ毎に個別に記憶されている。

具体的には例えば、本実施の形態ではアイテムは上述したようにワインとされているので、その性質として、上述した赤ワイン、白ワイン、および、スパークリングワインの３種類に着目した場合には、赤ワインについてのUPV、白ワインについてのUPV、および、スパークリングワインについてのUPVのそれぞれが、UPV/UPV管理表記憶部１２に記憶されて管理されることになる。

また、UPV/UPV管理表記憶部１２に記憶されて管理されるUPV管理表とは、上述した推薦アイテムの呈示数の比率を決定するために利用される表であって、各ユーザ毎に個別に作成されて管理される表のことを言う。即ち、上述したように呈示数の比率は第１の条件に従って決定されるが、この第１の条件にとって適切なUPV管理表が、UPV/UPV管理表記憶部１２に記憶されて管理されることになる。

このようなUPV管理表の具体例が図２乃至図４に示されている。そこで、以下、図２乃至図４を参照して、UPV管理表のそれぞれの具体例について、その順番で個別に説明していく。

図２は、UPVの更新（アクセス）頻度に応じて呈示数の比率が決定される場合に利用されるUPV管理表の具体例を示している。

即ち、例えばいま、アプリケーションサーバ２が、物品やコンテンツといったアイテム（本実施の形態ではワイン）を提供（販売等）するサービスを行うためのホームページ等（以下、サイトと称する）をインターネット４上で管理しているとする。そして、ユーザは、このサイトを見て（ユーザ機器３の表示部３２に表示させ）、個々のアイテムやそれらが属するカテゴリに対するアクセス操作（いわゆるクリック操作等）や購入手続き操作を行う（操作部３１の対応する操作を行う）とする。また、この操作が行われる毎に、対応する性質のUPVも更新されるとする。なお、この仮定は、後述する図３と図４との説明においても成立するとする。

この場合、各性質についてのUPV毎に、更新の回数またはアクセスの回数を蓄積することで、UPVの更新（アクセス）頻度に応じた呈示数の比率の決定が可能になる。このUPVの更新の回数またはアクセスの回数が記述される表の一具体例が、図２のUPV管理表である。

図２のUPV管理表において、第１列目の各行には、上から順に、UPVの名称が記述されており、最後に「各期間合計」が記述されている。ここで注目すべき点は、第１列目の各行に記述されている各UPVは何れも、とある一人のユーザについてのUPVであるという点である。即ち、とある一人のユーザについての、アイテムの各性質毎のUPVがUPV管理表に含まれているという点である。

なお、以下、説明の簡略上、「UPV１」は、赤ワインについてのUPVとされ、「UPV２」は、白ワインについてのUPVとされているとする。

第２列目以降の各列には、各期間のそれぞれにおける、各UPVの更新の回数またはアクセスの回数が記述され、最後の列には、全期間にわたっての各UPVの更新の回数またはアクセスの回数が記述される。従って、現時点を含む期間に対応する列と、全期間に対応する列とが更新の対象になる。なお、各期間は、特に限定されず、任意の期間でよく、他の期間と同一の長さである必要も特にない。さらに、各期間は、他の期間にまたがってもよい。例えば、「期間１」を、１セッション（ユーザがサイトを開いてから閉じるまで）として、「期間２」を、本日中（例えば午前６時から翌日午前６時まで）としてもよい。

例えば、「期間１」においては、「UPV1」の更新の回数またはアクセスの回数、即ち、赤ワインについてのユーザの操作回数は「３回」であり、「UPV２」の更新の回数またはアクセスの回数、即ち、白ワインについてのユーザの操作回数は「１回」であったことがわかる。なお、「期間１」が例えば過去の期間（先週等）である場合には、「期間１」についての第２列目の記述内容は更新されない。

また例えば、「期間２」においては、「UPV1」の更新の回数またはアクセスの回数、即ち、赤ワインについてのユーザの操作回数は「１０回」であり、「UPV２」の更新の回数またはアクセスの回数、即ち、白ワインについてのユーザの操作回数は「５回」であったことがわかる。なお、「期間２」が例えば現時点を含む期間（今週等）である場合には、「期間２」についての第３列目は更新対象になる。即ち、例えば、その後、赤ワインについてのユーザ操作が行われると、「期間２」である第３列目の、「UPV1」である第２行目の記述内容が「１０回」から「１１回」に更新されることになる。なお、その際、「期間２」である第３列目の、「各期間合計」である最後の行の記述内容が「１８回」から「１９回」に更新されるとともに、「全期間」である最後の列の、「UPV1」である第２行目の記述内容が「５８回」から「５９回」に更新される

この図２の例のようなUPV管理表がUPV/UPV管理表記憶部１２に記憶され、操作履歴管理部１１により管理されることで、後述する推薦リスト生成部１４は、このUPV管理表を使用して、UPVの更新（アクセス）頻度に応じて呈示数の比率を容易に決定することが可能になる。なお、推薦リスト生成部１４による呈示数の比率の具体的な演算手法については後述する。

図３は、UPVの更新（アクセス）頻度に対してアクセス内容に応じた重み付けが行われ、重み付け後のUPVの更新（アクセス）頻度に応じて呈示数の比率が決定される場合に利用されるUPV管理表の具体例を示している。

上述したように、図３におていも図２と同様の仮定が成立しているとすると、UPVの更新またはアクセスの度に、アクセス内容に応じた重み（荷重）を積算し、その積算結果を蓄積することで、重み付け後のUPVの更新（アクセス）頻度に応じた呈示数の比率の決定が可能になる。この積算結果（重み付け後のUPVの更新の回数またはアクセスの回数）が記述される表の一具体例が、図３のUPV管理表である。

図３のUPV管理表において、第１列目の各行には、上から順に、UPVの名称が記述されており、最後に「合計」が記述されている。なお、以下、説明の簡略上、「UPV１」は、図２と同一の「UPV1」、即ち、同一ユーザの赤ワインについてのUPVとされ、「UPV２」は、図２と同一の「UPV2」、即ち、同一ユーザの白ワインについてのUPVとされているとする。

第２列目乃至第５列目のそれぞれには、「大カテゴリ」、「小カテゴリ」、「商品詳細」、および「商品購入」のそれぞれにおける、各UPVの更新の回数またはアクセスの回数そのものが記述される。

「大カテゴリ」、「小カテゴリ」、「商品詳細」、および「商品購入」のそれぞれは、アクセス内容を示している。即ち、一般的に、商品の販売サイトの構造は、カテゴリの大小に応じて階層化され、各階層毎のページが作成されていることが多い。このため、ユーザは、購入希望商品を見つけ出す場合、大きなカテゴリのページから小さなカテゴリのページに順次アクセスして対象を絞っていくことで、購入希望商品を特定することが多い。従って、大カテゴリのページへのアクセスが「大カテゴリ」に分類され、小カテゴリのページへのアクセスが「小カテゴリ」に分類され、購入希望商品を含む各商品の詳細内容が呈示されるページへのアクセスが「商品詳細」に分類され、かつ、購入希望商品の購入操作に伴うアクセスが「商品購入」に分類されることになる。

具体的には、例えばワインの販売サイトでは、その産地がカテゴリとされていることが多く、ユーザが例えばフランスのボルドー地方のシャトー○○という名称のワインを購入したいと考えた場合、次のような操作を行うことが多い。即ち、例えばはじめに、ユーザは、各国の名称等が呈示される第１のページ（例えばトップページ等）にアクセスする。例えば次に、ユーザは、第１のページの中からフランスを指定する操作を行うことで、フランスの各地方（ボルドー、ブルゴーニュ等）の名称等が呈示される第２のページにアクセスする。例えば次に、ユーザは、第２のページの中からボルドーを指定する操作を行うことで、ボルドー産のワインの詳細（名称、値段、コメント等）が呈示されている第３のページにアクセスする。そして例えば、ユーザが、第３のページのうちシャトー○○の購入に必要な各種操作を行う。この場合、第１のページへのアクセスが「大カテゴリ」に分類され、第２のページへのアクセスが「小カテゴリ」に分類され、第３のページへのアクセスが「商品詳細」に分類され、かつ、シャトー○○の購入に必要な各種操作に伴うアクセスが「商品購入」に分類されることになる。

この場合、ユーザにとってのアクセスの重要度は、一般的に、「大カテゴリ」、「小カテゴリ」、「商品詳細」、および「商品購入」の順に順次高くなっていく。即ち、ユーザが、所定の性質のアイテムについて、「大カテゴリ」までの操作を行った場合と、「商品詳細」までの操作を行った場合とでは、後者の場合の方が、所定の性質に対してより重要である（興味を持っている等）とユーザが捉えているとみなすことができる。

そこで、図３の例では、「大カテゴリ」、「小カテゴリ」、「商品詳細」、および「商品購入」のそれぞれに対して、荷重（重要度）として、１，２，３，５のそれぞれを与えているのである。これにより、UPVの更新（アクセス）頻度をアクセス内容に応じて重み付けを行うことが可能になる。

即ち、「積算ポイント」である第６列目のそれぞれには、アクセス内容に応じた重み付けがなされた後の各UPVの更新の回数またはアクセスの回数が記述されるのである。なお、以下、アクセス内容に応じた重み付けがなされた後の各UPVの更新の回数またはアクセスの回数を、図３の記載にあわせて、「積算ポイント」と称する。

具体的には例えば、「UPV1」の「積算ポイント」は、「４４」（＝３(回)×１（荷重）＋８（回）×２（荷重）＋５（回）×３（荷重）＋２（回）×５（荷重））となる。同様に例えば、「UPV2」の「積算ポイント」は、「１８」（＝１(回)×１（荷重）＋３（回）×２（荷重）＋２（回）×３（荷重）＋１（回）×５（荷重））となる。

この図３の例のようなUPV管理表がUPV/UPV管理表記憶部１２に記憶され、操作履歴管理部１１により管理されることで、後述する推薦リスト生成部１４は、このUPV管理表を使用して、「積算ポイント」に応じて呈示数の比率を容易に決定することが可能になる。なお、推薦リスト生成部１４による呈示数の比率の具体的な演算手法については後述する。

図４は、ユーザの過去の操作傾向に応じて呈示数の比率が決定される場合におけるUPV管理表の具体例を示している。

上述したように、図４におていも図２や図３と同様の仮定が成立しているとすると、ユーザの操作履歴の傾向を分析することで、類似度の演算に利用されるUPVが第１のUPVから第２のUPVへ遷移する遷移確率や、２以上のUPVが同時に類似度の演算に利用される確率を計算し、それらの確率に応じた呈示数の比率の決定することが可能になる。これにより、例えば、ユーザの購買の遷移傾向（操作傾向）に追従して、アイテムの推薦を適切に行うことが可能になる。このような確率のうちの遷移確率が記述される表の一具体例が、図４のUPV管理表である。

図４のUPV管理表において、第１列目の各行には、上から順に、UPVの名称が記述されており、最後に「合計」が記述されている。なお、以下、説明の簡略上、「UPV１」は、図２と同一の「UPV1」、即ち、同一ユーザの赤ワインについてのUPVとされ、「UPV２」は、図２と同一の「UPV2」、即ち、同一ユーザの白ワインについてのUPVとされているとする。また、「UPV３」は、同一ユーザのスパークリングワインについてのUPVとされているとする。

第２列目と第３列目とのそれぞれには、短期間と長期間のそれぞれについての、各UPVの「積算ポイント」が記述される。

第４列目乃至第６列目のそれぞれには、各UPVから「UPV1への遷移確率」、各UPVから「UPV2への遷移確率」、各UPVから「UPV3への遷移確率」のそれぞれが記述される。具体的には例えば、「UPV２」に対応する第３行目に着目すると、「UPV２」から「UPV1への遷移確率」は「0.01」であり、「UPV２」から「UPV2への遷移確率」は「0.24」であり、「UPV２」から「UPV3への遷移確率」は「0.45」である。従って、「UPV２」から「UPV3への遷移確率」が最も高いことから、このユーザの操作傾向としては、白ワインについての操作（購入操作等）後、スパークリングワインについての操作（購入操作）を行うことが多いことがわかる。

以上、図２乃至図４を参照して、UPV管理表のそれぞれの具体例について説明した。

図１に戻り、アイテム特徴ベクトル記憶部１３には、１以上のアイテム（本実施の形態ではワイン）のそれぞれについてのアイテム特徴ベクトルが記憶されている。

推薦リスト生成部１４は、UPV選択部４１、推薦選択部４２、および、表示配分決定部４３を含むように構成されている。

UPV選択部４１は、アプリケーションサーバ２の推薦取得部２から推薦リクエストを受け取ると、推薦ワインの呈示先であるユーザの各UPV（各性質毎のUPV）の中から、推薦対象の性質についてのUPVを、UPV/UPV管理表記憶部１２から選択して取得する。なお、推薦対象の性質の決定手法は、特に限定されないが、ここでは、例えば、推薦リクエストの内容や現在の状況（ユーザの操作状況や、ユーザに呈示されているサイトのページ等）に基づいて、推薦対象の性質を決定する手法が採用されているとする。

推薦選択部４２は、UPV選択部４１により選択された推薦対象の性質についてのUPVと、アイテム特徴ベクトル記憶部１３に記憶された複数のアイテム特徴ベクトルのうちの推薦対象の性質を有するものとの類似度をそれぞれ求める。次に、推薦選択部４２は、それらの類似度に基づいて、対応するアイテムの推薦度を演算する。推薦度の演算手法は、特に限定されないが、ここでは説明の簡略上、類似度がそのまま推薦度となるとする。次に、推薦選択部４２は、例えば、推薦度が閾値以上のアイテム特徴ベクトルが示す１以上のアイテムを、推薦対象の性質を有する推薦アイテムとして決定する。

換言すると、推薦リスト生成部１４は、推薦対象の性質についてのUPVを使用して、推薦対象の性質を有するアイテムの中からユーザにとって適切なアイテムを推薦する機能を有している。この機能を実現するために、推薦リスト生成部１４には、UPV選択部４１と推薦選択部４２とが設けられているのである。

さらに、推薦リスト生成部１４は、推薦アイテムの各性質毎の呈示の比率を決定する機能を有している。この機能を実現するために、推薦リスト生成部１４にはさらに、表示配分決定部４３が設けられているのである。

即ち、表示配分決定部４３は、UPV/UPV管理表記憶部１２に記憶されているUPV管理表を参照して、推薦対象の１以上の性質毎にそれぞれ呈示の比率を演算（決定）する。

すると、推薦選択部４２は、推薦対象の１以上の性質毎にそれぞれ、表示配分決定部４３により決定された呈示の比率に基づく個数（この個数は、各性質毎に異なることが多い）の推薦アイテムを選抜し、選抜された各性質毎のアイテムのそれぞれを含むリスト（以下、推薦リスト）を生成し、アプリケーションサーバ２の推薦取得部２３に供給する。

なお、実際には、推薦リストとは、１以上の推薦アイテムのそれぞれを特定可能な情報を、例えば推薦度の高い順にソートしたリストのことをいう。推薦アイテムを特定可能な情報とは、例えば本実施の形態のようにアイテムがワインである場合には、個々のワインに固有の識別子（ID）、あるいはワインの名称、産地、生産者（ドメーヌやワイナリー）等をいう。また、推薦リストの中に、その他の情報、例えば、ワインの価格や、そのワインの推薦理由等を含ませることも当然ながら可能である。

ところで、表示配分決定部４３による呈示の比率の演算手法は、特に限定されないが、上述したように、参照先のUPV管理表を利用可能な演算手法である必要がある。そこで、以下、上述した図２乃至図４のそれぞれの例のUPV管理表を利用する、呈示の比率の演算手法の一例について説明していく。

はじめに、図２の例のUPV管理表を利用可能な呈示の比率の演算手法の一例について説明する。

即ち、推薦の場面（ページ等）に応じて、対象期間を決定し、換言すると、図２の例のUPV管理表のうちの対象列を決定し、当該期間中の期間合計回数（決定した列の最終行である「各期間合計」の記述値）を、各UPVの更新（アクセス）回数（決定した列の、各UPVを示す行の記述値）で除算することで、各UPV毎の表示配分を決定するといった演算手法が、図２の例のUPV管理表を利用可能な呈示の比率の演算手法の一例である。なお、以下、係る手法を、他の手法と区別するために、第１の比率演算手法と称する。

具体的には例えばいま、図２の例のUPV管理表において、「期間１」が１セッションとされ、「期間１」中の赤ワインと白ワインとのそれぞれのアクセス頻度に応じて、配分比率が決定されるとする。この場合、赤ワインについての「UPV1」の「期間１」（１セッション）中の更新回数は「３回」とされ、「期間１」の「各期間合計」が４回とされているので、赤ワインの呈示の比率（配分比）は、3/4になる。同様に、白ワインについての「UPV２」の「期間１」（１セッション）中の更新回数は「１回」とされ、「期間１」の「各期間合計」が「４回」とされているので、白ワインの呈示の比率（配分比）は、1/4になる。従って、推薦ワインとして４本のワインをユーザに呈示できるとすると、赤ワイン3本と白ワイン1本とが推薦ワインとしてユーザに呈示されることになる。

次に、図３の例のUPV管理表を利用可能な呈示の比率の演算手法の一例について説明する。

即ち、ユーザの各ページへのアクセスの状況に応じて、各UPV毎の表示配分を決定するといった演算手法が、図３の例のUPV管理表を利用可能な呈示の比率の演算手法の一例である。換言すると、図３の例のUPV管理表において、各UPVの「積算ポイント」を、「積算ポイント」の「合計」で除算することで、各UPV毎の表示配分を決定するといった演算手法が、図３の例のUPV管理表を利用可能な呈示の比率の演算手法の一例である。なお、以下、係る手法を、他の手法と区別するために、第２の比率演算手法と称する。

具体的には例えばいま、図３の例のUPV管理表において、赤ワインについての「UPV1」の「積算ポイント」は「４４」とされ、「積算ポイント」の「合計」が「８０」とされているので、赤ワインの呈示の比率（配分比）は44/80＝約0.6になる。同様に、白ワインについての「UPV２」の「積算ポイント」は「１８」とされ、「積算ポイント」の「合計」が「８０」とされているので、白ワインの呈示の比率（配分比）は、18/80＝約0.2になる。従って、推薦ワインとして１０本のワインをユーザに呈示できるとすると、赤ワイン６本、白ワイン２本、その他のワイン（スパークリングワイン等）２本が推薦ワインとしてユーザに呈示されることになる。

さらに、図２の例のUPV管理表と図３の例のUPV管理表とを組み合わせて、各期間毎に「積算ポイント」を蓄積した結果を記述するUPV管理表を生成し、それを採用することができる。即ち、上述した図４の例の第２列目と第３列目のような情報を有するUPV管理表を採用することもできる。このようなUPV管理表が採用されている場合には、各期毎に蓄積した「積算ポイント」を用いて、場面にあった推薦比率を決定する、という手法を採用することもできる。例えば、サイトのトップページでは、全期間の「積算ポイント」を使って推薦比率を決定し、決済ページやバスケット（買い物籠）の内容確認ページといった下位のページでは短期（１セッションまたは一日）の「積算ポイント」を使って推薦比率を決定する、という手法を採用することもできる。なお、以下、係る手法を、他の手法と区別するために、第３の比率演算手法と称する。

次に、図４の例のUPV管理表を利用可能な呈示の比率の演算手法の一例について説明する。

即ち、各遷移確率に基づいてユーザの次の操作を推測し、その推測結果に基づいて各UPV毎の表示配分を決定するといった演算手法が、図４の例のUPV管理表を利用可能な呈示の比率の演算手法の一例である。なお、以下、係る手法を、他の手法と区別するために、第４の比率演算手法と称する。

具体的には例えば、図４の例のUPV管理表では、白ワインについての「UPV２」から、スパークリングワインについての「UPV3への遷移確率」が「0.45」と最も高いので、このユーザの操作傾向は、白ワインの購入操作後に、スパークリングワインの購入操作をすることが最も多いことになる。そこで、図１の表示配分決定部４３は、この第４の比率演算手法を適用することで、例えば所定の白ワインについての購入決定キーの押下操作が行われた場合、その後に、例えばスパークリングワインの配分比が高くなるように、各種類（赤ワイン、白ワイン、およびスパークリングワイン）の呈示の比率を変更することが可能になる。

また例えば、図４の例のUPV管理表では、スパークリングワインについての「UPV３」から、白ワインについての「UPV2への遷移確率」も「0.32」と他に比べて比較的高いので、このユーザは、結局、１セッション等の所定の期間で見ると、白ワインとスパークリングワインとを同時に購入していることが多い（そのような操作をしていることが多い）と言える。そこで、表示配分決定部４３は、この第４の比率演算手法を適用することで、例えば所定のスパークリングワインをバスケット（買い物籠）に入れる操作がなされた時点で、例えば白ワインの配分比が高くなるように、各種類の呈示の比率を変更することも可能になる。

なお、遷移確率は、上述した例では、呈示の比率を算出するために利用されたが、次の推薦処理の対象となるUPVを決定するために利用することも可能である。具体的には例えば、所定の白ワインについての購入決定キーの押下操作が行われた後に、図１のUPV選択部４１は、例えばスパークリングワインについての「UPV３」を選択することが可能になる。同様に例えば、所定のスパークリングワインをバスケット（買い物籠）に入れる操作がなされた時点で、UPV選択部４１は、白ワインを示す「UPV２」を選択することが可能になる。

その他、例えば、月ごとに、UPVの利用頻度を蓄積したUPV管理表を採用することで、季節による推薦内容の変化を演出するように呈示の比率を決定する、という手法を採用することもできる。例えば、12月（クリスマス）においては、スパークリングワインの「UPV３」の利用頻度が高いことがそのUPV管理表から判断できたとすると、１２月のワイン推薦においては、スパークリングワインがより多く推薦されるように各種類（赤ワイン、白ワイン、および、スパークリングワイン）の呈示の比率を変更する、といった手法を採用することもできる。なお、以下、係る手法を、他の手法と区別するために、第５の比率演算手法と称する。

ところで、図１の操作履歴管理部１１は、アイテムの各性質毎のユーザの操作履歴を、例えば本実施の形態ではUPVという形態で管理しているとしたが、その管理形態は本実施の形態に特に限定されない。例えば、操作履歴管理部１１は、操作履歴情報のまま管理し、即ち、操作履歴情報をUPV/UPV管理表記憶部１２に記憶させ、必要なときに必要な操作履歴情報だけを利用してUPVを生成することも可能である。これにより、例えば、操作履歴管理部１１は、短期と長期とに分けて別々に操作履歴情報をUPV/UPV管理表記憶部１２に蓄積して管理することが可能になり、その結果、短期の操作履歴情報だけに基づくUPV（以下、短期UPVと称する）、および、長期の操作履歴情報だけに基づくUPV（以下、長期UPVと称する）のそれぞれを個別に生成することが可能になる。この場合、推薦リスト生成部１４は、この短期UPVと長期UPVとを併用することで、現状況により相応しい推薦アイテムを決定することが容易にできる。

具体的には例えば、バスケット（買い物籠）のページでは、操作履歴管理部１１は、1セッション中のユーザの操作履歴情報だけを使用して、アイテムの各性質毎のUPV（例えば、赤ワイン、白ワイン、およびスパークリングワインのそれぞれについてのUPV）を生成し、推薦リスト生成部１４は、それらの各性質毎のUPVを用いて、各性質毎のアイテムのそれぞれを推薦アイテムとして決定することができる。そして、推薦リスト生成部１４は、対象となるセッション中の各性質毎のUPVへのアクセス頻度（または状況）から各性質毎の呈示の比率を決定することができる。

また例えば、サイトのトップページでは、操作履歴管理部１１は、そのユーザの過去の操作履歴情報の全てを使用して、アイテムの各性質毎のUPVを生成し、推薦リスト生成部１４は、それらの各性質毎のUPVを用いて、各性質毎のアイテムのそれぞれを推薦アイテムとして決定することができる。そして、推薦リスト生成部１４は、過去の全期間にわたる各性質毎のUPVへのアクセス頻度（または状況）から各性質毎の呈示の比率を決定することができる。

また例えば、購入後のページでは、推薦リスト生成部１４は、過去の操作履歴情報の全てから生成されたUPVを利用して推薦アイテムを再度決定し、対象となるセッション中の各性質毎のUPVへのアクセス頻度（または状況）から各性質毎の呈示の比率を決定することができる。その結果、推薦リスト生成部１４は、過去の購入内容とその日の購入配分とを加味した上で、追加注文の可能性を拡大させるようなアイテムを、推薦アイテムとして決定することができる。

以上、図１の推薦システムのうちの、推薦サーバ１の機能的構成例について説明した。次に、アプリケーションサーバ２と、ユーザ機器３とのそれぞれの機能的構成例について説明する。

アプリケーションサーバ２は、操作履歴取得部２１乃至表示内容生成部２４を含むように構成されている。

操作履歴取得部２１は、ユーザ機器３の操作部３１の操作内容をネットワーク４を介して取得し、推薦サーバ１に供給する。

サービス提供部２２は、各種サービスを表示内容生成部２４に提供する。具体的には例えば、上述したアイテムの提供（販売等）を行うためのサイトが、サービス提供部２２が提供するサービスの一例である。

推薦取得部２３は、アイテムの推薦の処理に利用される操作部３１の操作内容や、アイテムの推薦リクエスト等を推薦サーバ１の推薦リスト生成部１４に供給する。また、推薦取得部２３は、その推薦リクエストを受けた推薦リスト生成部１４により生成された推薦リストを取得して、表示内容生成部２４に供給する。

表示内容生成部２４は、ユーザ機器３２の表示部３２の表示内容となる画像（データ）を生成し、ユーザ機器３の表示部３２にネットワーク４を介して提供する。ユーザ機器３２の表示部３２の表示内容となる画像（データ）とは、例えば、サービス提供部２２から提供されるサイトの画像や、推薦取得部２３から供給される推薦リストの画像のことをいう。

ユーザ機器３は、操作部３１と表示部３２とを少なくとも含むように構成される。

即ち、ユーザは、表示部３２に表示される表示内容（アイテムの販売サイトや、アイテムの推薦リスト）を見ながら、操作部３１を操作して各種操作を行う。なお、ユーザの操作については、幾つかの具体例を既に上述しているので、ここでは省略する。

次に、図５のフローチャートを参照して、図１の推薦システムのうちの推薦サーバ１の処理の一例について説明する。

ステップＳ１において、推薦サーバ１の操作履歴管理部１１は、ユーザの操作がなされたか否かを判定する。

アプリケーションサーバ２の操作履歴取得部２１から特に何の情報も供給されてこない場合、ステップＳ１において、ユーザの操作がなされていないと判定されて、処理はステップＳ３に進む。

これに対して、アプリケーションサーバ２の操作履歴取得部２１から所定のユーザについての操作履歴情報（操作内容）が供給されてきた場合、操作履歴管理部１１は、ステップＳ１において、ユーザの操作がなされたと判定して、ステップＳ２において、UPV/UPV管理表記憶部１２に記憶されている対象ユーザのUPVおよびUPV管理表の生成または更新を行う。これにより、処理はステップＳ３に進む。

なお、上述したように、操作履歴管理部１１は、ステップＳ２の処理の時点では、UPVの生成または更新を行わずに、アプリケーションサーバ２から供給された操作履歴情報をそのままUPV/UPV管理表記憶部１２に記憶して管理し、後述するステップＳ３の処理で推薦リクエストがなされたと判定された時点で、その操作履歴情報を利用してUPVの生成または更新を行ってもよい。

ステップＳ３において、推薦サーバ１の推薦リスト生成部１４は、アプリケーションサーバ２の推薦取得部２３から推薦リクエストがなされたか否かを判定する。

ステップＳ３において、推薦リクエストがなされていないと判定された場合、ステップＳ４の処理は実行されずに、処理はステップＳ５に進む。

これに対して、ステップＳ３において、推薦リクエストがなされたと判定された場合、処理はステップＳ４に進む。ステップＳ４において、推薦リスト生成部１４は、上述した推薦リストを生成して、アプリケーションサーバ２の推薦取得部２３に供給する。係るステップＳ４の処理を、以下、「推薦リスト生成処理」と称する。「推薦リスト生成処理」の詳細については、図６のフローチャートを参照して後述する。

ステップＳ４の「推薦リスト生成処理」が終了すると、処理はステップＳ５に進む。ステップＳ５において、推薦サーバ１は、処理の終了が指示されたか否かを判定する。

ステップＳ５において、処理の終了が指示されたと判定された場合、推薦サーバ１の処理は終了となる。

これに対して、処理の終了がまだ指示されていないと判定された場合、処理はステップＳ１に戻され、それ以降の処理が繰り返し実行される。

なお、図５の処理例では、ステップＳ４の「推薦リスト生成処理」が行われている最中に、ユーザの操作が行われた場合には、ステップＳ２の処理、即ち、UPVおよびUPV管理表の生成または更新の処理は行われない。ただし、上述したように、操作履歴管理部１１と推薦リスト生成部１４とのそれぞれは、相互に独立して処理を実行することが可能である。即ち、実際には、ステップＳ１とＳ２との処理、および、ステップＳ３とＳ４との処理は、相互に独立して並列実行される。

ここで、図６のフローチャートを参照して、ステップＳ４の「推薦リスト生成処理」の詳細例について説明する。

ステップＳ２１において、図１の推薦リスト生成部１４のUPV選択部４１は、対象ユーザのUPVを１以上選択する。

詳細には、ステップＳ２１において、UPV選択部４１は、推薦リクエストを分析することで推薦対象の性質を決定して、推薦対象の性質についてのUPVを、UPV/UPV管理表記憶部１２から選択して取得し、推薦選択部４２に供給する。なお、その際、UPV選択部４１は、上述した短期履歴情報や長期履歴情報を考慮したUPVの選択を行うことも当然ながらできる。

ステップＳ２２において、推薦選択部４２は、選択されたUPV毎に、推薦アイテムを決定する。即ち、ステップＳ２２の処理で、推薦対象の性質毎に、１以上の推薦アイテムがそれぞれ個別に決定される。

ステップＳ２３において、表示配分決定部４３は、UPV/UPV管理表記憶部１２に記憶されている対象ユーザのUPV管理表を参照して、推薦対象の性質毎に、呈示の比率（配分比）をそれぞれ決定する。

ステップＳ２４において、推薦選択部４２は、UPV毎（推薦対象の性質毎）に、推薦リストに含める推薦アイテムをそれぞれ個別に決定する。即ち、ステップＳ２４の処理で、推薦対象の性質毎に、ステップＳ２３の処理で決定された呈示の比率（配分比）に基づく個数（この個数は、各性質毎に異なることが多い）の推薦アイテムがそれぞれ個別に決定されることになる。

ステップＳ２５において、推薦選択部４２は、ステップＳ２４の処理で決定された各性質毎の推薦アイテムのそれぞれを、おすすめ度（即ち、推薦度であり、ここでは類似度そのもの）順にソートすることで、推薦リストを生成する。

ステップＳ２６において、推薦選択部４２は、推薦リストを、アプリケーションサーバ２の推薦取得部２３に送信する。

これにより、「推薦リスト生成処理」は終了となる。即ち、図５のステップＳ４の処理が終了し、処理はステップＳ５に進むことになる。

以上、推薦サーバ１の処理の一例について説明した。

ところで、上述した一連の処理は、ハードウエアにより実行させることもできるが、ソフトウエアにより実行させることができる。

この場合、図１の推薦システムの推薦サーバ１、アプリケーションサーバ２、ユーザ機器３のそれぞれは、例えば、図７に示されるパーソナルコンピュータで構成することができる。

図７において、CPU（Central Processing Unit）１０１は、ROM（Read Only Memory）１０２に記録されているプログラム、または記憶部１０８からRAM（Random Access Memory）１０３にロードされたプログラムに従って各種の処理を実行する。RAM１０３にはまた、CPU１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。

CPU１０１、ROM１０２、およびRAM１０３は、バス１０４を介して相互に接続されている。このバス１０４にはまた、入出力インタフェース１０５も接続されている。

入出力インタフェース１０５には、キーボード、マウスなどよりなる入力部１０６、ディスプレイなどよりなる出力部１０７、ハードディスクなどより構成される記憶部１０８、および、モデム、ターミナルアダプタなどより構成される通信部１０９が接続されている。通信部１０９は、インターネットを含むネットワークを介して他の装置（図示せず）との間で行う通信を制御する。

入出力インタフェース１０５にはまた、必要に応じてドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどよりなるリムーバブル記録媒体１１１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１０８にインストールされる。

一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。

このようなプログラムを含む記録媒体は、図７に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク（フロッピディスクを含む）、光ディスク（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリなどよりなるリムーバブル記録媒体（パッケージメディア）１１１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM１０２や、記憶部１０８に含まれるハードディスクなどで構成される。

なお、アイテムの性質は、上述した例では、赤ワイン、白ワイン、および、スパークリングワインといった３種類の性質が利用されたが、当然ながら、この例に限定されず、２種類以上にアイテムを分類可能である各種性質を利用することができる。即ち、任意の性質のUPVを採用することができる。具体的には例えば、アイテムがワインである場合、価格帯別のUPV（例えば、1万円未満のUPVと１万円以上のUPV等）、葡萄の品種別のUPV（例えば、カベルネソービニヨン種のUPV、メルロ種のUPV、ピノノワール種のUPV等）、産地別のUPV（例えば、フランスワインであれば、ボルドー地方のUPV、ブルゴーニュ地方のUPV、ロワール地方のUPV、コートデュローヌ地方のUPV、シャンパーニュ地方のUPV等、各地方毎のUPV）、生産者別のUPV（例えば、ブルゴーニュワインであれば、ドメーヌやメゾン毎のUPVであり、カリフォルニアワイン等であれば、ワイナリー毎のUPVである）、年代別のUPV（例えば、古酒のUPVとそれ以外のUPV等）、および、甘さ度別のUPV（例えばドイツワインであれば、シュぺトレーゼのUPV、アウスレーゼのUPV等、ドイツのワイン法で規定されている各種類毎のUPV）、といった様々な性質のUPVを採用することが可能である。

ただし、これらの様々な性質のUPVの全てを利用するのではなく、上述したように、ユーザの嗜好傾向の違いを考慮した性質のUPVを利用するとよい。即ち、各性質毎のUPVの間に明らかな差（違い）ができるような、各性質のUPVを利用するとよい。この場合、その差を計る尺度としては、統計的な優位差、情報工学的な情報量（エントロピー）などを利用することができる。これらの尺度は、例えば、事前に実験によって得たデータや実際のサービスより得たデータなどから、複数ユーザのデータを抽出して計算することで得られる。従って、設計者等は、事前にこれらの尺度を求めておき、明らかな差が期待できる各性質のUPVを採用するとよい。

さらに、所定の性質を階層化して、各階層毎のそれぞれに属する種類毎にUPVを生成して、それらのUPVを使用することも可能である。具体的には例えば、産地別のUPVであれば、フランスワインの場合、フランスのワイン法であるA.C（Appellation Controlee）法(即ち、原産地統制名称法）で規定されているA.O.C（Appellation d'Origine Controlee）に則った階層、即ち、第１層として地方レベルを定義し、第２層として地区レベルを定義し、かつ、第３層として村レベルを定義し、第１層乃至第３層のそれぞれについて、複数種類のUPVを生成して、使用することが可能である。

即ち、例えば、第１層のUPVとしては、上述したボルドー地方のUPV等を生成して、使用することが可能である。また例えば、ボルドー地方についての第２層のUPVとしては、メドック地区のUPV、グラーブ（ぺサックレオニャン）地区のUPV、サンテミリオン地区のUPV、ポムロル地区のUPV、ソーテルヌ地区のUPV、およびその他のUPVのそれぞれを生成して、使用することが可能である。さらに例えば、メドック地区についての第３層のUPVとしては、サンテステフ村のUPV、ポイヤック村のUPV、サンジュリアン村のUPV、マルゴー村のUPV、および、その他のUPVのそれぞれを生成して、使用することが可能である。

なお、階層化する場合も、各性質毎のUPVの間に明らかな差（違い）ができる階層までのUPVを利用するとよい。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

また、本明細書において、システムとは、複数の装置や処理部により構成される装置全体を表すものである。

本発明が適用される情報処理システムまたは装置の機能的構成例を示すブロック図である。 UPV管理表の一例を示す図である。 UPV管理表の一例を示す図である。 UPV管理表の一例を示す図である。 図１のサーバの処理の例を説明するフローチャートである。 図５のステップＳ４の「推薦リクエスト生成処理」の詳細例を説明するフローチャートである。 図１の情報処理装置のハードウエア的構成例を示す図である。

符号の説明

１ 推薦サーバ， ２ アプリケーションサーバ， ３ ユーザ機器， ４ ネットワーク， １１ 操作履歴管理部， １２ UPV/UPV管理表記憶部， １３ アイテム特徴ベクトル記憶部， １４ 推薦リスト生成部， ４１ UPV選択部， ４２ 推薦選択部， ４３ 表示配分決定部， １０１ CPU， １０２ ROM， １０３ RAM， １０８ 記憶部， １１１ リムーバブル記録媒体

Claims (4)

1. 複数のアイテムを販売するためのウェブページに対するユーザの操作履歴を取得して、アイテムの種別毎に、前記ウェブページにおける、所定の種別のアイテムが属するカテゴリのページへの第１のアクセス数、前記所定の種別のアイテムのページへの第２のアクセス数、および前記所定の種別のアイテムの購入操作に伴うアクセスの回数である第３のアクセス数と、前記所定の種別の前記第１のアクセス数乃至前記第３のアクセス数を重み付き加算して得られる積算ポイントとを示す操作履歴管理情報を生成し、前記操作履歴管理情報を記憶する記憶手段と、
   アイテムの種別毎に、前記ユーザの前記操作履歴を用いて、前記種別のアイテムに関する前記ユーザの嗜好傾向を示すユーザ嗜好ベクトルを生成する嗜好ベクトル生成手段と、
   複数の種別の中から推薦対象の複数の種別が指定された場合、全ての前記推薦対象の種別の前記積算ポイントの和と、前記推薦対象の種別の前記積算ポイントとの比を求めることで、前記ユーザに対する前記推薦対象の種別毎のアイテムの呈示の配分比を決定する配分比決定手段と、
   前記推薦対象の種別が指定された場合、前記推薦対象の種別毎に、前記種別の前記ユーザ嗜好ベクトルと、前記推薦対象の種別のアイテムの特徴を示す特徴ベクトルとの類似度を余弦相関により演算し、演算された類似度が閾値以上である前記特徴ベクトルに対応するアイテムのうちの、前記推薦対象の種別の前記配分比により定まる数のアイテムを、前記ユーザに推薦すべき推薦アイテムとして決定する推薦手段と
   を備えることを特徴とする情報処理装置。
2. 前記推薦アイテムを示す情報が、前記推薦アイテムの前記類似度の高い順に並べられた推薦リストを生成する推薦リスト生成手段をさらに備える
   ことを特徴とする請求項１に記載の情報処理装置。
3. 記憶手段が、複数のアイテムを販売するためのウェブページに対するユーザの操作履歴を取得して、アイテムの種別毎に、前記ウェブページにおける、所定の種別のアイテムが属するカテゴリのページへの第１のアクセス数、前記所定の種別のアイテムのページへの第２のアクセス数、および前記所定の種別のアイテムの購入操作に伴うアクセスの回数である第３のアクセス数と、前記所定の種別の前記第１のアクセス数乃至前記第３のアクセス数を重み付き加算して得られる積算ポイントとを示す操作履歴管理情報を生成し、前記操作履歴管理情報を記憶する記憶ステップと、
   嗜好ベクトル生成手段が、アイテムの種別毎に、前記ユーザの前記操作履歴を用いて、前記種別のアイテムに関する前記ユーザの嗜好傾向を示すユーザ嗜好ベクトルを生成する嗜好ベクトル生成ステップと、
   配分比決定手段が、複数の種別の中から推薦対象の複数の種別が指定された場合、全ての前記推薦対象の種別の前記積算ポイントの和と、前記推薦対象の種別の前記積算ポイントとの比を求めることで、前記ユーザに対する前記推薦対象の種別毎のアイテムの呈示の配分比を決定する配分比決定ステップと、
   推薦手段が、前記推薦対象の種別が指定された場合、前記推薦対象の種別毎に、前記種別の前記ユーザ嗜好ベクトルと、前記推薦対象の種別のアイテムの特徴を示す特徴ベクトルとの類似度を余弦相関により演算し、演算された類似度が閾値以上である前記特徴ベクトルに対応するアイテムのうちの、前記推薦対象の種別の前記配分比により定まる数のアイテムを、前記ユーザに推薦すべき推薦アイテムとして決定する推薦ステップと
   を含むことを特徴とする情報処理方法。
4. 記憶制御手段が、複数のアイテムを販売するためのウェブページに対するユーザの操作履歴を取得して、アイテムの種別毎に、前記ウェブページにおける、所定の種別のアイテムが属するカテゴリのページへの第１のアクセス数、前記所定の種別のアイテムのページへの第２のアクセス数、および前記所定の種別のアイテムの購入操作に伴うアクセスの回数である第３のアクセス数と、前記所定の種別の前記第１のアクセス数乃至前記第３のアクセス数を重み付き加算して得られる積算ポイントとを示す操作履歴管理情報を生成し、前記操作履歴管理情報の記憶を制御する記憶制御ステップと、
   嗜好ベクトル生成手段が、アイテムの種別毎に、前記ユーザの前記操作履歴を用いて、前記種別のアイテムに関する前記ユーザの嗜好傾向を示すユーザ嗜好ベクトルを生成する嗜好ベクトル生成ステップと、
   配分比決定手段が、複数の種別の中から推薦対象の複数の種別が指定された場合、全ての前記推薦対象の種別の前記積算ポイントの和と、前記推薦対象の種別の前記積算ポイントとの比を求めることで、前記ユーザに対する前記推薦対象の種別毎のアイテムの呈示の配分比を決定する配分比決定ステップと、
   推薦手段が、前記推薦対象の種別が指定された場合、前記推薦対象の種別毎に、前記種別の前記ユーザ嗜好ベクトルと、前記推薦対象の種別のアイテムの特徴を示す特徴ベクトルとの類似度を余弦相関により演算し、演算された類似度が閾値以上である前記特徴ベクトルに対応するアイテムのうちの、前記推薦対象の種別の前記配分比により定まる数のアイテムを、前記ユーザに推薦すべき推薦アイテムとして決定する推薦ステップと
   を含む処理をコンピュータに実行させることを特徴とするプログラム。

Images