本発明の一実施の形態であるネットワークシステムについて図面を参照して説明する。以下では、まずシステム全体構成を説明し、その後、第1実施例〜第3実施例の順番で各構成の具体例および具体的動作例について説明する。
<システム全体構成>
図1は、本実施形態に係るネットワークシステム全体の構成を示すブロック図である。本図に示すように、ネットワークシステムは、アイテム等の情報を選択する情報選択装置10と、アイテム提供サーバ20と、1台以上の端末装置30(図中では30A〜30N、本実施形態では「端末装置30」と総称する)がネットワーク40を介して接続されて構成される。ここで、情報選択装置10とアイテム提供サーバ20により、端末装置30を使用するユーザに対してアイテム提供等のサービスを行なうアイテム提供システム1を構成している。ネットワーク40は、インターネットに代表される広域ネットワークとすることができる。また、端末装置30とネットワーク40との接続形態は、有線・無線を問わない。
ネットワークシステムは、図2に示すような構成としてもよい。すなわち、ネットワーク40にアイテム提供サーバ20と1台以上の端末装置30(30A〜30N)が接続され、情報選択装置10がネットワーク40とは別のネットワーク42を介してアイテム提供サーバ20と接続している構成である。この場合、ネットワーク42を介して接続された情報選択装置10とアイテム提供サーバ20により、アイテム提供システム2を構成する。ネットワーク42は、例えば、LAN(Local
Area Network)等とすることができ、セキュリティ確保の観点から、端末装置30から情報選択装置10への直接的なアクセスは制限することが望ましい。
ただし、ネットワークシステムは、上記の例に限られず、種々の構成を用いることができる。例えば、情報選択装置10とアイテム提供サーバ20とを同一の装置で構成してもよいし、それぞれを複数台の装置で構成するようにしてもよい。以下では、図1に示した構成でネットワークシステムを実現した場合を例に説明する。
本実施形態におけるアイテムは、ユーザに対して提供対象となるものであり、テキスト、音声、音楽、画像、映像、プログラム等のデジタルコンテンツ、様々な物品、金融商品、不動産、人物情報、ネットワークサービス等を含めることができ、有形か無形かを問わない。また、本実施形態では、各アイテムには、アイテムを分類するための情報であるカテゴリが1つ以上定められているものとするが、カテゴリを用いないで動作することも可能である。
本実施形態におけるアイテム提供サービスでは、少なくとも、単体アイテムと複合アイテムの2種類(2つの種別)のアイテムが提供される。ここで、複合アイテムとは、複数の単体アイテムを含むものであり、ユーザの1回の利用操作(購入操作)で、対応する複数の単体アイテムに相当する内容が提供されるものである。例えば、音楽コンテンツが提供されるサービスにおいては、個々の楽曲を単体アイテムとし、複数の楽曲を集めたアルバムを複合アイテムとすることができる。また、あるアーティストのすべての楽曲を1つの複合アイテムとしてもよい。また映像コンテンツが提供されるサービスでは、連続ドラマの各話を単体アイテムとし、それを複数まとめたものを複合アイテムとすることができる。また、書籍(紙の書籍でも電子書籍でもよい)が提供されるサービスでは、1巻を単体アイテムとし、関連のある巻をまとめて複合アイテムとすることができる。
ある複合アイテムに対応する複数の単体アイテムを利用する意向のあるユーザにとっては、それぞれの単体アイテムの利用操作を複数回繰り返すよりは、その複合アイテムを1回の利用操作で利用した方が、時間や手間の節約になり、ユーザにとっての利便性が高い。また、複合アイテムは、複数の単体アイテムを合わせた要素以外の要素を含んでいてもよい。例えば、音楽コンテンツの場合、複合アイテムであるアルバムコンテンツは、単体アイテムである個々の楽曲を複数含む他に、単体アイテムには含まれない、ジャケット写真、ライナーノーツ(アルバムの解説)、歌詞カード、ボーナストラック、イベント参加権利、及びその他の特典を含んでいてもよい。
本実施形態に係るアイテム提供サービスにおいて、アイテムは基本的に有料であるが、無料のアイテムが存在してもよい。一般的には、複合アイテムの価格の方が、単体アイテムの価格よりも高い傾向にある。すなわち、単体アイテムに比べて、相対的に複合アイテムの価格は高いといえる。ただし、単体アイテムよりも価格の安い複合アイテムや、無料の複合アイテムが存在してもよい。また一般的には、複合アイテムの価格は、それに対応する全ての単体アイテムの価格の合計よりも安く設定されることが多いが、必ずしも安くなくてもよい。例えば、対応する単体アイテムの合計額と同じでもよいし、複合アイテム独自の特典があるなどの理由により、対応する単体アイテムの合計額より高い価格であってもよい。
また、アイテム提供の都度、ユーザに対する課金を行ってもよいが、所定の期間ごとに所定金額を課金してもよい。例えば、毎月の所定日(毎月1日、入会日など)に月会費として1000円を徴収し、その月(またはそれ以降の1ヶ月間)に合計1000円(1000ポイント)相当のアイテムを自由に組合せて利用できるようにしてもよい。ユーザがその月に1000円を超えてアイテムを利用したい場合は、追加ポイント(例えば、500円分、1000円分、2000円分など)を購入して、追加ポイントに相当する金額までのアイテムを利用できるようにすればよい。また追加ポイントをユーザに購入させることなく、月会費を越えた分のアイテムに関して、個別に課金を行ってもよい。また、月会費の徴収は、ユーザが会員である限り、自動的に継続するようにしてもよい。また、月会費に相当するポイントをその月に使い切らなかった場合、翌月には繰り越せない(翌月には失効する)ようにしてもよいし、余ったポイントを翌月以降に繰り越して使えるようにしてもよい。また、繰り越しを認める場合、最大6ヶ月後まで繰り越し可などのように、期限を設けてもよい。また、月会費制だけではなく、週単位、年単位、3ヶ月毎など、任意の期間(任意の周期)ごとに会費を徴収し、その対価として一定金額までのアイテムを利用させるようにしてもよい。
以下、上記構成のネットワークシステムについての実施例を説明する。各実施例について同じブロックについては同じ符号を付すものとし、同じブロックで動作が異なる場合は、第2実施例について「b」、第3実施例について「c」を符号の末尾に付加して説明する。
(実施例1)
<情報選択装置>
図3は、第1実施例における情報選択装置10の構成を示すブロック図である。本図に示すように情報選択装置10は、アイテム属性格納部101と、利用履歴格納部102と、関連度算出部104と、関連集合格納部105と、種別影響度算出部106と、情報選択部107と、推薦情報格納部108と、送受信部109と、制御部110とを備えて構成されている。また、情報選択装置10には、情報選択装置10の管理者向けに必要な情報を表示するための表示装置120と、管理者が操作を行なうためのキーボード、マウス等の入力装置130とが接続されている。
情報選択装置10は、CPU、RAM、ROM、HDD(ハードディスクドライブ)、ネットワークインタフェース等を備える一般的なコンピュータを用いて構成することができる。すなわち、一般的なコンピュータは、以下で説明するような処理を行なうためのコンピュータプログラムを実行することにより、情報選択装置10として機能することができるようになる。
また、上述のように、情報選択装置10を複数台のコンピュータを用いて構成してもよい。例えば、負荷分散をするために、情報選択装置10のある処理ブロックに相当するコンピュータを複数台用いて、すなわち、同じ処理ブロックを備える複数台のコンピュータを用いて分散処理を行なうようにしてもよい。また、情報選択装置10の一部の処理ブロックをあるコンピュータで実施し、他の処理ブロックを別のコンピュータで実施する形態で分散処理を行なってもよい。また、図3に示す処理ブロックを全て備えるコンピュータを複数台用いて分散処理を行ってもよい。
アイテム属性格納部101は、アイテムに関する情報が記録されたアイテム情報テーブル101Aと、カテゴリに関する情報が記録されたカテゴリ情報テーブル101Bとを格納している。
図4(a)は、アイテム情報テーブル101Aの一例を示している。本図に示すように、アイテム情報テーブル101Aは、アイテム識別子(アイテムID)と、アイテム属性情報とを対応させたテーブルである。アイテム属性情報は、アイテムの「種別情報」「タイトル(名称)」「カテゴリ識別子」「価格情報」「説明情報」「アイテム時期情報」などで構成されている。
ここで「種別情報」とは、上述の単体アイテム及び複合アイテムの少なくとも2つの種別のアイテムを、識別可能な情報である。本実施形態においては、複合アイテムの種別情報が、単体アイテムの種別よりも大きな値となるように、それぞれに数値を割り当てる例を用いて説明する。例えば、本図に示すように、単体アイテムを「0」、複合アイテムを「1」の数値に対応させればよい。また、単体アイテムを「1」、複合アイテムを「2」などのように、本図とは別の数値に対応させてもよい。ただし、本実施形態で説明する例とは逆に、複合アイテムの種別情報が、単体アイテムの種別情報よりも小さな値となるように設定することも、もちろん可能である。また例えば、単体アイテムを「単体」という文字列、複合アイテムを「複合」という文字列で表わす等、種別情報として文字列や記号を用いてもよい。また後述するように、種別情報を3値以上の数値で表わしてもよい。また、種別情報を3種類以上の文字列や記号で表わしてもよい。
「価格情報」は、そのアイテムの価格である。ただし、必ずしも円、ドル、ユーロといった実際の通貨に基づく価格である必要はない。例えば、本実施形態に係るアイテム提供サービスや、提携している関連サービスで使用できる独自のポイントの値であってもよい。なお、本図の例から分かるように、価格情報(価格)が「0円」である無料のアイテムが存在してもよい。一般的には、複合アイテムの価格が、単体アイテムの価格よりも高いが、ある単体アイテムの価格が、ある複合アイテムの価格より高くてもよい。
「カテゴリ識別子」は、そのアイテムに対応するカテゴリ(アイテムの属するカテゴリ)を識別する識別子であり、以下に説明するカテゴリ情報テーブル101Bにおいても、共通するカテゴリ識別子が格納されている。
図4(b)は、カテゴリ情報テーブル101Bの一例を示している。本図に示すように、カテゴリ情報テーブル101Bは、カテゴリ識別子(カテゴリID)とカテゴリ属性情報とを対応させたテーブルである。カテゴリ属性情報は、「カテゴリ名」「カテゴリ説明」などで構成されている。2つのテーブルに存在する「カテゴリ識別子」を介して、アイテム情報テーブル101Aのアイテム情報とカテゴリ情報テーブル101Bのカテゴリ情報とを関連付けることができる。
ここで、カテゴリとは、アイテムを所定の基準で分類した情報であり、1つのアイテムについて1個以上設定される。カテゴリは、例えば、アイテムの「クリエイター(作成者)」とすることができる。なお「クリエイター」は、アイテムの制作者、監督、プロデューサー、執筆者、作曲者、作詞者、演奏者、出演者等である。
また、アイテムが音楽コンテンツの場合、「ロック」「ジャズ」「クラシック」「フォーク」等のジャンル情報をカテゴリとすることができ、アイテムが映画の場合、「SF」「アクション」「コメディ」「アニメ」「サスペンス」等のジャンル情報をカテゴリとすることができる。さらには、「日本」「アメリカ」「イギリス」など作成者の国や地域を用いた分類情報や、「癒し系」「エキサイティング」「ドラマティック」といったアイテムの雰囲気やムードを示す情報をカテゴリとして用いてもよい。
アイテム属性情報の「説明情報」は、アイテムのあらすじや要約、制作された背景説明などの情報である。「アイテム時期情報」は、アイテムの作成された時期(時点)を示す情報である。ただし、アイテム提供サーバ20にアイテムが登録された時期や、アイテムが提供開始された時期を用いてもよい。本実施形態では、時期(時点)の表現形式として、「2010年1月1日」などの日付を用いるが、他の表現形式を用いてもよい。例えば、「2010年1月1日 10時15分20秒」などの秒単位までの日時でもよいし、ミリ秒単位までの日時でもよい。あるいは、「2010年1月」などの月単位の表現形式でも、「2010年 1Q」などの四半期単位の表現形式でも、「2010年」などの年単位の表現形式でも、「2000年代」などの年単位より大まかな年代の表現形式でもよい。
アイテム情報テーブル101Aのアイテム属性情報においては、1つのアイテムに同じ種類の属性項目が複数存在していてもよい。例えば、1つのアイテムに、「クリエイター1」「クリエイター2」「クリエイター3」「ジャンル1」「ジャンル2」の合計5つのカテゴリが設定されていてもよい。もちろん、ここで挙げたアイテム属性情報とカテゴリ属性情報は、あくまでも例示であり、上記に限定される訳ではない。例えば、アイテム属性情報に「サイズ」や「色」などの属性項目を用いてもよい。
図4(c)は、複合−単体対応テーブル101Cの一例を示している。複合−単体対応テーブル101Cは、複合アイテムと単体アイテムとの対応情報であり、複合アイテムのアイテム識別子と、単体アイテムのアイテム識別子とを対応させて格納する。本図の例では、複合アイテムである「ItemID−3」に、「ItemID−1」、「ItemID−2」、「ItemID−5」、「ItemID−6」の4つの単体アイテムが対応している。また、複合アイテムである「ItemID−4」に、「ItemID−2」、「ItemID−10」、「ItemID−11」の3つの単体アイテムが対応している。このように、1つの複合アイテムに対応する単体アイテムの数は、複合アイテムごとに異なっていてもよい。また、単体アイテムである「ItemID−2」が、「ItemID−3」と「ItemID−4」の2つ複合アイテムに対応していることから分かるように、1つの単体アイテムが、複数の複合アイテムに対応してもよい。
なお、複合アイテムに対応する単体アイテムの個数を種別情報としてもよい。例えば、図4(c)に示すような複合アイテムと単体アイテムの対応関係がある場合、図4(a)において、「ItemID−3」の種別情報を「4」、「ItemID−4」の種別情報を「3」にしてもよい。なお、単体アイテムの種別情報は「0」にすればよい。種別情報は典型的には、整数値で表わされるが、実数値で表わされてもよい。例えば、図4(c)に示す例において、単体アイテム「ItemID−2」は、「ItemID−3」と「ItemID−4」の2つの複合アイテムに対応している。このように、複数の複合アイテムに対応する単体アイテムが存在するとき、複合アイテムに対応する単体アイテムの個数をカウントする際に、それを「1」としてカウントするのではなく、より小さな値としてカウントしてもよい。例えば、「ItemID−2」を「0.5」としてカウントすると、「ItemID−3」の種別情報は「3.5」、「ItemID−4」の種別情報は「2.5」となる。
また、複合アイテムに対応する単体アイテムの個数に基づき、複合アイテムを複数のタイプに分類し、その分類情報を種別情報としてもよい。例えば、対応する単体アイテムの個数が5個未満の複合アイテムを「小規模複合アイテム」、対応する単体アイテムの個数が5個以上20個未満の複合アイテムを「中規模複合アイテム」、対応する単体アイテムの個数が20個以上の複合アイテムを「大規模複合アイテム」と分類し、その分類情報を種別情報としてもよい。「小規模複合アイテム」を「1」、「中規模複合アイテム」を「2」、「大規模複合アイテム」を「3」などのように、数字や文字列で種別情報を表わせばよい。また、価格情報を種別情報に反映させてもよい。例えば、対応する単体アイテムの個数が20個以上であり、かつそれら単体アイテムの価格情報(価格)の合計額が1万円以上になる複合アイテムを「大規模複合アイテム」としてもよい。また例えば、対応する単体アイテムの個数が20個以上であり、その複合アイテムの価格情報(価格)が1万円以上である場合に、「大規模複合アイテム」としてもよい。また、単体/複合の違いを示す情報でなくても、アイテムの価格とある程度の相関関係(規則性)があれば、他のアイテム属性情報を種別情報とすることもできる。例えば、あるカテゴリ(カテゴリA)に属するアイテムの価格が、他のカテゴリに属するアイテムの価格よりも高い傾向にある場合、カテゴリAに対応するアイテムの種別情報を「1」、それ以外のカテゴリに対応するアイテムの種別情報を「0」として処理を行ってもよい。また例えば、アイテム時期情報が新しい(例えば、3ヶ月以内)アイテムの価格が、アイテム時期情報が古い(例えば、3ヶ月より前)アイテムの価格よりも高い傾向に有る場合、新しいアイテムの種別情報を「1」、古いアイテムの種別情報を「0」として処理を行ってもよい。また新しさに応じて、3種類以上の種別情報を用いてもよい。単体/複合の違いを示す情報以外の情報を、種別情報として用いる場合でも、後述する複合アイテムと単体アイテムとの対応情報を用いた処理を省略すれば、推薦情報を作成することができる。
なお、情報選択装置10が、必要に応じてアイテム提供サーバ20の後述するアイテム格納部202からアイテム情報およびカテゴリ情報を取得できるようにして、アイテム属性格納部101を省略することも可能である。
送受信部109は、ネットワーク40(図2の構成の場合は、さらにネットワーク42)を介して、アイテム提供サーバ20または端末装置30との間でデータを送受信する処理を行なう。
制御部110は、情報選択装置10の全体の制御を行なうための種々の処理を行なう。例えば、後述するように、アイテム提供サーバ20または端末装置30から送信される利用リクエストを、送受信部109を介して受信し、利用リクエストに含まれるユーザ識別子とアイテム識別子とを対応させて、利用履歴情報として利用履歴格納部102に格納させる。
利用履歴格納部102は、ユーザのアイテム利用履歴情報を記録するアイテム利用履歴テーブル102Aを格納している。アイテム利用は、ユーザからの利用リクエストに対してアイテム提供サーバ20がアイテムを提供することにより実行される。ただし、アイテム利用は、購入を伴う提供に限られず、アイテムに関する情報の閲覧、視聴等を含めるようにしてもよい。
アイテム利用履歴テーブル102Aは、利用履歴情報の格納形態として、種々の格納形態を採用することができる。例えば、図5(a)のアイテム利用履歴テーブル102A−1に示すように、利用主体識別子とアイテム識別子とを関連付けて格納することができる。ここで、「利用主体識別子」は、端末装置30を利用するユーザを一意に識別するユーザ識別子、または端末装置30を一意に識別するための端末識別子であり、ユーザ識別子と端末識別子とを合わせた概念である。本実施形態では、ユーザ識別子を用いてユーザを識別するものとするが、端末装置30として携帯電話を用いた場合等には、端末装置30との接続時に取得可能な端末識別子を用いるようにしてもよい。
本例では、1つの利用リクエストが、テーブルの1行に対応している。テーブルの1行目と4行目がともに「UserID−1」と「ItemID−3」の組み合わせであることから分かるように、利用主体識別子とアイテム識別子の組み合わせが同じであっても、利用リクエストごとにテーブル行のデータを追加して格納している。このため、アイテム識別子が示すアイテムごとの利用回数、およびアイテムごとの利用ユーザ数を他の処理部が容易にカウントすることができる。なお、1つの利用リクエストに複数のアイテム識別子が含まれている場合は、アイテム識別子の数だけのテーブル行を割り当てて格納する。
図5(b)に示すアイテム利用履歴テーブル102A−2は、利用主体識別子とアイテム識別子と利用時期情報とを関連付けて格納する格納形態例である。図5(a)に示したアイテム利用履歴テーブル102A−1と同様に、1つの利用リクエストが、テーブルの1行に対応している。利用リクエストに利用時期情報が含まれている場合は、その情報を取り出して利用時期情報として格納する。利用リクエストに利用時期情報が含まれていない場合は、制御部110に内蔵等されている時計を用いて、情報選択装置10が利用リクエストを受信した時期(時点)を利用時期情報として格納する。
本実施形態では、利用時期情報の表現形式として、「2010年1月1日 10時15分20秒」などの秒単位までの日時を用いるが、それ以外にも、ミリ秒単位までの日時、日単位までの日付、月単位、年単位など種々の形式を用いることができる。なお、利用リクエストの中に、ユーザのアイテムに対する評価値(好き=3、どちらでもない=2、嫌い=1、などの好き嫌いの度合いを示す数値)を含ませた上で、ユーザ識別子とアイテム識別子と利用時期情報と評価値とを関連付けてアイテム利用履歴テーブル102A−2に格納するようにしてもよい。
なお、図5(a)および(b)には示していないが、利用リクエストが発行された際にユーザが閲覧していたページ情報(閲覧ページ情報)を、利用主体識別子およびアイテム識別子と関連付けて格納してもよい。例えば、ユーザが推薦ページを閲覧して利用リクエストを発行したのか、あるいは新着アイテムを紹介するページを閲覧して利用リクエストを発行したのかを区別できる情報を格納する。このような閲覧ページ情報は、推薦情報を提供した効果を詳細に測定するために用いることができる。
図5(c)に示すアイテム利用履歴テーブル102A−3は、利用時期情報を省略し、ユーザ識別子とアイテム識別子と利用回数とを関連付けた格納形態例である。後述するように、関連度算出部104において、利用時期情報を用いない場合は、アイテム利用履歴テーブル102A−3を用いることで利用履歴格納部102の記憶容量を削減することができる。また、利用リクエストの中に、ユーザのアイテムに対する評価値が含まれる場合は、ユーザ識別子とアイテム識別子と利用回数と最新の評価値とを関連付けてアイテム利用履歴テーブル102A−3に格納するようにしてもよい。
なお、図5(c)に示すアイテム利用履歴テーブル102A−3では、利用時期情報を格納していないが、あるユーザがあるアイテムを利用した最新の利用時期情報を格納してもよい。すなわち、ユーザ識別子とアイテム識別子と利用回数と最新の利用時期情報とを関連付けて格納してもよい。あるいは、ユーザ識別子とアイテム識別子と利用回数と最初の(最も古い)利用時期情報とを関連付けて格納してもよい。
推薦情報格納部108は、情報選択部107で選択された推薦情報を記録する推薦情報テーブルを格納する。推薦情報は、利用主体識別子と、それに関連するアイテム識別子(以下「関連識別子」または「関連アイテム識別子」と称する)とを対応させた情報である。図6は、利用主体識別子と関連アイテム識別子と推薦順位とを対応させて格納したアイテム推薦情報テーブル108Aの例を示している。関連アイテム識別子は、利用主体識別子と関連するアイテムの識別子であり、単体アイテム、複合アイテムともに関連アイテムになり得る。すなわち、ある1つの利用主体識別子に対応する関連アイテムは、全て単体アイテムであってもよいし、全て複合アイテムであってもよいし、単体アイテムと複合アイテムが混在していてもよい。
アイテム推薦情報テーブル108Aでは、1つの利用主体識別子に、1つ以上の関連アイテム識別子が対応付けられている。「UserID−1」に対応する関連アイテムはN1個格納されており、「UserID−2」に対応する関連アイテムはN2個格納されている。ここで、N1とN2は同じであっても、異なっていてもよい。すなわち、利用主体識別子ごとの関連識別子の個数がすべて同じであってもよいし、利用主体識別子ごとに関連識別子の個数が異なっていてもよい。
推薦順位は、利用主体識別子ごとに関連アイテムを推薦する順位を示しており、ここでは番号が小さいほど優先順位が高く、優先的にユーザに提示されるものとする。本図では、各々の利用主体識別子に対して、推薦順位の高い順に関連識別子(関連アイテム識別子)を格納しているが、推薦順位と対応付けて関連識別子を格納する場合は、適当な順序で格納してもよい。
なお、推薦順位の代わりに、数値が大きいほど優先順位が高く、優先的にユーザに提示されるような推薦度を格納するようにしてもよい。また、推薦情報テーブルにおいて推薦順位を省略してもよい。この場合は、推薦情報テーブルにおいて、利用主体識別子ごとに推薦順位の高い順、または推薦順位の低い順に関連識別子を格納すればよい。すなわち、ある利用主体識別子に対する関連識別子の推薦順位の情報を、関連識別子の格納順序(格納位置)に持たせてもよい。あるいは、記録された関連識別子をすべて同じ順位として扱ったり、推薦情報テーブルを読み出す際に、ランダムに推薦順位を付与してもよい。
関連度算出部104は、利用履歴格納部102に格納されたデータを用いて、利用主体識別子とアイテムとの関連度を算出して関連集合を作成し、関連集合格納部105に格納させる。
関連集合格納部105は、利用主体識別子と、関連識別子と、関連度とを対応させた関連度テーブル105Aを格納する。関連度とは、利用主体識別子と関連識別子との関連性の高さを示す数値であり、利用主体識別子に係るユーザが関連識別子に係るアイテムを好む程度を予測した数値である。
図7は、関連度テーブル105Aの一例を示している。関連度テーブル105Aに格納されている、ある1つの利用主体識別子に対応する関連識別子の集合をその利用主体識別子の関連集合と称する。本図の例では、利用主体識別子「UserID−1」に対応する関連識別子をL1個、利用主体識別子「UserID−2」に対応する関連識別子をL2個格納している。ここで、L1とL2は同じであっても、異なっていてもよい。すなわち、すべての利用主体識別子に対して同じ数の関連識別子を格納してもよいし、利用主体識別子ごとに異なる数の関連識別子を格納してもよい。また、関連度算出部104で関連度が算出された利用主体識別子と関連識別子の組み合わせをすべて格納してもよいし、利用主体識別子との関連度の高い関連識別子のみを関連集合として格納してもよい。一部のみを格納することにより、関連集合格納部105の記憶容量を削減することができる。また、本図に示すように、利用主体識別子ごとに、関連度の大きい順に関連識別子を格納してもよい。
1つの関連集合の要素数(関連識別子の数)は、基本的には複数であるが、要素数が「1」の関連集合が存在していてもよい。ただし、少なくとも1つ以上の関連集合の要素数は「2」以上である必要がある。なお、情報選択装置10以外の他の装置で算出された関連集合および関連度を関連度テーブル105Aに記録してもよく、その場合は関連度算出部104を省略することができる。
種別影響度算出部106は、アイテム属性格納部101および関連集合格納部105を参照しながら、関連集合の各々の関連識別子について、その種別情報が推薦結果に与える影響度である種別影響度を算出する。
情報選択部107は、種別影響度算出部106で算出された種別影響度と、関連集合格納部105の関連度テーブル105Aに格納された関連度とを用いて選択指標を算出し、その選択指標に基づいて、関連集合格納部105の関連度テーブル105Aに格納された利用主体識別子ごとに関連識別子を選択し、その選択された関連識別子と利用主体識別子との組み合わせを推薦情報として、推薦情報格納部108のアイテム推薦情報テーブル108Aに格納する。
<アイテム提供サーバ>
アイテム提供サーバ20は、端末装置30からの要求に応じて、アイテムおよびアイテムに関する情報を提供する装置である。図8は、アイテム提供サーバ20の構成を示すブロック図である。本図に示すように、アイテム提供サーバ20は、ユーザ管理部201と、アイテム格納部202と、データ格納部203と、送受信部204と、制御部205とを備えて構成されている。
アイテム提供サーバ20は、CPU、RAM、ROM、HDD(ハードディスクドライブ)、ネットワークインタフェース等を備える一般的なコンピュータを用いて構成することができる。すなわち、一般的なコンピュータは、以下で説明するような処理を行なうためのプログラムを実行することにより、アイテム提供サーバ20として機能することができるようになる。
送受信部204は、ネットワーク40(図2の構成の場合は、さらにネットワーク42)を介して情報選択装置10および端末装置30との間でデータを送受信する処理を行なう。制御部205は、アイテム提供サーバ20の全体の制御を行なう。
ユーザ管理部201は、端末装置30を利用するユーザを一意に識別するユーザ識別子、または端末装置30を一意に識別するための端末識別子である利用主体識別子を少なくとも格納している。アイテム提供サーバ20は、例えば、ユーザにアイテム利用を開始させるに先立ち、入会処理等を行なって、入会処理の終了した利用主体識別子をユーザ管理部201に格納する。また、必要に応じて、利用主体識別子に対応させて、ログイン名、パスワード、氏名、生年月日、連絡先、決済方法等のユーザ属性情報をユーザ管理部201に格納するようにしてもよい。
アイテム格納部202は、アイテム提供サーバ20が提供するアイテムに関する情報を格納する。アイテム格納部202は、情報選択装置10のアイテム属性格納部101と同様に、単体アイテムおよび複合アイテムのアイテム属性情報を格納する。ただし、アイテムが有体の物品ではなく、デジタルコンテンツ等であって、ネットワーク40を介して端末装置30に配信可能である場合には、アイテム属性格納部101のデータに加えて、アイテム識別子と、アイテム本体(デジタルコンテンツ等のデータ)とを対応させて格納する。
なお、制御部205は、アイテム格納部202が更新されるごと、または所定のスケジュールに基づいて、アイテム格納部202のデータを、送受信部204を介して情報選択装置10に送信し、アイテム属性格納部101に格納させるようにしてもよい。また逆に制御部205は、情報選択装置10から送信されるアイテム属性格納部101のデータを受信し、アイテム格納部202に格納させるようにしてもよい。あるいは、情報選択装置10からアイテム提供サーバ20にアイテム属性情報を要求するメッセージを送信するようにし、制御部205が、それに応じたデータをアイテム格納部202から読み出して、送受信部204を介して情報選択装置10に送信するようにしてもよい。
データ格納部203は、様々なデータを格納することができる。例えば、情報選択装置10の推薦情報格納部108に格納されたデータをコピーしてデータ格納部203に格納することができる。この場合、端末装置30は、アイテム提供サーバ20から推薦情報を受信することができるので、情報選択装置10の処理負荷を低減することができる。また、情報選択装置10の利用履歴格納部102と同様なデータを格納してもよい。この場合、情報選択装置10からデータ格納部203を参照できるようにして、情報選択装置10の利用履歴格納部102を省略することも可能である。
<端末装置>
端末装置30は、ユーザが使用する装置である。図9は、端末装置30の構成を示すブロック図である。本図に示すように、端末装置30は、制御部301と、送受信部302と、ブラウザ部303と、アプリケーション部304とを備えて構成されている。端末装置30は、CPU、RAM、ROM、HDD(ハードディスクドライブ)、ネットワークインタフェース等を備える一般的なコンピュータ等を用いることができる。すなわち、一般的なコンピュータは、以下で説明するような処理を行なうためのプログラムを実行することにより、端末装置30として機能することができるようになる。また、端末装置30は、Webブラウザ機能等を備えた携帯電話や、携帯端末装置等を用いて構成することもできる。
端末装置30には、Webブラウザに代表されるWebページにアクセスしてその情報を表示するプログラムがインストールされており、ブラウザ部303を構成している。また、種々のアプリケーションプログラムを実行することにより、アプリケーション部304が構成される。
端末装置30としてコンピュータを用いた場合には、ディスプレイ等の表示装置320や、キーボード、マウス、トラックボール、リモコン等のユーザからの操作指示を受け付けるための入力装置330が接続される。端末装置30として携帯電話や、携帯端末装置等を用いた場合は、表示装置、入力装置は内蔵されているが、以下では、便宜的に表示装置320、入力装置330が接続されているものとして説明する。
<システム動作>
<システム全体の動作>
図10のフローチャートを参照して、ネットワークシステム全体の基本的な動作を説明する。この基本的な動作は、多少の変更はあるがすべての実施例で共通である。まず、ステップS100において、端末装置30は、ブラウザ部303を用いて、アイテム提供サーバ20のURL(Uniform
Resource Locator)にアクセスする。具体的には、アイテム提供サーバ20の提供する所定のWebページへのリクエスト(利用開始リクエスト)をアイテム提供サーバ20に送信する。
端末装置30としてパーソナルコンピュータ等を用いる場合は、端末装置30を利用するユーザに、事前に設定させたログイン名(ユーザID)とパスワードとを入力させ、これらを利用開始リクエストに含めて送信する。あるいは、Cookie等の技術を用いて、端末装置30を利用するユーザを識別可能なデータを利用開始リクエストに含めて送信すれば、ログイン名とパスワードの送信を省略できる。ログイン名とパスワードを利用開始リクエストに含めて送信する場合は、ステップS100の前に、アイテム提供サーバ20から端末装置30に、ログイン名とパスワードの入力を受け付けるためのHTML(Hyper
Text Markup Language)データ等を送信しておけばよい。
また、端末装置30として携帯電話等を用いる場合は、端末固有の端末識別子を利用開始リクエストに含めて送信すればよい。この場合は、ログイン名とパスワードの送信を省略することができる。
ステップS110において、アイテム提供サーバ20の制御部205は、送受信部204を介して端末装置30からの利用開始リクエストを受信し、ユーザ管理部201を参照しながら、登録済のユーザか否かを判定する。具体的には、利用開始リクエストにログイン名とパスワードが含まれている場合は、それらをユーザ管理部201に格納されているログインおよびパスワードと照合する。また、利用開始リクエストに端末識別子が含まれる場合は、それがユーザ管理部201に格納されている利用主体識別子と一致するか判定する。登録済のユーザである場合(Yes)は、ステップS130に進み、そうでない場合(No)は、ステップS120に進む。
ステップS120において、アイテム提供サーバ20の制御部205は、送受信部204を介して、端末装置30に入会処理を行なうためのWebページ(HTML)を送信する。本図には示していないが、端末装置30を利用するユーザは、入力装置330を利用して入会処理のWebページに必要な情報を入力し、アイテム提供サーバに送信する等の操作を行い、アイテム提供サーバ20は、その情報をユーザ管理部201に格納する等の入会処理が行われる。端末装置30は、入会処理完了後に、改めて利用開始リクエストを送信することができる。
ステップS130において、アイテム提供サーバ20の制御部205は、アイテム格納部202を参照しながら、利用開始リクエストに対応するWebページの応答データであり、アイテムを紹介する情報を含む応答データを作成し、送受信部204を介して端末装置30に送信する。応答データは、HTMLデータ、画像データ、映像データ、音声データなどで構成されており、複数回に分けて端末装置30に送信される場合がある。また、応答データには、ユーザに推薦情報を提供するためのリンク等の情報と、ユーザにアイテムを利用させるための情報とが含まれている。またCookie等の技術を用いて、応答データにユーザや端末装置30を識別するための情報を含めてもよい。
ステップS140において、端末装置30は、アイテム提供サーバ20から応答データを受信し、表示装置320にその情報を表示する。表示画面の例を図11に示す。図11は、応答データにアイテムを紹介する情報が含まれる場合の表示例である。本図の例は、アイテム提供サーバ20が最近提供を開始した「新着アイテム」を紹介する表示画面である。ただし、本図に示すようなアイテムを紹介する情報は、種々のタイミングで端末装置30に送信することができる。なお、情報選択装置1の表示制御情報作成部(図示せず)が、このような応答データを作成し、端末装置30に送信するようにしてもよい。
本図において「アイテムABC」は1番目のアイテムのタイトルであり、「SF」は1番目のアイテムのカテゴリ名であり、「このアイテムは、2001年に制作された映画で…」という表示は1番目のアイテムの説明情報である。また、各々のアイテムごとに、そのアイテムを利用するためのボタンやリンク等(利用リンク)が表示される。2番目以降のアイテムについても同様な表示がされる。
また図11に示すように、「あなたへお薦めのアイテム」等のボタン、リンク等が表示される。これは、端末装置30を利用するユーザに対して、そのユーザとの関連度の高い(そのユーザの嗜好や興味に合う可能性の高い)アイテム情報を表示するためのボタンやリンク等(関連アイテムリンク)である。以下では、このボタンやリンク等を、関連アイテムリンク、または関連リンクと称する。
ユーザは、入力装置330を使用したクリック等の操作により、関連リンクまたは利用リンクを選択することができる。なお表示画面には表示されないが、応答データには、各々のアイテムのアイテム識別子、および端末装置30を利用するユーザに係る利用主体識別子が含まれている。なお、本図には示していないが、新着アイテム等を紹介する表示画面において、アイテムごとにその価格情報を表示してもよい。
図10のフローチャートの説明に戻って、ステップS150において、端末装置30は、関連リンクがユーザから入力装置330を介して選択されたか否かを判定する。関連リンクが指定された場合(Yes)は、ステップS160に進み、指定されていない場合(No)は、ステップS190に進む。
ステップS160において、端末装置30は、関連リンクに対応するURLにリクエスト(推薦リクエスト)を送信する。本実施形態では、関連リンクが情報選択装置10の所定のURLに対応する場合を説明するが、関連リンクをアイテム提供サーバ20の所定のURLに対応させてもよい。推薦リクエストには、利用主体識別子(端末装置30を利用するユーザのユーザ識別子または端末装置30の端末識別子)が含まれている。以下では、この推薦リクエストに含まれる利用主体識別子を「リクエスト利用主体識別子」(情報選択に係る利用主体識別子)と称する。
ステップS170において、情報選択装置10の制御部110は、送受信部109を介して、推薦リクエストを受信し、それに含まれるリクエスト利用主体識別子に対応する表示用推薦データを作成して端末装置30に送信する。
図6に示した推薦情報格納部108のアイテム推薦情報テーブル108Aを参照しながら、リクエスト利用主体識別子に一致する利用主体識別子を特定し、それに対応する関連アイテム識別子と推薦順位とを読み出す。さらに、その関連アイテム識別子に対応するアイテム属性情報をアイテム属性格納部101のアイテム情報テーブル101Aから読み出す。そして、関連アイテム識別子と、推薦順位と、アイテム属性情報とを対応させた表示用推薦データを作成する。
例えば、図6に示した例において、リクエスト利用主体識別子が「UserID−1」である場合は、それと同じ利用主体識別子に対応した関連アイテム識別子である「ItemID−1000」「ItemID−1020」…「ItemID−1035」と、その推薦順位「1」「2」…「N1」を読み出す。ただし、特定した利用主体識別子に対応する関連アイテム識別子をすべて読み出してもよいし、推薦順位の高い順に所定個数読み出してもよい。また推薦リクエストの中に、読み出す推薦情報の個数が含まれている場合は、推薦順位の高い順にその個数だけを読み出す。
このとき、利用履歴格納部102のアイテム利用履歴テーブル102Aを参照しながら、リクエスト利用主体識別子に係るユーザが過去に利用したアイテム識別子(利用済みアイテム識別子)を特定し、利用済みアイテム識別子(利用済みアイテム)を推薦情報に含めない処理を行なってもよい。このような処理を行なうことで、ユーザが1回しか同じアイテムを購入しない性質を持つようなアイテム提供サービスにおいて、精度の高い推薦が可能になる。例えば、1度購入したデジタルコンテンツは、端末装置30で繰り返し利用(再生)できる、といったサービスに適している。
また、過去の利用回数が所定数以上のアイテムを推薦情報に含めない処理や、最近3ヶ月以内等の所定期間内に利用したアイテムを推薦情報に含めない処理を行なってもよい。このような処理を行なうことで、ユーザが利用しない可能性の高いアイテムが推薦情報に入り難くなるので、推薦情報に対するユーザの信頼感や興味の度合いを高めることができる。
そして制御部110は、アイテム属性格納部101を参照しながら、読み出した関連アイテム識別子に対応する「種別情報」「タイトル」「価格情報」「説明情報」などのアイテム属性情報と、「カテゴリ名」などのカテゴリ属性情報とを読み出し、関連アイテム識別子と2つの属性情報と推薦順位とを合わせて表示用推薦データを作成する。また、複合−単体対応テーブル101Cを参照しながら、読み出した関連アイテム識別子が「複合アイテムのアイテム識別子」に合致する場合は、その複合アイテムに対応する単体アイテムを特定し、その特定したアイテムのアイテム属性情報を表示用推薦データに含めてもよい。例えば、図4(c)に示した例において、関連アイテムが「ItemID−3」(複合アイテム)である場合、それに対応する単体アイテム「ItemD−1」などのアイテム属性情報を表示用推薦データに含めてもよい。同様に、読み出した関連アイテム識別子が「単体アイテムのアイテム識別子」に合致する場合、その単体アイテムに対応する複合アイテムを特定し、その特定したアイテムのアイテム属性情報を表示用推薦データに含めてもよい。例えば、図4(c)に示した例において、関連アイテムが「ItemID−2」(単体アイテム)である場合、それに対応する複合アイテム「ItemID−3」「ItemID−4」などのアイテム属性情報を表示用推薦データに含めてもよい。また、アイテム情報テーブル101Aを参照しながら、読み出した関連アイテム識別子に対応する価格情報を読み出し、表示用推薦データに含めてもよい。
なお、アイテム提供サーバ20のユーザ管理部201に、ユーザの氏名やログイン名などのユーザ属性情報が格納されている場合には、上述した表示用推薦データを作成する際にこれらを読み出して、表示用推薦データの中に、リクエスト利用主体識別子と、リクエスト利用主体識別子に対応するユーザ属性情報とを含めてもよい。
また、アイテム推薦情報テーブル108Aにおいて、推薦順位が格納されておらず、関連識別子の格納順序が推薦順位の情報を持っている場合は、その格納順序に従って、表示用推薦データにおける関連識別子の順序を決めればよい。例えば、格納順序が1番目の関連アイテム識別子を表示用推薦データの1番目にし、格納順序が2番目の関連アイテム識別子を表示用推薦データの2番目にすればよい。また、表示用推薦データを作成する際に、ランダムな推薦順位を生成して付与したり、表示用推薦データにおける関連識別子の順序をランダムに決定してもよい。
図10のフローチャートの説明に戻って、ステップS180において、端末装置30は、ステップS170で情報選択装置10から送信された表示用推薦データを受信し、例えば、図12に示す形式で表示装置120に推薦リストとして表示する。図12は、推薦リクエストを発行したユーザとの関連度が高いアイテムを「○○○さんへのおすすめアイテム」として表示する画面の一例である。
「○○○」には、リクエスト利用主体識別子に対応するユーザの氏名やログイン名が表示される。このような表示を行なうことにより、他のユーザに対する推薦情報と共通のものではなく、そのユーザ専用に作成された推薦情報であることをユーザに明確に伝えることができるので、推薦情報に対するユーザの信頼感や興味の度合いを高めることができる。なお、氏名やログイン名を表示しなくても、「あなただけにお知らせする、とっておきアイテムです」など、そのユーザ専用に作成された推薦情報であることが分かる表示を行なうことで、同様の効果を得ることができる。
アイテムの表示順序は、推薦順位に従って決められており、推薦順位が上位のアイテムほど、ユーザの目に留まりやすい位置に表示される。例えば、本図に示すように上下方向に各々のアイテムの情報を配置する場合は、推薦順位が上位のアイテムの表示画面の上側に表示するとよい。また、左右方向に各々のアイテムの情報を配置する場合は、表示画面の左側に表示するとよい。
「アイテムOPQ(第1話)」は1番目のアイテム(推薦順位が「1」のアイテム)のタイトルであり、「サスペンス」は1番目のアイテムのカテゴリ名であり、「このアイテムは、目が離せない…」という表示は、1番目のアイテムの説明情報である。また、<単>は、単体アイテムであること示しており、「300円」は価格情報である。本図では、単体アイテムか複合アイテムであるかの区別を、<単>と<複>といった文字・記号で示しているが、アイコンやフォントの違いなどによって表現してもよい。図11に示した表示例と同様に、各々のアイテムに対して、利用リンクに対応付けられた「アイテム利用」ボタンが表示される。2番目以降のアイテムについても同様な表示がされる。「アイテムDEF(全話セット)」は、推薦順位が「2」のアイテムのタイトルであり、「<複>」は、複合アイテムであること示す文字・記号である。なお、本図には示していないが、表示用推薦データに価格情報が含まれている場合は、アイテムごとにその価格情報を表示してもよい。
図10のフローチャートの説明に戻って、ステップS190において、端末装置30は、利用リンクがユーザから入力装置330を利用して選択されたか否かを判定する。この利用リンクは、代表的には、アイテムの購入要求とすることができるが、アイテムの再生、アイテムのプレビュー、アイテムの詳細情報の表示、アイテムに対する評価情報(評価値)の登録などの種々の要求を含めることができる。利用リンクが選択された場合(Yes)は、ステップS200に進み、そうでない場合(No)はステップS250に進む。
ステップS200において、端末装置30は、利用リンクに対応するURLにリクエスト(利用リクエスト)を送信する。本実施形態では、利用リンクがアイテム提供サーバ20の所定のURLに対応する場合を説明する。なお端末装置30は、利用リクエストをアイテム提供サーバ20に加えて、情報選択装置10に直接送信してもよい。
各々の利用リンクには、選択対象となるアイテムのアイテム識別子が付与されており、利用リクエストには、ユーザが選択したアイテムのアイテム識別子と、そのユーザまたは端末装置30を識別する利用主体識別子とが含まれている。なお、ユーザが一度に複数のアイテムを利用する場合は、1つの利用リクエストに複数のアイテムのアイテム識別子を含めてもよいし、複数の利用リクエストを送信してもよい。
ステップS210において、アイテム提供サーバ20の送受信部204は、端末装置30から受信した利用リクエストを情報選択装置10に送信し中継する。このとき、アイテム提供サーバ20の制御部205が、利用リクエストからアイテム識別子や利用主体識別子などの情報を取り出し、利用情報として、データ格納部203に格納させるようにしてもよい。
ステップS220において、情報選択装置10の制御部110が、送受信部109を介して、利用リクエストを受信し、利用履歴情報として利用履歴格納部102に格納させる。そして、制御部110は、送受信部109を介して、利用履歴情報の格納を終了したことを示すメッセージをアイテム提供サーバ20に送信する。
ステップS230において、アイテム提供サーバ20の制御部205が、送受信部204を介して情報選択装置10からの格納終了メッセージを受信した後、端末装置30にアイテムを提供する処理を行なう。例えば、提供対象のアイテムがデジタルコンテンツである場合には、アイテム格納部202から、利用リクエストに含まれるアイテム識別子に対応するアイテム本体を読み出して、送受信部204を介して端末装置30に送信する。また、アイテムが物品である場合には、配送事業者のシステムに配送依頼の情報を送る配送処理などを行なう。このとき必要に応じて、課金処理などを行なう。また、アイテムの詳細情報が要求された場合には、アイテム格納部202から「説明情報」などを読み出して、端末装置30に送信する。
ステップS240において、端末装置30は、アイテム提供サーバ20から提供されたアイテムの利用に係る処理を行なう。例えば、アイテムがデジタルコンテンツである場合には、アイテムの再生、表示などを行なう。また、アイテムが物品である場合には、配送処理を受付した旨のメッセージ等を画面に表示する。
ステップS250において、端末装置30は、ユーザがブラウザを終了する等の操作終了指示があるか否かを判定する。操作終了指示がある場合(Yes)は、端末装置30の処理を終了し、操作終了指示がない場合(No)は、ステップS150に戻って処理を継続する。
以上がシステム全体の動作の説明である。なお、本実施形態においては、ステップS160で、端末装置30から情報選択装置10に推薦リクエストを送信しているが、これ以外の方法を用いてもよい。例えば、端末装置30からアイテム提供サーバ20に推薦リクエストを送信し、アイテム提供サーバ20が情報選択装置10に推薦リクエストを中継してもよい。また、適当なタイミングで、情報選択装置10の制御部110が、送受信部109を介して、推薦情報格納部108に格納されたデータをアイテム提供サーバ20に送信すると共に、アイテム提供サーバ20の制御部205が、送受信部204を介して、そのデータを受信し、データ格納部203に格納させておいてもよい。そして、ステップS160において、端末装置30からアイテム提供サーバ20に推薦リクエストを送信し、ステップS170に相当する処理として、アイテム提供サーバ20の制御部205が、データ格納部203から推薦データを読み出し、表示用推薦データを作成して、端末装置30に送信するようにしてもよい。この場合は、表示用推薦データ作成とその送信に伴う情報選択装置10の処理負荷を減らすことができる。
また、本実施形態においては、ステップS210で、アイテム提供サーバ20が端末装置30からの利用リクエストを情報選択装置10に中継しているが、これ以外の方法を用いてもよい。例えば、ステップS200の利用リクエストの送信と同時、あるいは適当なタイミングで、端末装置30から情報選択装置10に直接、利用リクエストを送信してもよい。
また、ステップS220において、情報選択装置10は、利用履歴情報の格納に加えて、利用リクエストに含まれる利用主体識別子に対応する表示用推薦データをステップS170と同様な方法で作成し、表示用推薦データをアイテム提供サーバ20に送信してもよい。そして、ステップS230において、アイテム提供サーバ20が、アイテム提供処理に加えて、表示用推薦データを端末装置30に送信してもよい。すなわちこの場合、端末装置30は、利用リクエストを送信するごとに、利用リクエストに含まれる利用主体識別子に対応する推薦情報を受信することができる。
また、携帯電話等の端末識別子を利用することができ、特別なユーザ登録処理が不要なアイテム提供サービスにおいて、ステップS200で送信される利用リクエストに、利用主体識別子を含めることができる場合であれば、ステップS110の登録済ユーザ確認処理と、ステップS120の入会処理に必要なデータの送信とを省略することも可能である。
<情報選択装置の動作>
<推薦情報作成動作>
第1実施例における情報選択装置10の処理動作について説明する。まず、情報選択装置10が推薦情報を作成する動作について図13のフローチャートを参照して説明する。
情報選択装置10の制御部110は、所定のタイミングで情報選択装置10の各処理部に指示を出し、推薦情報を作成する処理を開始する。推薦情報作成のタイミングとして、次の3種類を用いることができる。
推薦情報作成の第1のタイミングは、所定の日時または所定の時間間隔である。例えば、「毎日午前6時と午後6時」「毎週月曜の午前10時30分」「12時間ごと」「24時間ごと」などである。このとき、「平日は午前6時、土日は午前6時と午後6時」「平日は3時間ごと、土曜日は6時間ごと、日曜日は12時間ごと」などのように時間間隔が変動してもよい。また、夏は時間間隔を短くして、冬は時間間隔を長くするなど、季節に応じて時間間隔を変えてもよい。この第1のタイミングを用いると、他のタイミングを用いた場合より情報選択装置10の処理負荷を減らすことができる。特に、推薦リクエスト数が少ない時間帯に推薦情報を作成するように設定すれば、情報選択装置10の処理負荷の低減に効果的である。
推薦情報作成の第2のタイミングは、端末装置30の推薦リクエスト送信処理(図10ステップS160)による端末装置30からの推薦リクエストを所定回数受信するごとである。この場合は、基本的には所定回数を1として、推薦リクエストを受信するごとに推薦情報を作成するのがよい。以下の説明では、所定回数を1とするが、所定回数を2以上にすることも可能である。所定回数を1とする場合は、まず推薦リクエストに含まれる利用主体識別子(リクエスト利用主体識別子)に対する推薦情報を作成し、その後に表示用推薦データ作成・送信処理(ステップS170)を行なう。このようにすれば、リクエスト利用主体識別子に対して、常に最新の推薦情報を提供することができる。
推薦情報作成の第3のタイミングは、アイテム提供サーバ20を中継して送られる(ステップS210)、端末装置30の利用リクエスト送信(ステップS200)による利用リクエストを所定回数受信するごとである。この所定回数を調整することにより、情報選択装置10の処理負荷の大きさと、推薦情報の新しさとのバランスを調整することができる。
通常は、所定回数をある程度大きな値として、情報選択装置10の処理負荷があまり大きくならないようにするのがよい。一般的には、ある程度の数の利用履歴が追加されないと、新たな推薦情報を作成しても前回の推薦情報と似た内容になることが多いので、所定数を適切な値に設定すれば、情報選択装置10の処理負荷を抑えながら、比較的新しい利用状況を反映させた推薦情報を提供することができる。特に、利用リクエストの数が季節、曜日、時間帯などにより大きく変動する場合や、利用リクエスト数の増減パターンを事前に予測するのが難しい場合には、第1のタイミングで推薦情報を作成するよりも、情報選択装置10の処理負荷の軽減と、比較的新しい利用状況を推薦情報に反映させることとを両立させやすい。
以下の説明において、推薦情報を作成する対象となる利用主体識別子(情報選択に係る利用主体識別子)の集合を「推薦基準集合」と称する。第1のタイミングおよび第3のタイミングで推薦情報を作成する場合は基本的に、推薦基準集合の要素数が多数となる。第2のタイミングで推薦情報を作成する場合は、推薦基準集合の要素数は基本的に1つであるが、複数の場合もある。
まず、ステップS400において、制御部110の指示を受けた関連度算出部104が、利用主体子とアイテムとの関連度を算出し、これに基づき関連集合を作成し、関連集合を関連集合格納部105に格納させる。ステップS410において、制御部110の指示を受けた種別影響度算出部106が、アイテム属性格納部101を参照しながら、アイテムの種別が推薦結果に与える影響の度合いを示す種別影響度を算出する。
ステップS420において、制御部110の指示を受けた情報選択部107が、ステップS400で算出された関連度、およびステップS410で算出された種別影響度を用いて、選択指標を算出する。
ステップS430において、情報選択部107が、選択指標に基づいて、アイテムを選択して、推薦情報格納部108に格納させる。そして、推薦情報作成動作が終了した旨を制御部110に通知する。
次に、関連集合作成処理(ステップS400)について図14のフローチャートを参照して説明する。
ステップS500において、関連度算出部104は、利用履歴格納部102のアイテム利用履歴テーブル102Aに記録されている利用履歴を読み出す。ここでは、すべての利用履歴を読み出してもよいし、所定の条件を満たす利用履歴を読み出してもよい。例えば、図6(b)に示したアイテム利用履歴テーブル102A−2のように利用時期情報を記録した上で、「利用時期が過去4ヶ月以内」「利用時期と現在との差が3日以上かつ30日未満」などのように、「利用履歴の利用時期情報が所定の範囲にある」という条件を満たす利用履歴を読み出してもよい。
また、ユーザ(利用主体識別子)ごとに利用時期が新しい順に所定個数以内の利用履歴を読み出してもよい。例えば、所定個数を20個とした場合、利用回数が20回以上のユーザに対しては、利用時期が新しい順に20個ずつの利用履歴を読み出し、利用回数が20回未満のユーザに対しては、そのユーザに関するすべての利用履歴を読み出すようにする。このようにすれば、利用頻度が少なく、最近アイテムを利用していないようなユーザに対しても効率よく関連集合を作成することができる。
そして、このステップS500で読み出した利用履歴に含まれるユーザ(利用主体識別子)の集合σを作成する。以下では、このステップで読み出した利用履歴に含まれるアイテムの数(アイテム識別子の種類数)をMs、ユーザの数(利用主体識別子の種類数)をUsとする。
ステップS510において、関連度算出部104は、推薦基準集合K1を作成する。上述したように、第2タイミングで推薦情報を作成する場合には、リクエスト利用主体識別子を推薦基準集合K1に入れる。
第1および第3のタイミングで推薦情報を作成する場合は、ステップS500で作成したアイテムの集合σを推薦基準集合K1とする。この場合は、所定条件を満たす利用履歴に含まれる利用主体識別子識別子それぞれに対して関連アイテム集合が作成されることになる。なお、ここで作成された推薦基準集合K1は、情報選択部107、制御部110などの他の処理部から参照することができる。
ステップS520において、関連度算出部104は、ステップS510で作成された推薦基準集合K1の中から未処理のユーザを1つ選択する。この処理対象となるユーザを基準ユーザxとする。
ステップS530において、関連度算出部104は、ステップS500で読み出された利用履歴を用いて、基準ユーザxと、ユーザ集合σに属する他ユーザy(y∈σ、x≠y)との類似度を算出する。
具体的には、基準ユーザ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]を算出することができる。以下では、あるユーザ(例えば、ユーザx)が利用したアイテムの集合を利用アイテム集合と称する。
また、ステップS500で読み出された利用履歴から、利用回数に関する情報やユーザがアイテムに対して行なった評価の情報(評価値)が得られる場合は、コサイン尺度やピアソン積率相関係数を用いて類似度を算出してもよい。例えば、ユーザxのアイテムzに対する嗜好値をE[x][z](ただし、E[x][z]≧0)、ユーザyのアイテムzに対する嗜好値をE[y][z](ただし、E[y][z]≧0)としたとき、[数2]を用いて、ユーザxとユーザyとの類似度D[x][y]を算出することができる。ここで、γは0より大きい定数であり、γ=1に設定すると、[数2]はコサイン尺度になる。γ>1に設定すると、通常のコサイン尺度に比べ、利用回数または評価値が大きいデータの影響力を大きくして類似度を算出できる。また、Msは、ステップS500で読み出された利用履歴に含まれるアイテムの数である。
また、嗜好値とは、ユーザxのアイテムzに対する利用回数または評価値に基づく数値である。例えば、利用回数または評価値そのものを嗜好値としてもよい。あるいは、利用回数または評価値を所定の関数に入力した際の出力値を嗜好値としてもよい。例えば、利用回数の平方根、利用回数を対数関数に入力した出力値を用いて算出された値などを嗜好値とすればよい。特に、利用回数が幅広く分布している場合(利用回数のダイナミックレンジが広い場合)は、このように、利用回数に対して非線形関数を適用して嗜好値を算出するとよい。本実施形態で示す例においては、利用回数が「0」であれば、嗜好値も「0」になる。
また、[数3]に示すように、ピアソン積率相関係数を用いて、類似度D[x][y]を算出してもよい。
ここで、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]を算出してもよい。
また、利用履歴格納部102に利用時期情報が格納されている場合は、E[x][z]などを算出する際に、利用時期が古い利用履歴より、新しい利用履歴の重みを大きくして算出してもよい。
さらに、ユーザxのアイテムzに対する嗜好値であるE[x][z](x=1〜Us、z=1〜Ms)を行列要素とする行列に対して、主成分分析や数量化3類などの多変量解析を適用し、次元数を削減したベクトルを生成し、コサイン尺度やユークリッド距離などを用いてユーザ間の類似度を算出してもよい。また、上記以外にも、ユーザ間の類似性を表わす指標であれば、どのような方法を用いてもよい。
なお、ユーザ間の類似度を算出する際に、それぞれのユーザの利用アイテム集合をそのまま用いてもよいが、以下に示す第1〜第2の方法を用いて、利用アイテム集合を加工した拡張利用アイテム集合を作成した上で、それを用いてユーザ間の類似度を算出してもよい。
拡張利用アイテム集合作成の第1の方法は、利用アイテム集合に含まれる単体アイテムに対応する複合アイテムを、利用アイテム集合に追加する方法である。単体アイテムと複合アイテムとの対応関係は、複合−単体対応テーブル101Cに基づいて判定すればよい。例えば、図4(c)に示す例において、ユーザxが単体アイテム「ItemID−1」を利用していて、それに対応する複合アイテム「ItemID−3」を利用していない場合、ユーザxの利用アイテム集合I[x]に「ItemID−3」を追加する。すなわち、ユーザxが「ItemID−3」を仮想的に利用したと見なす。また、ユーザxが「ItemID−2」を利用し、それに対応する「ItemID−3」および「ItemID−4」の2つの複合アイテムのうち少なくとも一方を利用していない場合、その利用していない複合アイテムを追加する。
またユーザが、複合アイテムに対応する単体アイテムを所定数以上(または所定割合以上)利用している場合に、その複合アイテムを利用アイテム集合に追加するようにしてもよい。例えば、図4(c)に示す例において、複合アイテム「ItemID−3」に対応する単体アイテムは4個あるが、この所定数を「2」とした場合、「ItemID−1」のみを利用したユーザに対しては、「ItemID−3」は追加されない。一方、「ItemID−1」と「ItemID−5」を利用したユーザに対しては、「ItemID−3」が追加される。この所定数を「1」として、ユーザが対応する単体アイテムを1つ以上利用した場合に、複合アイテムを追加してもよい。また、所定数ではなく、所定割合を用いて同様の処理を行ってもよい。例えば、所定割合を50%として、同様の処理を行ってもよい。また、所定数と所定割合を組合せて同様の処理を行ってもよい。例えば、複合アイテムに対応する単体アイテムを3個以上利用し、かつ対応する単体アイテム全体の40%以上利用している場合に、その複合アイテムを利用アイテム集合に追加する等の処理を行ってもよい。
また、上述の[数2]または[数3]に示すように、ユーザのアイテムに対する嗜好値を用いて、ユーザ間類似度を算出する場合、追加する複合アイテムに関する嗜好値を、種々の方法で算出して用いればよい。例えば、ユーザxが利用していない複合アイテムzfを利用アイテム集合に追加する場合、複合アイテムzfに対応するn個の単体アイテムzt1〜ztnを対象に、ユーザxのそれぞれの単体アイテムに対する嗜好値E[x][zt1]〜E[x][ztn]の合計値を算出し、その合計値を複合アイテムzfの嗜好値E[x][zf]としてもよい。また、E[x][zt1]〜E[x][ztn]の代表値(平均値、中央値、最頻値、最大値、最小値、四分位値など)をE[x][zf]としてもよい。なお、ユーザxが利用している複合アイテムzg(最初から利用アイテム集合に含まれる複合アイテム)の嗜好値E[x][zg]を、それに対応する単体アイテムの嗜好値を用いて加工してもよい。例えば、複合アイテムzgが、n個の単体アイテムzs1〜zsnに対応する場合、それらの嗜好値E[x][zs1]〜E[x][zsn]の合計値または代表値を、複合アイテムzgの嗜好値E[x][zg]に加算した値を、複合アイテムzgの新たな嗜好値としてもよい。
第1の方法を用いることにより、複合アイテムが推薦情報に含まれる可能性を増やすことができる。従って後述するように、より多くの複合アイテムを推薦情報に含めたい場合に、第1の方法を用いるとよい。なお、第1の方法の変形例として、複合アイテムを利用アイテム集合に追加することに加えて、追加した複合アイテムに対応する単体アイテム(元々利用アイテム集合に含まれていた単体アイテム)を削除する処理を行ってもよい。
拡張利用アイテム集合作成の第2の方法は、利用アイテム集合に含まれる複合アイテムに対応する単体アイテムを、利用アイテム集合に追加する方法である。例えば、図4(c)に示す例において、ユーザxが複合アイテム「ItemID−3」を利用していて、それに対応する単体アイテム「ItemID−5」および「ItemID−6」は利用しており、「ItemID−1」および「ItemID−2」は利用していない場合、ユーザxの利用アイテム集合I[x]に「ItemID−1」および「ItemID−2」を追加する。すなわち、ユーザxが「ItemID−1」および「ItemID−2」を仮想的に利用したと見なす。またユーザが、ある複合アイテムを所定回数以上利用している場合に、その複合アイテムに対応する単体アイテムを利用アイテム集合に追加するようにしてもよい。
また、上述の[数2]または[数3]に示すように、ユーザのアイテムに対する嗜好値を用いて、ユーザ間類似度を算出する場合、追加する単体アイテムに関する嗜好値を、種々の方法で算出して用いればよい。例えば、ユーザxが利用していない単体アイテムztを利用アイテム集合に追加する場合、単体アイテムztに対応する複合アイテムが1つであれば、その複合アイテムzf1に関する嗜好値E[x][zf1]を、単体アイテムztの嗜好値E[x][zt]とすることができる。あるいは、E[x][zf1]を、複合アイテムzf1に対応する単体アイテムの個数で割った値をE[x][zt]としてもよい。また、単体アイテムztに対応する複合アイテムが複数(n個)ある場合は、それらの複合アイテムzf1〜zfnを対象に、E[x][zf1]〜E[x][zfn]の代表値(平均値、中央値、最頻値、最大値、最小値、四分位値など)を算出し、その代表値をE[x][zt]とすればよい。なお、ユーザxが利用している単体アイテムzs(最初から利用アイテム集合に含まれる単体アイテム)の嗜好値E[x][zs]を、それに対応する複合アイテムの嗜好値を用いて加工してもよい。例えば、単体アイテムzsが、n個の複合アイテムzg1〜zgnに対応する場合、それらの嗜好値E[x][zg1]〜E[x][zgn]それぞれを、zg1〜zgnそれぞれに対応する単体アイテムの個数zq1〜zqnで割った値、(E[x][zg1]/zq1)、(E[x][zg2]/zq2)、(E[x][zg3]/zq3)、…、(E[x][zgn]/zqn)を算出する。そして、算出したこれらの値の合計値または代表値を、単体アイテムzsの嗜好値E[x][zs]に加算した値を、単体アイテムzsの新たな嗜好値としてもよい。
第2の方法を用いることにより、単体アイテムが推薦情報に含まれる可能性を増やすことができる。従って後述するように、より多くの単体アイテムを推薦情報に含めたい場合に、第2の方法を用いるとよい。なお、第2の方法の変形例として、単体アイテムを利用アイテム集合に追加することに加えて、追加した単体アイテムに対応する複合アイテム(元々利用アイテム集合に含まれていた複合アイテム)を削除する処理を行ってもよい。
上述の拡張利用アイテム集合作成に関する第1および第2の方法に共通する効果として、ユーザ間の類似度をより精度よく算出でき、推薦情報をより精度よく算出できる場合がある。例えば、利用したアイテムの数が少ないユーザでは、後述する類似ユーザが十分な数だけ算出できない場合があるが、複合アイテムと単体アイテムとの対応関係(対応情報)に基づく拡張利用アイテム集合の作成処理を行うことにより、類似ユーザの数が増加し、推薦情報の精度が改善される。また、推薦情報に含まれるアイテムの種類数(推薦情報のバリエーション)を増やすことができるので、ユーザの推薦情報に対する興味を高めることができる。また後述するように、所定の時点からの経過時間に応じて、拡張利用アイテム集合を作成しない、第1の方法を用いて拡張利用アイテム集合を作成する、第2の方法を用いて拡張利用アイテム集合を作成する、など処理の切り替えを行ってもよい。
このようにして算出されたユーザxと、ユーザy(y∈σ、x≠y)との類似度は、関連度算出部104内部のメモリ(図示せず)に格納される。なお、ステップS520〜S560のループ(繰り返し)処理において、ユーザxと、ユーザyとの類似度が既に算出され、関連度算出部104内部のメモリに格納されている場合は、新たな算出を行なわずに格納されている値を利用してもよい。
ステップS540において、関連度算出部104は、基準ユーザxとアイテムzとの関連度W[x][z]を算出する。
関連度算出の第1の方法は、ステップS530で算出された類似度D[x][y]が高い「類似ユーザ」を特定し、類似ユーザに多く利用されたアイテムほど関連度が高くなるように算出する方法である。
具体的にはまず、類似度D[x][y]が所定値以上のユーザ、あるいは類似度D[x][y]が高い順に所定数のユーザを類似ユーザ(類似ユーザ集合)として特定する。次に、ステップS500で読み出された利用履歴を対象にして、類似ユーザが利用したアイテムを特定し、アイテムごとに利用回数をカウントし、この利用回数を関連度とする。また利用回数の平方根や対数値などを用いて関連度を算出してもよい。あるいは、類似ユーザ集合を特定した後、類似ユーザの嗜好値が「0」より大きいアイテムを対象にして、アイテムごとに嗜好値を加算して合計値を算出し、その合計値を関連度としてもよい。第1の方法によれば、類似ユーザに利用されたアイテムの関連度が算出される。類似ユーザに利用されていないアイテムの関連度は「0」とすればよい。
この第1の方法は、ユーザがアイテムを気に入った場合に、そのアイテムを複数回利用(購入)する性質を持つようなアイテム提供サービスに適している。例えば、端末装置30に保存できない形式のデジタルコンテンツや、消耗品の物販などである。
関連度算出の第2の方法は、多くの類似ユーザに利用されたアイテムほど関連度が高くなるように算出する方法である。第1の方法と同様に、類似ユーザを特定した後、ステップS500で読み出された利用履歴を対象にして、類似ユーザが利用したアイテムを特定し、アイテムごとに利用した人数をカウントし、この利用人数を関連度とする。
第2の方法は、ユーザが基本的に同じアイテムを1度しか利用(購入)しない性質のアイテム提供サービスに適している。例えば、アイテムが端末装置30に保存して何回でも再生できる形式のデジタルコンテンツであれば、ユーザが再度購入するのは、ユーザが端末装置30から間違って消去したような例外的なケースが想定され、基本的には同じアイテムを1回しか購入しないので、この第2の方法が有効である。また、第1および第2の方法によれば、類似ユーザの数を適切に設定することにより、少ない計算量で、精度よく関連度を算出することができる。
関連度算出の第3の方法は、ユーザ間の類似度を直接用いて関連度を算出する方法である。具体的にはまず、ステップS500で読み出された利用履歴を対象にして、ユーザy(y∈σ、x≠y)がアイテムzを利用した回数C[y][z]をカウントする。そして、[数4]に示すように、類似度D[x][y]と利用回数C[y][z]との積を加算した値を用いてユーザxとアイテムzとの関連度W[x][z]を算出する。あるいは、C[y][z]の代わりに、ユーザyのアイテムzに対する嗜好値E[y][z]を用い、[数4]のおいて、C[y][z]をE[y][z]で置き換えて、関連度を算出してもよい。第3の方法では、アイテムzの利用回数が多く、かつ利用したユーザの類似度が高いほど、関連度が高く算出される。
なお[数4]では、類似度D[x][y]が算出されたすべてのユーザの情報を用いて関連度を算出しているが、類似ユーザ集合の各ユーザを対象にして[数4]の計算を行なってもよい。また[数4]において、ユーザyがアイテムzを利用した場合にC[y][z]=1、利用していない場合にC[y][z]=0として計算してもよい。このようにすれば、アイテムzを利用したユーザ数が多く、かつ利用したユーザの類似度が高いほど、関連度が高く算出される。この第3の方法によれば、基準ユーザとアイテムとの関連度をさらに精度よく算出することができる。
さらに関連度算出の第1〜第3の方法において、アイテム属性格納部101のアイテム情報テーブル101Aからアイテム時期情報を読み出し、これを用いて処理を行なってもよい。具体的には、アイテム時期情報が新しいアイテムほど大きな値となる重み係数を算出し、利用回数や利用ユーザ数を算出する際に、この重み係数を乗じる等の演算を行なう。このようにすれば、ユーザにとって一般的に価値の高い「新作」アイテムの関連度を高くして、優先的に推薦情報に入れることができる。
また関連度算出の第1〜第3の方法において、単体アイテムと複合アイテムとの対応情報を用いて、関連度を加工した拡張関連度を算出し、これを関連度の代わりに関連集合格納部105に格納してもよい。
拡張関連度算出の第1の方法は、対応関係のある単体アイテムの関連度を用いて、複合アイテムの拡張関連度を算出し、その複合アイテムの関連度の代わりに拡張関連度を用いる方法である。単体アイテムと複合アイテムとの対応関係は、複合−単体対応テーブル101Cに基づいて判定すればよい。例えば、図4(c)に示す例において、ある利用主体識別子(ユーザA)と単体アイテム「ItemID−1」との関連度が「0.5」、ユーザAと単体アイテム「ItemID−2」との関連度が「0.4」として算出され、ユーザAと「ItemID−5」、「ItemID−6」および「ItemID−3」との関連度は算出されていないものとする。この場合、複合アイテム「ItemID−3」の拡張関連度を、それと対応関係のある単体アイテムである「ItemID−1」および「ItemID−2」の関連度を用いて算出することができる。
例えば、対応する単体アイテムの関連度の総和を拡張関連度とすることができ、「0.5+0.4=0.9」が拡張関連度となる。また、対応する単体アイテムの関連度の代表値を拡張関連度としてもよい。例えば、代表値として最大値を用いると、拡張関連度は「0.5」となり、代表値として平均値を用いると、格調関連度は「(0.5+0.4)÷2=0.45」となる。代表値として他に、中央値、最頻値、最低値などを用いることができる。また、複合アイテムに対応する全ての単体アイテムのうち所定個数以上または/および所定割合以上の単体アイテムの関連度が算出された場合にのみ、拡張関連度を算出してもよい。例えば、単体アイテムの50%以上で関連度が算出された場合にのみ拡張関連度を算出してもよい。また、ユーザAと「ItemID−3」との関連度が算出されている場合であっても、その関連度の代わりに拡張関連度を用いてもよい。例えば、関連度よりも拡張関連度が大きい場合に、関連度を拡張関連度で置き換えて使用する等のルールを設けてもよい。この第1の方法を用いると、関連度の算出されなかった複合アイテムや関連度の小さな複合アイテムでも、後述の関連アイテム集合に入れることができるため、推薦情報により多くの複合アイテムを含めることができる。
拡張関連度算出の第2の方法は、対応関係のある複合アイテムの関連度を用いて、単体アイテムの拡張関連度を算出し、その単体アイテムの関連度の代わりに拡張関連度を用いる方法である。例えば、図4(c)に示す例において、ある利用主体識別子(ユーザA)と複合アイテム「ItemID−4」との関連度が「0.9」、ユーザAと単体アイテム「ItemID−2」との関連度が「0.4」として算出され、ユーザAと「ItemID−10」および「ItemID−11」との関連度は算出されていないものとする。この場合、単体アイテム「ItemID−10」および「ItemID−11」の拡張関連度を、それらと対応関係のある複合アイテムである「ItemID−4」の関連度を用いて算出することができる。
例えば、対応する複合アイテムの関連度をそのまま単体アイテムの拡張関連度とすることができ、「0.9」がそれぞれの拡張関連度となる。また、対応する複合アイテムの関連度を対応する単体アイテムの個数で割った値としてもよい。例えば、ItemID−4に対応する単体アイテムは3個あるので、「0.9÷3=0.3」がそれぞれの拡張関連度となる。また、複合アイテムの関連度から、対応する単体アイテムの関連度の総和を引いた値を、関連度が算出されていない単体アイテムの個数で割った値を算出してもよい。例えば、この例において、「ItemID−4」に対応する単体アイテムで関連度が算出されていないものは2個なので、「(0.9−0.4)÷2=0.25」をそれぞれの拡張関連度としてもよい。また例えば、ユーザAと「ItemID−10」との関連度が算出されている場合であっても、その関連度の代わりに拡張関連度を用いてもよい。例えば、関連度よりも拡張関連度が大きい場合に、関連度を拡張関連度で置き換えて使用する等のルールを設けてもよい。この第2の方法を用いると、関連度の算出されなかった単体アイテムや関連度の小さな単体アイテムでも、後述の関連アイテム集合に入れることができるため、推薦情報により多くの単体アイテムを含めることができる。
また、拡張関連度算出の第1〜第2の方法において、3種類以上の種別情報を用いて処理を行ってもよい。例えば、第1の方法において、複合アイテムが「大規模複合アイテム」または「中規模複合アイテム」である場合に拡張関連度を算出し、「小規模複合アイテム」の場合は拡張関連度を算出しない等の処理を行ってもよい。また後述するように、所定の時点からの経過時間に応じて、拡張関連度を算出しない、第1の方法を用いて拡張関連度を算出する、第2の方法を用いて拡張関連度を算出する、など処理の切り替えを行ってもよい。
ステップS550において、関連度算出部104は、基準ユーザxに関する関連アイテム集合Ω[x]を作成し、関連集合格納部105に格納させる。関連アイテム集合Ω[x]は、関連識別子がすべてアイテム識別子であるような関連集合である。なお、以下の説明における関連度には、上述の拡張関連度も含まれる。
関連アイテム集合作成の第1の方法は、ステップS540において基準ユーザxとの関連度を算出したすべてのアイテム(関連度が「0」より大きいすべてのアイテム)を関連アイテム集合Ω[x]に入れる方法である。この方法は、なるべく多くの推薦結果を出力したい場合に適している。
関連アイテム集合作成の第2の方法は、基準ユーザxとの関連度が高いアイテムを選出して関連アイテム集合Ω[x]に入れる方法である。具体的には、ステップS540において関連度を算出したすべてのアイテムの中から、関連度が閾値以上のアイテムを選出する。または、関連度が大きい順に所定値を超えない範囲でアイテムを選出してもよい。例えば、基準ユーザxとの関連度が算出されたアイテムの数が所定数に満たない場合は、関連度が算出されたすべてのアイテムを選出し、そうでない場合は、関連度が大きい順に所定数のアイテムを選出すればよい。
さらに、基準ユーザxとの関連度が所定値以上のアイテムの中から、関連度が大きい順に所定数を超えない範囲でアイテムを選出し、それらを関連アイテム集合Ω[x]としてもよい。また関連アイテム集合Ω[x]の要素が所定数以上得られるように、関連度の閾値を基準ユーザxごとに調整して選出してもよい。この第2の方法によれば、関連集合格納部105に必要な記憶容量を削減でき、さらにステップS410〜S430の処理を効率よく行なうことができる。
そして、関連度算出部104は、基準ユーザxの利用主体識別子と、関連アイテム集合Ω[x]の各アイテム識別子と、その関連度とを対応させて、関連集合格納部105の関連度テーブル105Aに記録する。具体的には、基準ユーザxの利用主体識別子を図7に示した関連度テーブル105Aの利用主体識別子に対応させ、関連アイテム集合Ω[x]の各アイテム識別子を関連度テーブル105Aの関連アイテム識別子に対応させて記録する。
なお、上述したユーザとアイテムとの関連度の算出工程において、関連度の最大値や合計値が所定値(例えば「1」)になるように、正規化処理を行なってもよい。
ステップS560において、関連度算出部104は、他の基準ユーザを選択可能か判定する。ステップS510で作成された推薦基準集合K1の中で、まだ処理を行なっていないユーザが存在する場合に「Yes」と判定し、未処理のユーザが存在しない場合は、「No」と判定する。「Yes」と判定した場合は、ステップS520に戻って処理を繰り返し、「No」と判定した場合は、関連度算出処理を終了する。
この結果、関連集合格納部105の関連度テーブル105Aには、ステップS510で作成された推薦基準集合K1の利用主体識別子それぞれに対応する関連集合が格納される。
<種別影響度算出処理>
図13に戻り、ステップS410における種別影響度算出処理を詳細に説明する。制御部110は、ステップS400により関連集合格納部105に格納された関連集合(関連識別子)を読み出し、アイテム属性格納部101を参照しながら、各関連識別子に対応する種別情報を種別影響度算出部106に入力し、種別影響度を算出させる。
例えば、関連識別子が「ItemID−3」である場合は、図4(a)に示したアイテム情報テーブル101Aを参照し、その種別情報である「1」を種別影響度算出部106に入力する。また例えば、関連識別子が「ItemID−5」である場合は、その種別情報である「0」を種別影響度算出部106に入力する。
種別影響度算出部106は、種別情報を入力Xとし、種別情報が推薦結果に与える影響を決める種別影響度を出力Yとする種別影響関数F(X)を内部の記憶領域に記憶している。本実施形態においてまず、単体アイテムと複合アイテムに対応する2値の離散値を入力Xとし、入力値それぞれに対応する種別影響度を出力する種別影響関数(対応規則)について説明するが、3値以上の離散値で種別情報を構成し、3値以上の入力値に対応する種別影響関数を用いることもできる。なお以下では、種別影響関数を「種別対応規則」、または単に「対応規則」と称することもある。
そして、種別影響度算出部106は、種別影響度算出部106または制御部110が備えるリアルタイムクロック等の計時機能を用いて、所定の時点と推薦情報の作成に係る時点との時間差、または所定の時点と推薦情報の提供に係る時点との時間差に応じて、種別影響関数の特性を変化させる。すなわち、所定の時点から、推薦情報の作成に係る時点または推薦情報の提供に係る時点までの経過時間に応じて、種別影響関数の特性を設定する。
この所定の時点としては、ユーザのアイテム利用意欲に係る可能性のある種々の時点を用いることができる。例えば、アイテム提供サービスが月額課金などの周期的な課金制度を採用している場合には、課金と引き換えに、ユーザの新たなアイテム利用権(新たなポイント)が発生する時点とすることができる。例えば、毎月1日午前0時に月会費として1000円の課金が発生し、1000円に相当するアイテム利用権(アイテムを利用するためのポイント)が、ユーザに付与されるサービスにおいては、毎月1日午前0時を所定の時点とすればよい。また、アイテム提供サービスのキャンペーンやプロモーション等により、多くのユーザにポイント(ボーナスポイント等)が付与される機会があれば、その時点を用いることができる。また、アイテム提供サービスが月額課金などの周期的な課金制度を採用していない場合には、一般的に多くの企業で給料が支給される日(例えば、毎月25日)や、ボーナスが支給される日(例えば、12月10日)など、ユーザが収入を得る確率の高い時点を用いればよい。また、株式市場の株価の指標値、企業の決算情報、景気動向指数、GDP(Gross
Domestic Product)等の経済指標など、経済に係る指標値、またはそれらの成長率が所定の条件を満たす時点を用いてもよい。例えば、経済指標が所定値以上になった時点や、経済指標が極大になる時点は、一般的にユーザの購買力が高く、ユーザのアイテム利用意欲も高い傾向にあると推定できる。
本実施形態においては、アイテム提供サービスが月額課金制度を採用しており、毎月1日午前0時に新たなアイテム利用権(アイテムを利用するためのポイント)が、ユーザに付与される場合を例に説明するが、これに限定されるものではない。また本実施形態においては、図13に示す推薦情報作成処理を実行する時点を所定の時点とする場合を例にして説明するが、これに限定されるものではない。例えば、作成した推薦情報をユーザに提供開始する予定日時や、提供開始から提供終了までの期間の中間時点など、推薦情報の提供に係る時点を所定の日時として用いてもよい。また、所定の時点と、推薦情報の作成に係る時点または推薦情報の提供に係る時点との時間差(経過時間)Tpを表現する単位として、秒単位、分単位、時単位、日単位、週単位など種々の単位を用いることができるが、本実施形態では、日単位を用いることとする。なお、本実施形態では、ユーザのアイテム利用意欲が大きくなる(例えば、極大)と推定される時点を所定の時点としているが、これとは逆に、利用意欲が小さくなる(例えば、極小)と推定される時点を所定の時点とすることも可能である。
種別影響度算出部106は、時間差Tpを算出し、その値に応じて、種別影響関数の特性を設定する。以下では、時間差Tpの値が3つの条件のどれに該当するか判定し、それぞれの条件に対応する3種類の関数を使う例を説明する。
Tpが小さい場合(Tp≦μ1である場合)、図15(a)に示すような関数F1(X)を用いる。ここでμ1は、例えば「10日」等の所定の定数である。関数F1(X)は、X1およびX2の2つの離散値(X1<X2)を関数の定義域とし、それに対応して、Y1およびY2(Y1<Y2)を出力する関数である。本実施形態において、単体アイテムはX1に、複合アイテムはX2に対応する。例えば、X1=「0」、X2=「1」とすればよい。また、X1=「1」、X2=「2」としてもよい。このように、複合アイテムを単体アイテムよりも大きな入力値に対応させた上で、Y1<Y2である単調増加の特性にすると、複合アイテムの種別影響度よりも単体アイテムの種別影響度が大きくなり、複合アイテムが推薦情報に入る確率が高くなる。このような種別影響関数を用いた処理は、アイテムの種別情報に応じた重み係数を設定する処理ということもできる。種別情報がn種類(n≧3)である場合は、n種類の離散値(X1、X2、…、Xn)を入力とし、(Y1、Y2、…、Yn)を出力とする、単調増加関数を用いるとよい。すなわち、Y1<Y2<…<Ynである関数を用いるとよい。時間差Tpが比較的小さい場合には、ユーザが持つポイントが比較的多い(またはユーザがアイテム利用に使えるお金が比較的多い)可能性が高いので、相対的に価格の高い傾向にある複合アイテムを推薦情報の中に多く含めると、アイテム提供サービス全体の売上を増大させる上で効果的である。
時間差Tpが中程度である場合(μ1<Tp≦μ2である場合)には、図15(b)に示すような関数F2(X)を用いる。ここで、μ2は、例えば「20日」等のμ1<μ2を満たす所定の定数である。時間差Tpが中程度である場合には、ユーザが持つポイント(あるいはユーザがアイテム利用に使えるお金)が、時間差Tpが小さい場合に比べて、減少している可能性が高い。従って、図15(b)に示すような、相対的に価格が安い傾向にある単体アイテムの種別影響度が、相対的に価格が高い傾向にある複合アイテムの種別影響度よりも大きくなるような特性を持つ関数を用いるのがよい。種別情報がn種類(n≧3)である場合は、n種類の離散値(X1、X2、…、Xn)を入力とし、(Y1、Y2、…、Yn)を出力とする、単調減少関数を用いるとよい。すなわち、Y1>Y2>…>Ynである関数を用いるとよい。
時間差Tpが大きい場合(μ2<Tp、またはμ2<Tp≦μ3である場合)には、図15(c)に示す関数F3(X)を用いる。ここでμ3は、例えば「30日」等のμ2<μ3を満たす所定の定数である。アイテム提供サービスが月額課金であり、毎月1日から月末までが1つのまとまった期間として扱われる場合は、μ3が月ごとの月末の日に相当するように調整するとよい。なお本実施形態においては、翌月1日の午前0時の時点で、所定の時点がそれまでの時点よりも1ヶ月後に更新されるため、μ3を使わなくても処理可能である。本図に示すように、関数F3(X)は、Y1=Y2の関数である。すなわち、単体アイテムの種別影響度と複合アイテムの種別影響度が同じ値となる。
時間差Tpが大きい場合(本実施形態では、毎月の下旬に相当)、ユーザが持つポイント(あるいはユーザがアイテム利用に使えるお金)の額は、ユーザによって大きく異なる傾向にある。一般的には、時間の経過に従って、ユーザが保有するポイント数は減少するが、アイテム提供サービスをあまり利用しないユーザのポイント数は、ほとんど減少しない。このため、月の下旬にユーザが保有するポイント数は、個人差が大きく、少ないポイントしか保有していないユーザ群と、多くのポイントを保有しているユーザ群の2つのグループに分かれる傾向がある。更に、当月分のポイントが月末で無効になる課金制度を採用するアイテム提供サービスにおいては、自分の保有するポイントを月末までに使い切ろうとする心理がユーザに働く、このため、図15(c)に示すような関数F3(X)を用いて、単体アイテムと複合アイテムの両方とも推薦情報に入り易くすることにより、多くのユーザの購入意欲を高め、サービス全体の売上を増大させることにつながる。
図15に示す関数F1(X)〜F3(X)は、あくまでも例示であり、他の特性の関数を用いてもよい。例えば、F3(X)の代わりに、Y1がY2よりもわずかに大きい関数を用いてもよい。
また、図16に示す非線形の関数F4(X)〜F6(X)を種別影響関数として用いてもよい。本図に示すような非線形関数を用いる場合は、3値以上の種別情報を用いる必要があり、種別情報の値の種類がある程度多いことが望ましい。例えば、あるアイテムに対応する単体アイテムの個数を種別情報として用いるとよい。この場合、単体アイテムの種別情報は「0」、対応する単体アイテムが20個ある複合アイテムの種別情報は「20」、対応する単体アイテムが50個ある複合アイテムの種別情報は「50」といった数値となる。種別情報は典型的には整数値であるが、上述のように実数値となる場合もある。本図では詳細な作図を省略しているが、種別情報が整数値である場合には、関数の定義域は整数値となる。
図16(a)に示すF4(X)は、単調増加(単調減少区間を持たない)非線形関数である。このようなS字特性の関数を用いると、対応する単体アイテムの個数が多い複合アイテムほど、種別影響度が大きくなり、推薦情報に入り易くなる。また例えば、種別情報が「40」の種別影響度と、「50」種別影響度がほぼ同じことから分かるように、種別情報の違いを圧縮して種別影響度に反映することができる。関数F4(X)は、Tpが小さい場合(Tp≦μ1である場合)に用いるとよい。
図16(b)に示すF5(X)は、種別情報が比較的小さい値のときにピーク(極大)となる非線形関数である。関数F5(X)は、時間差Tpが中程度である場合(μ1<Tp≦μ2である場合)に用いるとよい。図16(c)に示すF6(X)は、種別情報が比較的小さい値と、比較的大きな値のときの2箇所でピーク(極大)となる非線形関数である。関数F6(X)は、時間差Tpが大きい場合(μ2<Tp、またはμ2<Tp≦μ3である場合)に用いるとよい。上述のように月の下旬には、少ないポイントしか保有していないユーザ群と、多くのポイントを保有しているユーザ群の2つに分かれる傾向があるため、種別情報が小さい方のピークを前者のユーザ群に対応させ、種別情報が大きい方のピークを後者のユーザ群に対応させることにより、どちらのユーザ群に対しても適合する推薦情報を作成することができる。
更に、図17(a)に示すような階段状の関数F7(X)を用いてもよい。本図の線分の端点の黒丸はその値を含み、白丸はその値を含まないことを示している。本図の例のように階段状の関数を用いると、図16に示すような連続的な関数を用いるよりも比較的処理が単純になり、情報選択装置10の処理負荷を低減することができる。
また、図17(b)に示すような関数F8(X)〜F10(X)を用いてもよい。これら3つの関数は、X≦Xαで最小値Yα、X≧Xβで最大値Yβをとる点では共通であるが、その間のカーブの形状(勾配)が異なっている。このため、所定の出力値(例えば、Y=Yc)を得るための入力値が3つの関数で異なっている。時間差Tpに応じて、F8(X)〜F10(X)を使い分けてもよい。これら3つの関数は、単調減少区間を持たないため、種別情報の大きいアイテムほど種別影響度が高くなるが、その度合いが関数によって異なっている。F8(X)では、種別情報が比較的小さい領域(X<Xc)の出力と、最大出力Yβとの差(倍率)が大きいため、種別情報が比較的小さいアイテムの種別影響度に比べて、種別情報が大きいアイテムの種別影響度が非常に大きくなる。すなわち、3つの関数の中で、種別情報大きいアイテムの優先度合いが最も高い。このため、時間差Tpが小さいときに、ユーザの購買力が最も大きいと判断すれば、3つの関数の中では関数F8(X)を使うとよい。
関数F10(X)は逆に、種別情報が比較的小さい領域の出力と、最大出力Yβとの差(倍率)が小さいため、種別情報が比較的小さいアイテムの種別影響度に比べて、種別情報が大きいアイテムの種別影響度はそれほど大きくない。このため、3つの関数の中で、推薦情報に種別情報が小さいアイテムが入り易い。時間差Tpが大きいときに、ユーザの購買力が最も低いと判断すれば、3つの関数の中では関数F10(X)を使うとよい。関数F9(X)は、F8(X)とF10(X)の中間的な性質である。時間差Tpが中程度であるときに、ユーザの購買力も中程度であると判断すれば、3つの関数の中では関数F9(X)を使うとよい。
通常、種別影響度算出部106は、関数F(X)に従って、入力Xに対する出力Yをあらかじめ算出しておき、算出結果の(X,Y)の情報(対応規則)を記憶領域に格納しておくとよい。例えば、記憶領域のXに相当するアドレスにYの値を格納するLUT(Look-Up
Table)方式を用いることができる。この方式によれば、入力が与えられてから出力するまでに、数式を計算する必要がないので、処理量を少なくすることができ、応答時間を短くすることができる。また、種別情報の種類が非常に多い場合には、種別影響関数F(X)を数式として内部の記憶領域に記憶しておき、入力が与えられるごとに、その数式に従って種別影響度を算出してもよい。この方式によれば、種別情報の種類が非常に多い場合に、必要なメモリ量を少なくすることができ、種別影響度を精度よく(高い解像度で)算出することができる。また種別影響度の値が所定の範囲(0以上1以下など)に収まるような正規化を行なってもよいし、行なわなくてもよい。なお、種別情報が文字列や記号である場合にも、上述の説明と同様な処理を行うことができる。例えば、単体アイテムの種別情報が「単体」、複合アイテムの種別情報が「複合」といった文字列である場合、「単体」という文字列入力に対して、所定値Y1(例えば、「1.0」)を出力し、「複合」という文字列入力に対して、所定値Y2(例えば、「2.0」)を出力するような種別対応規則を用いて種別影響度を算出すればよい。
なお、種別影響度算出部106が、時間差Tpに応じて異なる動作を行うのと同様に、関連度算出部104が、時間差Tpに応じて異なる動作を行うようにしてもよい。この場合、種別影響度算出部106または制御部110が備えるリアルタイムクロック等の計時機能を用いて算出された時間差Tpに基づいて、制御部110が関連度算出部104を制御すればよい。例えば、時間差Tpが小さい場合に、拡張利用アイテム集合作成の第1の方法および拡張関連度算出の第1の方法のうちの少なくとも一方を用いて、推薦情報により多くの複合アイテムが入るようにしてもよい。また例えば、時間差Tpが中程度である場合に、拡張利用アイテム集合作成の第2の方法および拡張関連度算出の第2の方法のうちの少なくとも一方を用いて、推薦情報により多くの単体アイテムが入るようにしてもよい。また例えば、時間差Tpが大きい場合に、拡張利用アイテム集合の作成処理、および拡張関連度の算出処理を行わないようにしてもよい。
<選択指標算出処理>
ステップS420における選択指標算出処理を詳細に説明する。制御部110の指示を受けた情報選択部107は、ステップS410で種別影響度が算出された各関連識別子について、その関連度Wと種別影響度Yとを用いて選択指標Sを算出する。この選択指標Sは、関連度Wが大きいほど、かつ種別影響度が大きいほど大きな値となる数値であり、以下の方法で算出する。
選択指標算出の第1の方法は、[数5]を用いる方法である。
すなわち、利用主体識別子iと関連識別子jとの関連度W[i][j]を基数としてγaを指数とする累乗値を算出し、種別影響度Y[j]を基数としてγbを指数とする累乗値を算出し、それらの乗算値を用いて選択指標S[i][j]を算出する方法である。ここで、βc、γbは0より大きな定数である。また、γaも基本的に0より大きな定数であるが、後述するように、関連度を用いずに選択指標を算出することも可能であり、その場合は、γa=0、γb=1とすることに相当する。
この第1の方法では、関連度と種別影響度が両方とも大きい関連識別子が推薦結果に入りやすい。さらにγaおよびγbを調整することにより、推薦結果に入る関連識別子を変えることができる。
例えば、γaを大きくすることにより、関連度W[i][j]が大きい関連識別子がより推薦結果に入りやすくなる。またγbを大きくすることにより、種別影響度Y[j]が大きい関連識別子がより推薦結果に入りやすくなる。なお、βc=γa=γb=1として、関連度と種別影響度との積を選択指標にしてもよい。
選択指標算出の第2の方法は、[数6]を用いる方法である。
すなわち、関連度W[i][j]とβaとの乗算値と、種別影響度Y[j]とβbとの乗算値を算出し、それらの加算値を選択指標S[i][j]とする方法である。ここで、βaおよびβbは重み係数であり、βbは0より大きな定数である。また、βaも基本的には0より大きな定数であるが、後述するように、関連度を用いずに選択指標を算出することも可能であり、その場合は、βa=0、βb=1とすることに相当する。[数6]は、関連度と種別影響度とをそれぞれ重み付けして加算した値といえる。
第2の方法でも、関連度と種別影響度が両方とも大きな関連識別子が最も推薦結果に入りやすいが、第1の方法と比べると、関連度と種別影響度のいずれかが大きい関連識別子も推薦結果に比較的入りやすい。さらにβaおよびβbを調整することにより、推薦結果に入る関連識別子を変えることができる。
例えば、βaを大きくすることにより、関連度W[i][j]が比較的大きい関連識別子がより推薦結果に入りやすくなる。またβbを大きくすることにより、種別影響度Y[j]が比較的大きい関連識別子がより推薦結果に入りやすくなる。なお、βa=βb=1として、関連度と種別影響度との和を選択指標にしてもよい。
選択指標算出の第3の方法は、[数7]を用いる方法である。
すなわち、関連度W[i][j]の対数値とβdとの乗算値と、種別影響度Y[j]の対数値とβeとの乗算値を算出し、それらの加算値を選択指標S[i][j]とする方法である。ここで、βdおよびβeは0より大きな定数であり、重み係数である。[数7]は、関連度の対数値と種別影響度の対数値とをそれぞれ重み付けして加算した値といえる。また、βdおよびβeを調整することにより、推薦結果に入る関連識別子を変えることができる。なお、βd=βe=1として、関連度と種別影響度との和を選択指標にしてもよい。第3の方法は、関連度または種別影響度のダイナミックレンジが広い場合や、両者のダイナミックレンジが大きく異なる場合に適している。
なお、関連度の代わりに、関連度の順位を用いて、順位が高いほど、かつ種別影響度が大きいほど、大きな値となるように選択指標を算出してもよい。例えば、推薦情報格納部108と同様に、関連度が大きいほど高い順位を示す番号(順位番号)を関連集合格納部105に格納しておき、それを用いるようにすればよい。
また、関連度および種別影響度だけでなく、さらに他の情報を用いて選択指標を算出してもよい。例えば、情報選択部107がアイテム属性格納部101のアイテム情報テーブル101Aを参照して、関連識別子jのアイテム時期情報T[j]を読み出し、関連度W[i][j]が大きいほど、かつ種別影響度Y[j]が大きいほど、かつアイテム時期情報T[j]が新しいほど(処理時点とアイテム時期情報との差が小さいほど)、大きな値となるように選択指標を算出してもよい。
<推薦情報選択処理>
ステップS430における推薦情報選択処理を詳細に説明する。ステップS430において、情報選択部107は、ステップS420で算出された選択指標に基づいて、関連集合の中から関連識別子を選択する。
具体的には、選択指標S[i][j]が所定値θ1以上の関連識別子を関連集合から選択する。または、選択指標S[i][j]が大きい順に所定数η1を超えない数の関連識別子を選択してもよい。例えば、関連集合の要素数が所定数η1に満たない場合は、関連集合の要素をすべて選択し、そうでない場合は、選択指標が大きい順に所定数η1の関連識別子を選択すればよい。
さらに、選択指標が所定値θ2以上の関連識別子を対象にして、選択指標が大きい順に所定数η2を超えない範囲で選択してもよい。この場合、選択指標がθ2以上の関連識別子の数がη2に満たない場合は、θ2以上の関連識別子をすべて選択する。また、利用主体識別子iに対して、所定数η3個以上の関連識別子が選択できるように所定値θ3を利用主体識別子ごとに設定し、選択指標がθ3以上の関連識別子を選択してもよい。
また情報選択部107は、アイテム属性格納部101を参照しながら、種別情報に基づくアイテム数の制限処理を行ってもよい。例えば、複合アイテムと単体アイテムを合わせてη1個選択する場合、複合アイテムの上限数をη4に設定し(η4≦η1)、単体アイテムが(η1−η4)個以上選択されるようにしてもよい。選択指標S[i][j]が大きい順に上位η1個のアイテムの中に、複合アイテムがη4個よりも多く存在する場合は、それらを全て選択するのではなく、そのうちのη4個のみ選択するようにする。そして、選択指標S[i][j]が大きい順に単体アイテムが(η1−η4)個選択されるように、選択候補の範囲(探索範囲)を選択指標の上位η1個から広げる。また例えば、単体アイテムの上限数をη5に設定し(η5≦η1)、複合アイテムが(η1−η5)個以上選択されるようにしてもよい。選択指標S[i][j]が大きい順に上位η1個のアイテムの中に、単体アイテムがη5個よりも多く存在する場合は、それらを全て選択するのではなく、そのうちのη5個のみ選択するようにする。そして、選択指標S[i][j]が大きい順に複合アイテムが(η1−η5)個選択されるように、選択候補の範囲(探索範囲)を選択指標の上位η1個から広げる。
なお、利用履歴格納部102を参照しながら、利用主体識別子iに対応するユーザが既に利用したアイテムを特定し、それらを除外して(利用済み除外処理を行なって)選択集合を作成してもよい。ユーザが1回しか同じアイテムを購入しない性質を持つようなアイテム提供サービスでは、このステップS430において利用済みのものを選択集合から除外しておくと、推薦情報格納部108の記憶容量を節約できる。ステップS430において利用済み除外処理を行なう場合、ステップS170での利用済み除外処理を省略してもよいし、再度行なってもよい。ステップS430を実行した後、ステップS170を実行するまでの間に、新たな利用履歴が格納される可能性がある場合は、両方のステップで利用済み除外処理を行なう方が、推薦精度の向上の面では確実である。
このような方法で選択された関連識別子の選択指標に従って、推薦順位を付与する。すなわち、選択指標が大きいほど、高い推薦順位を付与する。そして、利用主体識別子と、関連識別子と、推薦順位とを対応させて、図6に示す形式で、推薦情報テーブル108Aを推薦情報格納部108に格納させる。以上、推薦情報選択処理を説明した。
第1実施例の最後に、図18を用いて、推薦情報の具体例を説明する。関連集合格納部105には図18(a)に示すような「アイテム推薦形式」のデータが格納されているものとする。本図に示すように、「UserID−1」の関連集合は、「ItemID−13」〜「ItemID−17」の5つのアイテムである。「UserID−2」の関連集合もまったく同じ5つのアイテムであるが、各々の関連度は異なっているものとする。また、図18(b)に示すようにには、「ItemID−11」〜「ItemID−17」の7つのアイテムの種別情報が格納されている。
説明を簡単にするため、時間差Tpが小さく、種別影響関数として図15(a)に示した関数F1(X)を用いることとし、X1が単体アイテム、X2が複合アイテムに対応し、Y1=1、Y2=2とする。情報選択部107では、[数6]を用いて選択指標を算出し、βc=γa=γb=1であるとする。また、情報選択部107は、選択指標の大きい順に3つのアイテムを選択して推薦情報を作成するものとする。
以上の条件において、仮に、種別情報を使わずに関連度だけでアイテムを選択したとすると、図18(a)から明らかなように、「UserID−1」に対応する推薦アイテムは、1位が「ItemID−13」、2位が「ItemID−14」、3位が「ItemID−15」になる。これらの種別情報は各々「0」「0」「1」である。
一方、関数F1(X)を用いて選択指標を算出すると、「ItemID−15」については、「2×0.85=1.7」となる。他のアイテムについても同様に算出した結果を図18(c)に示す。本図において選択指標の大きい順に「UserID−1」に対するアイテムを3つ選択すると、1位が「ItemID−15」、2位が「ItemID−16」、3位が「ItemID−13」となる。各々の種別情報は「1」「1」「0」である。すなわち、関連度だけでアイテムを選択すると推薦情報の中の複合アイテムは1つであるのに対し、複合アイテムが2つに増える。このように、関数F1(X)を用いると、関連度だけでアイテムを選択する場合に比べて、相対的に価格の高い傾向にある複合アイテムを多く推薦結果に入れることができる。
また、種別情報を使わずに関連度だけでアイテムを選択したとすると、「UserID−2」に対応する推薦アイテムは、1位が「ItemID−14」、2位が「ItemID−15」、3位が「ItemID−17」になる。これらの種別情報は各々「0」「1」「1」である。
一方、関数F1(X)を用いて選択指標を算出すると、1位が「ItemID−15」、2位が「ItemID−17」、3位が「ItemID−14」となり、各々の種別情報は「1」「1」「0」である。この場合、複合アイテムの数はどちらも2つで変わらないが、相対的に価格の高い傾向にある複合アイテムが上位の推薦順位となり、ユーザの目に留まりやすくなる。
また、「UserID−1」に対する推薦結果には、複合アイテム「ItemID−16」が入るが、「UserID−2」に対する推薦結果には、これが入らない。このことからも分かるように、種別影響関数として、関数F1(X)を用い、種別影響度と関連度とを用いて選択指標を算出すると、ユーザと推薦アイテムとの関連度が高い場合、すなわちそのユーザが推薦アイテムを気に入る可能性が高い場合にのみ複合アイテムが推薦されるので、ユーザに不自然な印象を与えるリスクが少ない。このため、時間差Tpが小さい時期(ユーザのアイテム利用意欲が一般的に旺盛な時期)に、そのような推薦情報を提供することにより、アイテム提供サービス全体の売上増大につながると期待できる。
なお、上述の説明では、関数F1(X)を種別影響関数に用いる一例を説明したが、時間差Tpに応じて、これとは特性の異なる関数を用いることにより、図18(c)に示す選択指標と異なる値が算出され、推薦情報に入るアイテムが時間差Tpに応じて変化することは明らかである。例えば、相対的に価格の安い単体アイテムを優先的に推薦情報に入れたり、複合アイテムと単体アイテムのどちらも対等に扱うといったことが柔軟にできる。また、より多くの種類の種別情報を用いると、推薦情報に入り易いアイテムの種別をより細かくコントロールすることができる。
本実施形態は、インターネットサービスで広く採用されている月額課金制度、あるいは多くの企業で採用されている月給制度などを鑑み、ユーザがアイテム利用に使えるお金(ポイント等を含む)が時間的、周期的に変化することに着目したものであり、秘匿必要性の高いユーザの個人情報などは利用していないため、幅広い事業、サービスに応用することが可能である。月額課金制度において新たなアイテム利用権がユーザに付与される時点や、給料日を所定の時点とし、この所定の時点と推薦情報の作成に係る時点との時間差、または所定の時点と推薦情報の提供に係る時点との時間差であるTpに応じて、種別影響関数を設定しているため、推薦情報に入れるアイテムの種別、ひいてはアイテムの価格帯を適切なタイミングで調整することができる。このため、推薦情報の提供により、ユーザの購入意欲が増大する可能性を従来技術より大きくすることができ、アイテム提供サービスの売上増大につながる。
また、本実施形態の方法によれば、推薦情報の作成の際に、価格情報を用いていないため、幅広い事業、サービスに応用することが可能である。例えば、情報選択装置10とアイテム提供サーバ20とが、それぞれ別の事業者で運営されているようなアイテム提供システム1においては、アイテム提供サーバ20を運営する事業者が、自社の営業秘密につながる可能性があり、かつ競合他社との関係上、高い頻度で変更される可能性のある価格情報を、他社の運営する情報選択装置10に対して提供することは、営業的または技術的な理由から、困難である場合もあると想定される。一方、アイテム種別情報は、アイテム価格情報に比べて、営業秘密につながる可能性が少なく、かつ一度作成された情報が変更される可能性も少ないので、そのようなアイテム提供システム1においても、使い易い。また、種別情報は、一般的に価格情報に比べて、一度作成された後に変更される可能性が少なく、記憶や演算に必要なデータ量(ビット長)が少なくて済むなどの特性を持っているため、推薦情報の作成において価格情報よりも使い易い場合がある。
なお、第1実施例では、情報選択装置10が、種別影響度を算出し、選択指標を算出して推薦情報を作成するようにしていたが、これらの処理、あるいは、これらの処理の一部を端末装置30側で行なうようにしてもよい。
この場合、端末装置30のアプリケーション部304に、種別影響度算出部106および情報選択部107に相当する動作を行なわせるようにする。例えば、ステップS160に先立つ適当なタイミングで、アプリケーション部304が、アイテム提供サーバ20を経由して、あるいは直接情報選択装置10から、アイテム情報テーブル101A、および関連度テーブル105Aのデータを取得する。このとき、各々のテーブルの全部のデータを取得してもよいし、リクエスト利用主体識別子に関係するデータ等の必要なデータのみを取得するようにしてもよい。そして、ステップS160において、推薦リクエストを送信する代わりに、上述の手順に従って種別影響度を算出し、算出した種別影響度と取得した関連度とを用いて、選択指標を算出することで推薦情報を作成する。具体的には、ステップS410、S420、S430、S170に相当する処理をアプリケーション部304が実行すればよい。この場合、アプリケーション部304に、データ取得部、種別影響度算出部、情報選択部が形成されることになる。以下の実施例においても同様に、情報選択装置10の一部の動作を端末装置30で行なうようにしてもよい。
また、第1実施例では、種別影響度と関連度とを用いて選択指標を算出する例を説明したが、関連度を用いずに、選択指標を算出してもよい。例えば、関連度算出部104および関連集合格納部105を省略し、その代わりに、利用履歴格納部102のデータを用いて、多くのユーザの間で人気の高いアイテムの情報を作成する人気度算出部(図示せず)を設け、この人気度を関連度の代わりに用いて(人気度と種別影響度とを用いて)選択指標を算出してもよい。具体的には、複数のユーザの利用履歴を用いて、アイテムごとの利用数や利用人数を集計し、人気度とすることができる。そして、[数6]または[数7]において、関連度の代わりに人気度を用いて、選択指標を算出すればよい。人気度が高く、かつ種別影響度の高いアイテムの選択指標が大きな値となるため、そのようなアイテムが推薦情報に入り易くなる。人気度を用いる場合、全てのユーザに同じアイテムが推薦されるので、ユーザ個人ごとに異なる関連度を用いる場合に比べて、推薦情報がユーザ個人の嗜好に合致する可能性は低下するが、一般的に人気の高いアイテムなので、やはり推薦効果が期待できる。また、時間差Tpに応じて、種別影響関数の特性が変わるので、関連度を用いる場合と同様に、推薦情報に入れるアイテムの種別を適切なタイミングで調整することができる。
また、アイテム提供サービスの提供者(事業者)が、ユーザに対して薦めたいアイテムの集合と、それぞれのアイテムのお薦め度合いを示す推薦度(提供者推薦度)を用意した上で、提供者推薦度と種別影響度とを用いて、選択指標を算出してもよい。この場合も全てのユーザに対して同じ推薦情報が提供されることになるが、アイテムに関する知識の豊富な専門家(事業者)が選んだアイテムなので、推薦効果が期待できる。推薦度が高く、かつ種別影響度の高いアイテムの選択指標が大きな値となるため、そのようなアイテムが推薦情報に入り易くなる。また、人気度と推薦度と種別影響度とを組合せて、人気度が高く、かつ推薦度が高く、かつ種別影響度が高いほど、選択指標が大きな値となるように算出してもよい。また、関連度と人気度と推薦度と種別影響度とを組合せて、関連度が高く、かつ人気度が高く、かつ推薦度が高く、かつ種別影響度が高いほど、選択指標が大きな値となるように算出してもよい。
また、アイテム情報テーブル101Aのアイテム時期情報に基づき、アイテム時期情報が新しいほど大きな値となる新鮮度を算出し、新鮮度と種別影響度とを用いて、選択指標を算出してもよい。アイテム時期が新しく、かつ種別影響度の高いアイテムの選択指標が大きな値となるため、そのようなアイテムが推薦情報に入り易くなる。一般的に、新しいアイテム(新作)の方がユーザの利用意欲(購買意欲)が高いので、このような新鮮度を用いた場合でも、推薦効果が期待できる。上述の人気度、推薦度(提供者推薦度)、新鮮度は、いずれも選択指標を算出するための補助指標であるとも言える。このような補助指標または関連度と、種別影響度とを組合せて選択指標を算出すると、1種類の種別情報のアイテムのみで推薦情報が構成される可能性が少なくなり、推薦情報の多様性が増える。
また、種別影響度そのものを選択指標としてもよい。例えば、アイテム属性格納部101に格納されている全てのアイテムについて種別影響度を算出し、種別影響度の大きさに基づいて推薦情報を作成してもよい。この場合、選択指標の算出処理を省略できるので、情報選択装置10の処理量を低減することができる。時間差Tpに応じて、
種別影響関数の特性が変わるので、この場合であっても、推薦情報に入れるアイテムの種別を適切なタイミングで調整することができる。例えば、時間差Tpが小さい場合に複合アイテムを優先的に推薦情報に入れ、時間差Tpが大きい場合に単体アイテムを優先的に推薦情報に入れることができる。また3種類以上の種別情報を用いると、時間差Tpが小さい場合に大規模な複合アイテムを優先させ、時間差Tpが中程度の場合に単体アイテムおよび小規模な複合アイテムを優先させ、時間差Tpが大きい場合に単体アイテムおよび中規模な複合アイテムを優先させる等、より細かな制御が可能になる。
(実施例2)
本実施形態に係るネットワークシステムの第2実施例について説明する。第2実施例では、端末装置30を利用するユーザが、好みに応じて、種別影響度を調整することができるようになっている。第2実施例において、アイテム提供サーバ20および端末装置30は、第1実施例と同様とすることができる。
図19は、第2実施例における情報選択装置10bの構成を示すブロック図である。本図に示すように、情報選択装置10bは、アイテム属性格納部101と、利用履歴格納部102と、関連度算出部104と、関連集合格納部105と、種別影響度算出部106bと、情報選択部107bと、推薦情報格納部108と、送受信部109と、制御部110bとを備えて構成されている。また、情報選択装置10bには、情報選択装置10の管理者向けに必要な情報を表示するための表示装置120と、管理者が操作を行なうためのキーボード、マウス等の入力装置130とが接続されている。
すなわち、第2実施例の情報選択装置10bは、第1実施例の情報選択装置10と比べて、種別影響度算出部106、情報選択部107、制御部110の動作が一部異なる構成となっている。
制御部110bは、第1実施例と同様に、所定のタイミングで推薦情報作成動作を開始する。ただし第2実施例では、図13に示した推薦情報を作成する動作のフローチャートにおいてステップS400が終了した段階で推薦情報作成動作を終了する。ステップS410以降に相当する処理は、後述するステップS170bにおいて、表示用推薦データを作成する際に行なう。
第2実施例におけるシステム全体の動作は、処理ステップ間の関係において図10に示したフローチャートと同様であり、処理ステップの具体的内容において第1実施例と一部異なる。以下では、第1実施例と動作が異なる処理ステップにについて説明する。異なる処理ステップについては符号の末尾に「b」を付加して表記する。
図10のステップS130bにおいて、アイテム提供サーバ20の制御部205は、応答データを端末装置30に送信する。第2実施例における応答データ(画面表示情報)には、ユーザが種別影響度を調整するための操作画面を表示する情報が含まれている。なお、情報選択装置1の表示制御情報作成部(図示せず)が、このような応答データを作成し、端末装置30に送信するようにしてもよい。
ステップS140bにおいて、端末装置30は、アイテム提供サーバ20または情報選択装置1から受信した応答データに基づき、表示装置320にその情報を表示する。表示画面の一例を図20に示す。図11に示した第1実施例の表示画面との違いは、画面右上に「種別影響度の調整操作」ボタンが表示される点である。
「種別影響度の調整操作」ボタンは、種別影響度を調整するために必要なデータ(種別影響度調整データ)をユーザに入力させるためのGUI(Graphical
User Interface)を表示させるためのボタンであり、例えば、図21に例示するような画面を表示させることができる。画面移動ではなく、図21に示す情報を、図20の表示画面に含めるようにしてもよい。
図21(a)に示す例は、推薦結果に入れるアイテムの種別を指定するための画面である。複数の期間ごとに、3つの選択肢に対応して、円形のラジオボタンが表示されている。ラジオボタンの横の「1」〜「3」の数字は、ラジオボタンを識別するための番号であり、ユーザに選択されたラジオボタンの番号を端末装置30が読み取れるようになっている。
本図に示す例では、2つの期間が設定されており、それぞれの期間の条件として、月初(毎月1日)からの経過日Tpが表示されている。ユーザは、「10日」、「31日」といった期間の定義(経過日の範囲)を自由に設定、変更できる他、「期間の追加」をボタンを使って、自由に期間を追加できる。例えば、1ヶ月を6つの期間に分ける設定することも可能である。また、期間を選択した状態で、「期間の削除」ボタンを押すと、その期間を削除することができる。ユーザは、期間の設定、およびそれぞれの期間における推薦情報に入れるアイテムの種別に関する希望を設定した後、「決定」ボタンを押すことで、設定完了を端末装置30に伝えることができる。
またユーザは、「キャンセル」ボタンを押すことで、前の設定状態に戻すことができる。本図に示す例では、「単体アイテムを中心に推薦」、「単体/複合アイテムどちらでもよい」、「複合アイテムを中心に推薦」など、やや抽象的な表現の選択肢が用意されており、推薦情報に優先的に入れるアイテム種別をユーザが選択できる。選択肢の表現(文言)がやや抽象的であるため、多様なアイテムが提供されている場合でも、同じ操作画面が使えるというメリットがある。
図21(b)に示す例は、図21(a)に示した例と同じく、推薦結果に入れるアイテムの種別をやや抽象的に指定するための画面であるが、アイテム種別をより細かく、5段階で指定するものである。ラジオボタンの横の「1」〜「5」の数字は、ラジオボタンを識別するための番号であり、ユーザに選択されたラジオボタンの番号を端末装置30が読み取れるようになっている。
図21(c)に示す例は、単体アイテムまたは複合アイテムの推薦数を具体的に指定するための画面である。「単体アイテムを10個以上推薦」、「単体アイテムを5個以上推薦」、「単体/複合の数を制限しない」、「複合アイテムを5個以上推薦」、「複合アイテムを10個以上推薦」などの選択肢が表示される。具体的なアイテムの個数が表示されるので、ユーザにとって分かり易いメリットがある。ただし、本図の例で示す「5個」、「10個」などの個数は、可能な限り、その個数のアイテムを推薦情報に含めるという意味であり、その個数のアイテムが必ず推薦情報に含まれるという保障ではない。また、単体または複合アイテムに関する制限数をユーザが自由に設定できるようにしてもよい。また、「…個以上推薦」ではなく、「…個以下推薦」というように、単体または複合アイテムに関する上限数を選択させるようにしてもよい。また、図21には示していないが、アイテム属性格納部101のアイテム種別情報を3種類以上で構成した上で、アイテム種別情報の値に関する選択肢を設けてもよい。例えば、「対応する単体アイテムの多い複合アイテムを推薦に入れる」、「12個以上の単体アイテムに対応する複合アイテムを中心に推薦」、「20個以上の単体アイテムに対応する複合アイテムは2個以下にする」などの選択肢を用意してもよい。なお図21には示していないが、時間差Tpの起点である所定の時点を、ユーザごとに設定できるようにしてもよい。例えば、毎月1日に新規ポイントがユーザに付与される月額課金のサービスにおいても、ユーザの好みに応じて、1日以外の日を所定の時点に設定できるようにしてもよい。また例えば、ユーザが自分の給料支給日やボーナスポイント支給日に合わせて所定の時点を設定できるようにしてもよい。
ユーザは、図21に例示した画面で「決定」を選択した後、図20に示す関連リンク(「あなたへお薦めのアイテム」ボタン)を選択することで、種別に関する自分の好みが反映された推薦情報を取得することができる。なお、図21に示した種別影響度の調整操作用画面は、あくまでも一例であり、他の方法で、種別影響度の調整を行なってもよい。例えば、図15〜図17に示すような種別影響関数のグラフを期間ごとに表示し、ユーザがマウス、タッチパネル等を用いて、グラフの形状を直接指定したり、修正できるようにしてもよい。
図10のステップSl60bにおいて、端末装置30は、関連リンクに対応するURLに推薦リクエストを送信する。この推薦リクエストには、利用主体識別子に加えて、図21に示した画面で指定された種別影響度調整データが含まれている。例えば、設定された期間の数、それぞれの期間の定義情報、図21に示すラジオボタンの中でユーザに指定されたラジオボタンを識別するための「1」〜「5」などの番号を種別影響度調整データとすることができる。
ステップS170bにおいて、情報選択装置10bの制御部110bは、送受信部109を介して、推薦リクエストを受信し、それに含まれるリクエスト利用主体識別子に対応する表示用推薦データを作成して端末装置30に送信する。以下では、このステップS170bの処理を詳細に説明する。
ステップSl70bでは、第1実施例の推薦情報作成動作の一部である、図13に示したステップS410〜S430に相当する処理(ステップS410b〜S430b)を行なった後に、図示しないステップS450で表示用推薦データを作成する。なお、第2のタイミングで推薦情報を作成する場合は、関連集合を作成した後(ステップS400の後)に、ステップS410b〜440bを実行すればよい。
ステップS410bにおける種別影響度算出処理を詳細に説明する。制御部110bは、関連集合格納部105の中から、推薦リクエスト(リクエスト利用主体識別子)に一致する利用主体識別子を特定し、その利用主体識別子に対応する関連集合(関連識別子)を読み出す。以下では、ここで読み出された関連集合を集合Ψとする。
そしてアイテム属性格納部101を参照しながら、集合Ψの各関連識別子に対応する種別情報を取得し、その種別情報と、受信した種別影響度調整データとを種別影響度算出部106bに入力する。
第2実施例において、種別影響度算出部106bは、ユーザによって入力された種別影響度調整データに応じて、種別情報を入力Xとし種別影響度を出力Yとする種別影響関数F(X)の特性を変化させる。本実施形態においては、所定の時点を毎月1日午前0時とし、時間差Tpは、ステップS410bを実行する時点の毎月1日からの経過日数(経過時間)とする。種別影響度算出部106bは、時間差Tpを算出し、ユーザによって入力された種別影響度調整データの中のどの期間に該当するか判定する。そして、その期間に対応する関数を用いて、種別影響度を算出する。例えば、Tpが15日であり、期間1が10日以下、期間2が10日より大きく31日以下である場合、期間2の関数を用いる。この関数(対応規則)は、第1実施例と同様に、図15に示したような特性の関数を用いることができる。例えば、図21(a)に示す3つの選択肢を用いる場合、「1)単体アイテムを中心に推薦」を図15(b)に示すF2(X)に対応させ、「2)単体/複合アイテムどちらでもよい」を図15(c)に示すF3(X)に対応させ、「3)複合アイテムを中心に推薦」を図15(a)に示すF1(X)に対応させることができる。
図22(a)は、図21(b)の5つの選択肢に対応する5つの関数の一例を示す図である。本図において、X1は単体アイテム、X2は複合アイテムに対応する種別情報であり、X1<X2である。また、種別影響度の大きさに関し、0<Y1<Y2<Y3<Y4<Y5の関係がある。本図の関数Fa1(X)〜Fa5(X)の番号は、それぞれ図21(b)の選択肢1)〜5)に対応している。例えば、Fa1(X)は、選択肢1)に対応する関数である。Fa1(X)は、X1においてY5、X2においてY1をとる関数である。すなわち、負の大きな傾きを持つ(傾きがマイナスであり、その絶対値が大きな)単調減少関数である。単体アイテムの種別影響度が、複合アイテムの種別影響度に比べて非常に大きな値となるため、推薦情報に非常に多くの単体アイテムを含め易い。Fa2(X)は、(X1,Y4)、(X2,Y2)を通る関数である。すなわち、負のやや大きな傾きを持つ単調減少関数である。単体アイテムの種別影響度が、複合アイテムの種別影響度に比べてやや大きな値となるため、推薦情報にやや多くの単体アイテムを含め易い。
Fa3(X)は、(X1,Y3)、(X2,Y3)を通る関数である。すなわち、X軸に並行な関数である。単体アイテムの種別影響度と、複合アイテムの種別影響度が同じ値になるため、単体アイテムと複合アイテムとの違いによる推薦情報への影響がない。Fa4(X)は、(X1,Y2)、(X2,Y4)を通る関数である。すなわち、正のやや大きな傾きを持つ単調増加関数である。複合アイテムの種別影響度が、単体アイテムの種別影響度に比べてやや大きな値となるため、推薦情報にやや多くの複合アイテムを含め易い。Fa5(X)は、(X1,Y1)、(X2,Y5)を通る関数である。すなわち、正の非常に大きな傾きを持つ単調増加関数である。複合アイテムの種別影響度が、単体アイテムの種別影響度に比べて非常に大きな値となるため、推薦情報に非常に多くの複合アイテムを含め易い。以上の説明から明らかなように、関数番号の大きな関数ほど、相対的に複合アイテムの種別影響度が大きくなるため、複合アイテムが推薦情報に入り易くなる。
なお、出力の最小値がある程度大きい(0より大きな値の)関数を用いることで、どのような種別のアイテムも推薦情報に入る確率を0より大きな値にできるので、推薦情報に入れるアイテムの数を十分確保し易いというメリットが得られる。
図21(c)に示す種別影響度の調整操作部の選択肢を用いる場合は、図21(b)に示す選択肢と同様に、1)〜5)の選択肢それぞれを、図22(a)に示す関数Fa1(X)〜Fa5(X)に対応させればよい。そして、後述するように、情報選択部107bにおいて、種別情報に基づくアイテム数の制限処理を行えばよい。
図22に示した関数はあくまでも例示であり、図16に示したような非線形関数を用いても、もちろんよい。また、期間ごとに選択できる関数は、共通であっても異なっていてもよい。例えば、期間1では図15に示すF1(X)〜F3(X)を選択できるようにし、期間2では図16に示すF4(X)〜F6(X)を選択できるようにしてもよい。
種別影響度算出部106bは、Fa1(X)〜Fa5(X)、Fb1(X)〜Fb5(X)などの各関数の数式をあらかじめ記憶領域に記憶しておき、入力された種別影響度調整データに応じて該当する数式を選択して、入力Xが与えられるごとに、その数式に従って種別影響度を算出することができる。標準的な関数の数式だけを記憶しておき、入力Xと種別影響度調整データが与えられるごとに、標準関数の数式を基に他の関数の数式を作成した上で、その数式に従って種別影響度を算出してもよい。関数ごとに入力Xに対する出力Yをあらかじめ算出しておき、算出結果の(X,Y)の情報を記憶領域に格納しておいてもよい。以上、第2実施例のステップS410bを説明した。
選択指標算出を行なうステップS420bは、第1実施例のステップS420とほぼ同じである。ただし、制御部110bは、ステップS410bで読み出された集合Ψを対象に選択指標の算出を行なうように情報選択部107bを制御する。
推薦情報を作成するステップS430bにおいて、情報選択部107bは、ステップS420bで算出された選択指標に基づいて、集合Ψの中から関連識別子を選択する。具体的には、第1実施例で説明した方法を用いればよい。なお、図21(a)に示す例では、「…を中心に」などの抽象的な表現を用いて、単体アイテムの個数または割合に関する選択肢(条件)が1つと、複合アイテムの個数または割合に関する選択肢(条件)が1つ用意されている。このように、同じアイテム種別に関して1種類の選択肢を用意する場合は、種別影響度そのものを選択指標とすることも可能である。もちろん、関連度または補助指標(人気度、推薦度、新鮮度など)と組合せて選択指標を算出してもよい。
また、図21(b)に示したように、「やや多く」、「非常に多く」などの表現で、同じアイテム種別に関する2種類以上(2段階以上)の選択肢を用意する場合は、種別影響度そのものを選択指標とせずに、種別影響度と他の指標とを組合せて選択指標を算出する。例えば、種別影響度と関連度との組合せ、または種別影響度と人気度との組合せ、または種別影響度と推薦度(提供者推薦度)との組合せ、または種別影響度と新鮮度との組合せなどである。
また、図21(c)に示したように、「5個以上」、「10個以上」などの具体的な個数を用いた選択肢を用意する場合は、第1実施例の情報選択部107の動作において説明したように、種別情報に基づくアイテム数の制限処理を行う。例えば、全部で20個の推薦アイテムの中に、複合アイテムを10個以上入れる場合、選択指標の上位20個のアイテムの中に、複合アイテムが10個以上含まれていれば、その20個のアイテムを選択する。一方、選択指標の上位20個のアイテムの中に含まれる複合アイテムがη6個(ただし、η6<10)である場合、上位21個目以降のアイテムから、選択指標の大きい順に(10−η6)個の複合アイテムを選択すると共に、上位20個以内の単体アイテムを対象に、選択指標の小さい順に(10−η6)個の単体アイテムの選択を解除することにより、10個の複合アイテムと10個の単体アイテムを選択する。
また、選択された関連識別子の選択指標に従って、推薦順位を付与する。そして、利用主体識別子と、関連識別子と、推薦順位とを対応させて、推薦情報テーブル108Aを推薦情報格納部108に格納させる。
第2実施例では、ステップS430bに続いて、図13では図示していないステップS450を行なう。第2実施例のステップS450では、第1実施例のステップS170と同様な処理を行なえばよい。すなわち、制御部110bは、アイテム属性格納部101と推薦情報格納部108とを参照しながら、ステップS430bで選択された関連アイテム識別子に対応するアイテム属性情報を読み出し、関連アイテム識別子と、推薦順位と、アイテム属性情報とを対応させた表示用推薦データを作成し、送受信部109を介して端末装置30に送信する。なお、第1実施例で説明したように、推薦順位の高い順に所定個数選択したアイテムのみを表示用推薦データに入れたり、過去の利用回数が所定数以上のアイテムを表示用推薦データに含めない等の処理を行なってもよい。
この表示用推薦データには、ステップS180において端末装置30が推薦リストを表示する際に、図23に示すように、「種別影響度の調整操作」ボタン、関連リンク(「あなたへお薦めのアイテム」ボタン)をそれぞれ表示するためのデータを含めてもよい。
この場合、ユーザは、本図の右上部に示す「種別影響度の調整操作」ボタンを指定して、種別影響度の調整操作を再度行なった後に、本図の下部に示す関連リンクを指定することにより、再度設定した種別影響度に応じた新たな推薦情報を表示させることができる。このような方法を用いることで、ユーザは簡単な操作で、納得がいくまで種別影響度を繰り返し調整することができるので、推薦情報に対するユーザの満足度や信頼感を高めることができる。
また、本図の「指定された種別影響度…」で示すように、ステップS140bにおける種別影響度の調整操作でユーザによって指定された内容(選択肢など)を画面に表示するためのデータを、表示用推薦データに含めてもよい。このようにすれば、ユーザが種別影響度の調整操作を繰り返し行なって、少しずつ推薦情報を変更したいような場合に、ユーザは前回指定した条件を容易に知ることができるので、同じ条件を再度指定するような間違いが減り、操作性が向上する。
以上が第2実施例におけるシステム動作の説明である。第2実施例によれば、所定の時点からの経過時間に応じて、推薦情報に入れるアイテム種別をコントロールすることが可能である等、第1実施例と同様な効果を得ることができる。さらに第2実施例では、それらの効果に加えて、端末装置30を利用するユーザが自分の好みに応じて、所定の時点からの経過時間(期間)別に推薦結果に多く含めるアイテムの種別を調整することができるので、ユーザが推薦情報を納得して受け入れやすくなる。
例えば、毎月1日に新しいポイント(新たなアイテム利用権)が付与された直後に、予定以上に高額の商品を購入してしまう傾向があると自覚しているユーザ(ユーザA)は、毎月上旬に相対的に価格の安い単体アイテム中心に推薦されるようにあらかじめ設定しておけば、安心してサービスを利用することができる。また、毎月月末までにポイントを使い切れずに、ポイントを失効させてしまうこケースが多いと自覚しているユーザ(ユーザB)は、毎月下旬に相対的に価格の高い複合アイテム中心に推薦されるように設定しておけば、単体アイテムを多くの回数利用する場合よりも、少ない利用操作で手持ちのポイントを使い切ることができる。またユーザは、上述の所定の時点や各期間を自由に設定することができるため、自分の好みや都合に合わせて、推薦情報の変化をより細かくコントロールすることができる。このように、ユーザの利便性や納得感が向上するため、推薦情報に基づくアイテム利用が活発になり、アイテム提供サービスの売上をさらに増大させることが期待できる。
(実施例3)
本実施形態に係るネットワークシステムの第3実施例について説明する。第3実施例では、端末装置30を利用するユーザが過去に利用したアイテムの種別に基づいて、種別影響度を算出する関数の特性をユーザごとに変えることができるようになっている。第3実施例において、アイテム提供サーバ20および端末装置30は、第1実施例と同様とすることができる。
図24は、第3実施例における情報選択装置10cの構成を示すブロック図である。本図に示すように、情報選択装置10cは、アイテム属性格納部101と、利用履歴格納部102と、関連度算出部104と、関連集合格納部105と、種別影響度算出部106cと、情報選択部107cと、推薦情報格納部108と、送受信部109と、制御部110cと、利用種別情報算出部111と、利用種別情報格納部112とを備えて構成されている。また、情報選択装置10cには、情報選択装置10の管理者向けに必要な情報を表示するための表示装置120と、管理者が操作を行なうためのキーボード、マウス等の入力装置130とが接続されている。
すなわち、第3実施例の情報選択装置10cは、第1実施例の情報選択装置10に利用種別情報算出部111および利用種別情報格納部112を追加し、種別影響度算出部106、情報選択部107、制御部110の動作が一部異なる構成となっている。
制御部110cは、第1実施例と同様に、所定のタイミングで推薦情報作成動作を開始する。ただし本実施形態では、図13のフローチャートにおいてステップS400の後に、図示しないステップS415を実行し、ステップS415が終了した段階で推薦情報作成動作を終了する。種別影響度算出を行なうステップS410以降に相当する処理は、後述するステップS170cにおいて、表示用推薦データを作成する際に行なう。
ステップS415において、制御部110cの指示を受けた利用種別情報算出部111は、利用履歴格納部102を参照しながら、ユーザが利用したアイテムの種別に関する情報である利用種別情報を、所定の時点と推薦情報の作成に係る時点との時間差、または所定の時点と推薦情報の提供に係る時点との時間差Tpに応じた期間ごと、およびユーザごとに算出する。利用種別情報は、ユーザが利用したアイテムの種別に関する統計量である。
本実施形態では、月額課金制度を採用するアイテム利用サービスにおいて、新規のアイテム利用権(新規ポイント)が毎月1日午前0時にユーザに付与されるものとし、毎月1日午前0時を所定の時点とする。そして、推薦情報の作成に係る時点との時間差Tpを、月の上旬(例えば、1日から10日まで)、中旬(例えば、11日から20日まで)、下旬(例えば、21日以降)に対応する3つの期間に分ける例を用いて説明する。また、本実施形態では、利用履歴格納部102には、図5(b)に示すアイテム利用履歴テーブル102A−2が格納されているものとする。すなわち、アイテム利用時期情報(アイテムがユーザに提供された日時などの時点を示す情報)がアイテム利用履歴に含まれている。なお、利用種別情報における利用は、情報閲覧、視聴等を含めずに、実際に購入した場合に限定してもよい。
利用種別情報算出部111は、期間1(毎月1日から10日まで)、期間2(毎月11日から20日まで)、期間3(毎月21日以降)ごとに、ユーザの利用種別情報を算出する。利用種別情報として、例えば、特定のアイテム種別に関する、ユーザの利用の多さを指標化した種別水準値と、特定のアイテム種別に関する、ユーザの利用のばらつき度合いを指標化した種別分散値とを用いることができる。以下の説明においては、この特定のアイテム種別として、複合アイテムを用いる例を説明するが、これに限定される訳ではない。例えば、この特定のアイテム種別として、単体アイテムを用いてもよい。また、複合アイテム全般ではなく、「対応する単体アイテムが10個以上の複合アイテム」、「大規模な複合アイテム」などを、この特定のアイテム種別とし、利用種別情報を算出することもできる。
ここでは、利用種別情報算出部111は、以下に示す第1〜第6の利用種別情報のうち、1つ以上の値を算出するものとする。以下では1つの期間(例えば、上旬に該当する期間1)の処理を説明するが、他の期間についても同様である。また、もちろん3つ以外の期間を用いてもよいし、1ヶ月とは異なる周期を用いてもよい。
利用種別情報算出部111は、利用履歴格納部102に格納された利用履歴から、利用時期情報が特定の条件を満たす利用履歴を読み出す。例えば、利用時期情報の日付が1日から10日に該当するデータを上旬用の利用種別情報を算出するためのデータとして読み出す。そして、読み出した利用履歴に含まれる利用主体識別子ごとに、その期間の利用種別情報を算出する。なお、利用種別情報を算出する際に、推薦情報を作成する当月の利用履歴を用いてもよいし、用いなくてもよい。例えば、2012年12月10日に推薦情報を作成する場合、期間1(毎月1日から10日まで)の利用種別情報を算出するために、前月までの期間1に相当する2ヶ月分のデータ、すなわち、アイテム利用時期情報が、「2012年10月1日〜10月10日」および「2012年11月1日〜11月10日」の範囲にある利用履歴を用いてもよい。あるいは、これらに加えて、当月の「2012年12月1日〜12月9日」の利用履歴を用いてもよい。あるいは、前月までのデータを使わずに、当月の「2012年12月1日〜12月9日」である利用履歴のみ用いてもよい。
なお、アイテム利用時期が「2012年10月1日〜10月10日」の範囲にある利用履歴を期間1に対応させる処理は、所定の時点(2012年12月1日)から所定の時間(2ヶ月)遡った時点(2012年10月1日)を起点とし、その起点からアイテム利用時期との時間が所定値(10日)以下である利用履歴を期間1に対応させる処理ともいえる。アイテム利用時期が「2012年11月1日〜11月10日」の範囲にある利用履歴を期間1に対応させる処理は、起点を2012年11月1日にした同様の処理であり、「2012年12月1日〜12月9日」の範囲にある利用履歴を期間1に対応させる処理は、起点を所定の時点(2012年12月1日)にした同様の処理といえる。
第1の利用種別情報である第1の種別水準値は、ユーザの利用した複合アイテムに関する利用回数または種類数を用いた値である。第1の種別水準値を算出する場合、利用種別情報算出部111は、アイテム属性格納部101、および読み出した利用履歴を参照しながら、ある利用主体識別子(あるユーザ)が利用した複合アイテムを特定する。そして、その利用回数または種類数(アイテム数)をカウントして第1の種別水準値とする。例えば、あるユーザが利用した複合アイテムが1種類であり、その複合アイテムを3回繰り返して利用している場合、種類数である「1」を用いてもよいし、利用回数である「3」を用いてもよい。第1の種別水準値が大きいユーザは、購買能力の高いユーザと推測できる。
なお、複合アイテムの利用回数または種類数そのものではなく、利用回数または種類数に所定の値を乗じた値や、利用回数または種類数を所定の値で割った値を第1の種別水準値としてもよい。例えば利用回数または種類数、の桁数が大きくなるような場合に、所定の値で割って扱いやすい桁数の値にしたり、各々の利用種別情報の最大値が「1」になるような正規化を行なってもよい。また、会員期間が異なるユーザ(例えば、会員期間が1ヶ月のユーザと5年間のユーザ)の利用した複合アイテムの利用回数または種類数は大きく異なる場合があるので、利用回数または種類数をそれぞれのユーザの会員期間に応じた長さで割って正規化を行ってもよい。
第2の利用種別情報である第2の種別水準値は、ユーザの利用した複合アイテムの割合を用いた値である。第2の種別水準値を算出する場合、利用種別情報算出部111は、アイテム属性格納部101、および読み出した利用履歴を参照しながら、ある利用主体識別子(あるユーザ)が利用したアイテムを特定し、アイテムの種別ごとに利用回数をカウントする。そして、複合アイテムの利用回数を、全アイテムの利用回数で割った値(割合)を、その利用主体識別子に対応する第2の種別水準値とする。あるいは、ある利用主体識別子(あるユーザ)が利用したアイテムに関し、アイテムの種別ごとにアイテムの種類数をカウントし、複合アイテムの種類数を全アイテムの種類数で割った値(割合)を、第2の種別水準値としてもよい。また、利用回数の多いアイテムに大きな重みを付ける等、利用回数に応じた重みづけ行なって割合を算出してもよい。第2の種別水準値が大きいユーザは、複合アイテムを好むユーザと推測できる。
第3の利用種別情報である第1の種別分散値は、ユーザの複合アイテムの利用度合いに関するばらつきの大きさ(ばらつき度)を示す値である。具体的には、まず、読み出した利用履歴を複数のグループに分割する。例えば、「2012年10月」、「2012年11月」、「2012年12月」の3つの月に関する利用履歴を読み出した場合、それぞれの月ごとに3つのグループを形成すればよい。なお、必ずしも月ごとにグループを形成する必要はなく、利用履歴の利用時期情報に基づき、2以上の任意の数のグループを形成することができる。また例えば、Nv個の利用履歴を読み出した場合、0〜1の範囲に収まる乱数をNv回発生させ、その値が0.1以下であればグループ1に対応させ、0.1より大きく0.2以下であればグループ2に対応させ、0.2より大きく0.3以下であればグループ3に対応させる等のルールを用いて、1個目の乱数が0.1以下であれば、1個目の利用履歴をグループ1に対応させる等の処理を行い、10個のグループを形成してもよい。そしてグループごとに、第1の種別水準値または第2の種別水準値を算出する。そして、算出された種別水準値のばらつき度を示す値を算出し、その利用主体識別子に対応する第1の種別分散値とする。ばらつき度を示す値として、分散、標準偏差、範囲(最大値−最小値)、四分位範囲(第3四分位値−第1四分位値)などを用いることができる。例えば、10個のグループを形成した場合、10個の種別水準値が算出されるので、それらの分散を算出すればよい。第1の種別分散値が大きいユーザは、利用するアイテムの種別が一定しないユーザと推測できる。
上述した方法では、ある利用主体識別子(あるユーザ)が利用したアイテム(あるユーザの利用履歴)のみを用いて、第1〜第3の利用種別情報を算出するが、あるユーザおよび他のユーザの利用履歴を用いて算出してもよい。すなわち、あるユーザ(ユーザA)以外のユーザが利用したアイテムの種別に基づいて、ユーザAの利用種別情報を算出してもよい。
例えば、利用種別情報算出部111が利用履歴格納部102から読み出した利用履歴に、Nu人の利用主体識別子が含まれているとして、利用主体識別子ごとに、上述した第1の利用種別情報(第1の種別水準値)であるPs[u](u=1〜Nu)を算出し、Ps[u]の平均値Paと標準偏差Pbとを算出する。そして[数8]に従ってユーザuの標準得点S[u]、または偏差値等を算出し、第4の利用種別情報として用いることができる。
この第4の利用種別情報は、第3の種別水準値であり、あるユーザ(ユーザu)が利用した複合アイテムに関する利用回数または種類数が、ユーザ集団の中でどの位置にあるかを相対的に示す情報である。第2〜第3の利用種別情報についても、同様にユーザ集団の中での相対値を算出し、第5〜第6の利用種別情報とすることができる。また、上述の利用種別情報それぞれについて、最大値を1、最小値を0にする等の正規化処理を行ってもよい。また、上述の説明では、1つのアイテム種別(複合アイテム)に関する利用種別情報を算出しているが、複数種類のアイテム種別に関する利用種別情報を算出してもよい。例えば、単体アイテム、小規模複合アイテム、中規模複合アイテム、大規模複合アイテムの4つのアイテム種別に関して、それぞれ第1〜第3の3種類の利用種別情報を算出し、合計12種類の利用種別情報するようにしてもよい。
また利用種別情報算出部111は、ある利用主体識別子に対して、アイテム区分ごとに利用種別情報を算出してもよい。ここで、アイテム区分とは、アイテムを所定の基準で分類した情報であり、通常はカテゴリよりも上位の概念の分類である。例えば、アイテム提供サービスにおいて、種々のコンテンツを提供する場合、「音楽」「映画」「書籍」といった上位の階層の分類をアイテム区分とし、アイテム区分が「音楽」のアイテムに対しては、「ロック」「ジャズ」「クラシック」「フォーク」等のジャンル情報をカテゴリとすることができる。アイテム区分が「映画」のアイテムに対しては、「SF」「アクション」「コメディ」「アニメ」「サスペンス」等のジャンル情報をカテゴリとすればよい。
この場合は、アイテム属性格納部101に、各アイテムと、各アイテム区分とを対応させたアイテム区分情報を格納しておく。そして、利用種別情報算出部111はアイテム区分情報を参照しながら、ユーザが利用したアイテムのアイテム区分を特定し、アイテム区分ごとに利用種別情報を算出する。上記の例では、「音楽」に対応する利用種別情報と、「映画」に対応する利用種別情報と、「書籍」に対応する利用種別情報とを算出する。ただし、カテゴリをそのままアイテム区分とするようにしてもよい。
利用種別情報算出部111は、算出した利用種別情報を利用種別情報格納部112に格納させる。利用種別情報格納部112は、図25に示すような形式で、利用主体識別子と、利用種別情報とを対応させて、期間(期間1、期間2、期間3)ごとに格納する。図25(a)は、アイテム区分を用いない場合の格納形式である利用種別情報テーブル112Aを示している。複数種類(Np個)の利用種別情報が格納されているが、1種類の利用種別情報を格納するようにしてもよい。本図における「NULL」は、該当するデータが存在しないことを示すものである。例えば、期間3において、「UserID−2」の行は、利用履歴が全く、あるいは十分な量が存在しないため、利用種別情報が存在しない。このように、一部の期間の利用種別情報が欠落している利用主体識別子が存在していてもよい。
利用種別情報が存在しない場合は、その期間のユーザ全体の平均的な利用種別情報を用いてもよいし、その利用主体識別子に関する他の期間の利用種別情報で代用してもよい。また、他のユーザの利用種別情報を用いて、欠落している情報を埋めてもよい。具体的には、「UserID−2」の利用種別情報が存在する期間1と期間2において、「UserID−2」の利用種別情報と類似する利用種別情報を持つ他のユーザを特定し、そのユーザの期間3における利用種別情報を用いて、期間3における「UserID−2」の利用種別情報を算出してもよい。例えば、期間1と期間2において、「UserID−2」と利用種別情報がほぼ同じであるユーザとして、「UserID−5」と「UserID−6」(図示せず)を特定した場合、期間3において、これら2人のユーザの利用種別情報の平均値を「UserID−2」の利用種別情報として算出してもよい。
図25(b)は、アイテム区分を用いる場合の格納形式である利用種別情報テーブル112Bを示している。アイテム区分1に対応するNp1個の利用種別情報と、アイテム区分2に対応するNp2個の利用種別情報を、期間(期間1、期間2、期間3)ごとに格納している。ここで、Np1≠Np2として、アイテム区分ごとに異なる数の利用種別情報を算出して格納するようにしてもよい。以上がステップS415の説明である。
第3実施例におけるシステム全体の動作は、処理ステップ間の関係において図10に示したフローチャートと同様であり、ステップS160とS170の具体的内容において第1実施例と一部異なる。第3実施例におけるこれらの処理ステップは、末尾に「c」を付加して表記する。
ステップSl60cにおいて、端末装置30は、関連リンクに対応するURLに推薦リクエストを送信する。ステップS170cにおいて、情報選択装置10cの制御部110cは、送受信部109を介して、推薦リクエストを受信し、それに含まれるリクエスト利用主体識別子に対応する表示用推薦データを作成して端末装置30に送信する。以下では、このステップS170cの処理を詳細に説明する。
ステップSl70cでは、第1実施例の推薦情報作成動作の一部である、図13に示したステップS410〜S430に相当する処理(ステップS410c、S420c、S430c)を行なった後に、図示しないステップS450で表示用推薦データを作成する。なお、第2のタイミングで推薦情報を作成する場合は、利用種別情報を算出した後(ステップS415の後)にステップS410c〜440cを実行すればよい。このうち、ステップS420c、S430c、S450は、それぞれ第2実施例のステップS420b、S430b、S450と同じであるため説明を省略し、ステップS410cにおける種別影響度算出処理について詳細に説明する。
制御部110cは、関連集合格納部105の中から、推薦リクエストに含まれるリクエスト利用主体識別子に一致する利用主体識別子を特定し、その利用主体識別子に対応する関連集合(関連識別子)を読み出す。以下では、ここで読み出され関連集合を集合Ψとする。
そして、制御部110cは、アイテム属性格納部101を参照しながら、集合Ψの各関連識別子に対応する種別情報を取得し、その種別情報と、リクエスト利用主体識別子とを種別影響度算出部106cに入力する。利用種別情報格納部112に、図25(b)に示したアイテム区分ごとに利用種別情報が格納されている利用種別情報テーブル112Bを格納している場合には、制御部110cは、アイテム属性格納部101のアイテム情報テーブル101Aを参照しながら、関連識別子に対応するアイテム区分を特定し、そのアイテム区分も加えて種別影響度算出部106cに入力する。
種別影響度算出部106cは、利用種別情報格納部112を参照しながら、入力された利用主体識別子に応じて、種別情報を入力Xとし種別影響度を出力Yとする種別影響関数F(X)の特性を変える。この関数(対応規則)は、第1実施例と同様に、図15〜図17、および図22に示したような種々の特性の関数を用いることができる。
種別影響度算出部106cは、実施例1と同様に、所定の時点と推薦情報の作成に係る時点との時間差、または所定の時点と推薦情報の提供に係る時点との時間差Tpを算出する。本実施形態においては、所定の時点は毎月1日の午前0時であり、そこからの経過日数(経過時間)が時間差Tpとなる。また、月を3つの期間に分けて処理を行うので、算出したTpが3つのうちのどの期間に該当するか判定する。そして種別影響度算出部106cは、入力された利用主体識別子に対応し、かつ時間差Tpに該当する期間に対応する利用種別情報を利用種別情報格納部112から読み出す。利用種別情報格納部112に、図25(b)に示した利用種別情報テーブル112Bを格納している場合には、入力された利用主体識別子に対応し、かつ時間差Tpに該当する期間に対応し、かつ入力されたアイテム区分に対応する利用種別情報を読み出す。
ここでは、利用種別情報格納部112に、ユーザuの種別水準値L[u]が1つ、ユーザuの種別分散値V[u]が1つ格納されており、これらを読み出して利用することとする。ただし、種別水準値と種別分散値のどちらか一方を利用してもよいし、3つ以上の利用種別情報を利用して関数F(X)の特性を決定してもよい。
上述のように、図22(a)は、Fa1(X)〜Fa5(X)(Fa1〜Fa5)の5つの関数を示している。添字番号の大きい関数ほど、単体アイテムの種別影響度が小さくなり、複合アイテムの種別影響度が大きくなる。種別影響度算出部106cは、ユーザuの種別水準値L[u]に応じて、いずれかの関数を選択する。
具体的には、時間差Tpに該当する期間(当該期間)の種別水準値L[u]に関する閾値δ1〜δ4(δ1<δ2<δ3<δ4)を用意しておき、L[u]<δ1であればFa1、δ1≦L[u]<δ2であればFa2、δ2≦L[u]<δ3であればFa3、δ3≦L[u]<δ4であればFa4、δ4≦L[u]であればFa5を選択する。
この結果、種別水準値の大きいユーザ、すなわち購買能力の高いユーザや複合アイテムを好むと推定されるユーザに対しては、相対的に価格の高い複合アイテムが多く推薦され、種別水準値の小さいユーザに対しては、相対的に価格の安い単体アイテムが多く推薦される。
別の選択方法を、図22(b)を参照して説明する。本図は、Fb1(X)〜Fb5(X)(Fb1〜Fb5)の5つの関数を示しており、添字番号の大きい関数ほど、出力最大値Yβと出力最小値Yαとの差(出力最小値Yαに対する出力最大値Yβの倍率)が大きく、添字の小さい関数ほど、その差および倍率が小さくなっている。また、これらの関数は全て単調増加関数である。
種別水準値L[u]に関する閾値δ1〜δ4(δ1<δ2<δ3<δ4)を用意しておき、L[u]<δ1であればFb1、δ1≦L[u]<δ2であればFb2、δ2≦L[u]<δ3であればFb3、δ3≦L[u]<δ4であればFb4、δ4≦L[u]であればFb5を選択する。すなわち、種別水準値L[u]が大きいほど添字番号の大きい関数を選択することにより、種別水準値が大きいほど、出力最大値と出力最小値との差(出力最小値に対する出力最大値の倍率)が大きくなる傾向で種別影響関数を変化させているといえる。また、種別水準値が大きいほど、入力が最小値であるときの出力値が小さくなる傾向で種別影響関数を変化させているともいえる。この結果、種別水準値が大きいユーザでは、相対的に価格の高い複合アイテムが非常に推薦情報に入り易くなるのに対し、種別水準値が小さいユーザでは、複合アイテムがやや優先的ではあるものの、相対的に価格の安い単体アイテムも比較的推薦結果に入り易いという効果が得られる。
このように、単調増加関数を用いると、全てのユーザに対して、相対的に価格の高い複合アイテムを優先的に推薦情報に入れることができると同時に、ユーザの利用種別情報(すなわちユーザの利用状況)に応じて、その優先度合いを適応的に設定することができる。なお、複数の関数(例えば、Fb1(X)〜Fb5(X))を用意するのではなく、1つの関数のみを用意し、種別水準値に応じて、その関数を変形して用いるようにしてもよい。例えば、Fb3(X)を用意し、種別水準値L[u]と乗算した関数(値)(Fb3(X)×L[u])を種別影響度としてもよい。また、種別水準値に応じて、用意した関数の最大値および最小値のうちの少なくとも一方を変更してもよい。また、種別水準値L[u]とは別に、種別水準値L[u]が大きいほど大きな値となる係数K[u]を算出し、用意した関数との乗算を行って、種別影響度を算出してもよい。種別水準値L[u]と係数K[u]との関係は、線形でも非線形でもよい。
また、種別水準値L[u]ではなく、ユーザuの種別分散値V[u]を用いて、Fb1(X)〜Fb5(X)を選択してもよい。種別水準値L[u]の場合と同様に、種別分散値V[u]に関する閾値ε1〜ε4(ε1<ε2<ε3<ε4)を用意しておき、種別分散値V[u]が大きいほど添字番号の大きい関数を選択する。すなわち、種別分散値が大きいほど、出力最大値と出力最小値との差(出力最小値に対する出力最大値の倍率)が大きくなる傾向で種別影響関数を変化させてもよい。
一般に、種別分散値が小さなユーザは、限られた種別のアイテムを利用する傾向がある。すなわち、自分なりの利用パターンが確立しているユーザであるといえる。このようなユーザでは、複合アイテムだけを推薦した場合に受容されないリスクがより高いため、種別水準値を用いず、種別分散値のみで、単調増加の特性を持つ種別影響関数を設定する場合は、関数Fb1(X)などを用いて、複合アイテムと単体アイテムとの種別影響度の差があまり大きくないようにし、相対的に価格の安い単体アイテムも比較的推薦結果に入り易いようにする。
次に、ユーザuの種別水準値L[u]と種別分散値V[u]を両方用いて、関数F(X)の特性を動的に設定する方法を説明する。なお、関数F(X)の特性を動的に設定する例における種別情報は、単体/複合を示す2値ではなく、3値以上であり、例えば、複合アイテムに対応する単体アイテムの個数を用いるものとする。例外はあるものの、一般的には、種別情報の値が大きいほど、価格が高い傾向にあるといえる。また以下では、時間差Tpに応じて、複数種類のひな型関数を使い分ける例を説明するが、もちろん1種類のひな型関数を用いてもよい。種別影響度算出部106cは、時間差Tpが期間1(月の上旬)に該当する場合に、図26(a)に示す特性のひな型関数Fu(X)を用いる。本実施形態では、毎月1日にユーザに新規のアイテム利用権が付与されるサービスを例に説明しているが、新規のアイテム利用権が付与されてから間もない月の上旬は、一般的にユーザのアイテム利用意欲が高いため、価格の高いアイテムを推薦しても、ユーザのアイテム利用意欲が低下するリスクが小さい考えられる。そこで、図26(a)に示すような単調減少区間を持たないひな型関数を用いて、種別情報が大きいほど(ひいては価格が高いほど)種別影響度が大きくなるようにすると、サービス全体の売上増大に効果的である。種別影響度算出部106cは、このようなひな型関数の数式を内部の記憶領域に記憶しており、種別水準値L[u]および種別分散値V[u]に応じて、Fu(X)のパラメータXc、Xω、Yα、Yωを設定し、種別影響度を算出する。ここで、Xcは単調増加区間のX方向(Xα〜Xβ)の中点であり、Xωは単調増加区間のX方向の幅である。また、Yαは単調増加区間の最小出力値であり、Yωは単調増加区間のY方向の幅である。
まず、Xcを種別水準値L[u]が大きいほど大きな値となるように設定する。そして、Xωを種別分散値V[u]が大きいほど大きな値となるように設定する。この結果、単調増加区間の最小入力値Xαと最大入力値Xβとが設定される。
次に、Yαを種別水準値L[u]が小さいほど大きな値となるように設定する。そして、Yωを種別水準値L[u]が大きいほど大きな値となるように設定する。この結果、単調増加区間の最大出力値Yβが設定される。
このようにパラメータが設定された関数Fu(X)の特性について、図26(b)および図26(c)を参照し、ユーザu1〜ユーザu5の5人のユーザを例にして説明する。
ユーザu1は、単体アイテムのみを利用するため、ユーザu1の種別水準値L[u1]が5人のユーザの中で最も小さく、種別分散値V[u1]も小さいものとする。図26(b)に示すように、ユーザu1に対応した関数Fu1(X)は、Xc1、Xα1、Xβ1、Xω1、Yω1が小さく、Yα1が大きい。このため、種別情報の小さいアイテム(単体アイテム)と、種別情報の大きいアイテム(大規模な複合アイテム)との種別影響度の差(倍率)が小さい等により、5人のユーザの中で単体アイテムが最も推薦結果に入りやすくなる。
ユーザu2は、種別情報の小さいアイテムと大きいアイテムの両方を利用するが、種別情報の大きいアイテムをより多く利用するため、種別水準値L[u2]が5人の中で2番目に小さく、種別分散値V[u2]は大きいものとする。図26(b)に示すように、ユーザu2に対応する関数Fu2(X)のパラメータであるXc2、Xω2、Yα2、Yω2は、それぞれXc1<Xc2、Xω1<Xω2、Yα2<Yα1、Yω1<Yω2となる。このため、種別情報の小さいアイテムと種別情報の大きいアイテムとの種別影響度の差(倍率)がFu1より大きくなり、ユーザu1に比べると、単体アイテムが推薦結果に入りにくくなる。また、単調増加区間の幅Xω2が大きく、単調増加区間の勾配が比較的緩やかであるため、幅広い種別情報のアイテムが推薦結果に入り易くなる。ユーザu2は、単体アイテムと複合アイテムの両方を利用するユーザであるため、アイテム属性に関するユーザの日頃の利用傾向を反映した推薦情報が得られるといえる。
ユーザu3は、種別情報が中程度のアイテム(中規模な複合アイテム)のみ利用するため、種別水準値L[u3]は、ユーザu2の種別水準値L[u2]と同じであり、種別分散値V[u3]は、ユーザu2よりも小さいものとする。図26(b)に示すように、ユーザu3に対応する関数Fu3(X)のパラメータであるXc3、Xω3、Yα3、Yω3は、それぞれXc2=Xc3、Xω3<Xω2、Yα2=Yα3、Yω2=Yω3となる。このため、関数Fu2よりも出力値が大きくなる範囲の種別情報(線分P1で示す範囲の種別情報)を持つアイテムが、ユーザu2と比べて推薦結果に入りやすくなる。
また、ユーザu2では、関数Fu3が最大値となり、かつ関数Fu2が単調増加である範囲の種別情報(線分P2で示す範囲の種別情報)を持つアイテムは、それより大きい種別情報(線分P3で示す範囲)を持つアイテムより、推薦結果に入りにくいのに対し、ユーザu3では同程度に入るようになる。
元々利用している種別情報の範囲が狭いユーザu3には、P3に偏って推薦するよりも、それより若干種別情報の小さいP2を含めて推薦した方が、推薦結果が受容される可能性が高いと考えられる。一方で、元々幅広い範囲の種別情報に対応するアイテムを利用しているユーザu2は、ユーザu3に比べて、特定の種別情報へのこだわりが少なく、種別情報の大きなP3を受容する可能性が高いので、P2に相当するアイテムよりもP3に相当するアイテムを多く推薦結果に入れた方が、アイテム提供サービスの売上増大という点で効果的である。このように第3実施例では、種別分散値に応じて単調増加区間の幅を設定することにより、種別水準値が同程度のユーザに対しても、推薦情報の内容を適切に変えることができる。
ユーザu4は、種別情報の小さいアイテムと大きいアイテムの両方を利用するが、種別情報の大きいアイテムをより多く利用するため、種別水準値L[u4]が5人のユーザの中で2番目に大きく、種別分散値V[u4]は、ユーザu2と同程度に大きいものとする。図26(c)に示すように、ユーザu4に対応する関数Fu4(X)のパラメータであるXc4、Yα4、Xω4、Yω4は、それぞれXc2<Xc4、Xω1<Xω2≒Xω4、Yα4<Yα2、Yω2<Yω4となる。このため、種別情報の小さいアイテムと種別情報の大きいアイテムとの種別影響度の差(倍率)が関数Fu2より大きくなり、ユーザu2に比べると、種別情報の小さいアイテムが推薦結果に入りにくくなる。
ユーザu5は、種別情報の大きいアイテムのみを利用するため、種別水準値L[u5]が5人のユーザの中で最も大きく、種別分散値V[u5]は、ユーザu1と同程度に小さいものとする。図26(c)に示すように、ユーザu5に対応する関数Fu5(X)のパラメータであるXc5、Yα5、Xω5、Yω5は、それぞれXc5<Xc4、Xω1≒Xω5<Xω4、Yα5<Yα4、Yω4<Yω5となる。このため、種別情報の小さいアイテムと種別情報の大きいアイテムとの種別影響度の差(倍率)が非常に大きくなり、種別情報の小さいアイテムが5人のユーザの中で最も推薦結果に入りにくくなる。また、種別水準値の最も小さいユーザu1に対応する関数Fu1(X)と比べると、Xα1<<Xα5、Xβ1<<Xβ5、Yα1>>Yα5、Yβ1<<Yβ5であり、種別水準値の小さいユーザに比べて、種別情報の大きいアイテム(大規模な複合アイテム)が推薦結果に入りやすいことは明らかである。
なお、図26で説明に用いた関数Fu(X)は、あくまでも一例であり、他の特性の関数を用いてもよい。例えば、図27に示す特性の関数Fg(X)を用いて種別影響度を算出してもよい。この場合は、Fu(X)と同様な方法で、関数Fg(X)のパラメータXc、Xω、Yα、Yωを設定する他、種別水準値が小さければ、本図の関数Fg1のように上に凸の度合いが強い特性とし、種別水準値が中程度であれば、本図の関数Fg2のように線形に近い特性とし、種別水準値が大きければ、本図の関数Fg3のように下に凸の度合いが強い特性とする。下にと凸の度合いが強いほど、所定の出力値を得るために大きな入力値が必要といえる。また、種別分散値が大きいほど、下に凸の度合いを強くしてもよい。
次に、時間差Tpが期間2(月の中旬)に該当する場合に、種別影響度算出部106cは、図28に示す特性のひな型関数Fv(X)を用いる。新規のアイテム利用権が付与されてからある程度時間が経過している中旬は、一般的にユーザのアイテム利用意欲が上旬よりも低下している。このため、図28に示すように、ピーク(極大値)を持つ関数を用いて、種別情報の大きいアイテムが必ずしも優先的に推薦されないようにする。
まず、種別水準値L[u]が大きいほど、ピーク中心のX座標であるXcが大きな値となるように設定する。そして、種別分散値V[u]が大きいほど、ピークのX方向の幅であるXωが大きくなるように設定する。このように種別影響関数を設定すると、種別水準値が大きいユーザには、主に種別情報の大きいアイテムが推薦される一方、種別水準値が小さいユーザには、主に種別情報の小さいアイテムが推薦される。また、種別分散値が大きいユーザには、幅広い範囲の種別情報に対応するアイテムが推薦され易くなるが、種別分散値が小さいユーザには、特定の狭い範囲の種別情報に対応するアイテムが推薦される。すなわち、それぞれのユーザのアイテム利用パターンとほぼ同じ種別情報のアイテムが推薦される。ユーザが日頃利用しない種別情報のアイテムが推薦され難いため、ユーザのアイテム利用意欲の低下リスクを非常に小さくすることができる。
例えば、上述の5人のユーザのうち、種別水準値が小さく、種別分散値Vも小さいユーザu1では、Xc、Xωが両方とも小さくなるので、種別情報の小さいアイテム(単体アイテムおよび小規模な複合アイテム)のみ推薦される。また、種別水準値が中程度で、種別分散値Vが大きいユーザu2では、Xcが中程度で、Xωが大きくなるので、中程度の種別情報のアイテム(中規模な複合アイテム)を中心に、幅広い種別情報のアイテムが推薦されることになる。また、種別水準値が中程度で、種別分散値が小さいユーザu3では、Xcが中程度で、Xωが小さくなるので、中程度の種別情報という条件に限定されたアイテムが推薦される。また、種別水準値が大きく、種別分散値も大きいユーザu4では、Xc、Xωが両方とも大きくなるので、種別情報の大きいアイテム(大規模な複合アイテム)を中心に、幅広い種別情報のアイテムが推薦される。また、種別水準値が大きく、種別分散値が小さいユーザu5では、Xcが大きく、Xωが小さいので、種別情報の大きいアイテムのみ推薦される。
種別水準値L[u]および種別分散値V[u]に基づいて、ひな型関数Fv(X)の特性を変形させる方法は、上述の方法に限らない。例えば、種別分散値V[u]が大きいほど、ピークと底部とのY方向の高さの差Yω(極大値とピーク底部の出力値との差)が小さくなるように設定してもよい。Yωを小さくすると、種別影響度の最大値Yβと、種別影響度の最小値Yαとの差(または倍率)が小さくなるので、推薦情報に入るアイテムの種別情報の幅が広くなる。種別分散値が大きいユーザは、幅広い種別情報のアイテムを利用する傾向にあるので、そのようなユーザに対して、推薦アイテムの種別情報の幅を広く設定することは、購入意欲低下の防止に効果的である。また、種別分散値V[u]が大きいほど、Xωを大きく、Yωを小さくする等、種別分散値V[u]に応じて、XωとYωを両方変化させてもよい。また、上述のFv(X)は、ピークを中心に左右対称の関数であるが、ピークの左右で異なる形状の関数を用いてもよい。
次に、時間差Tpが期間3(月の下旬)に該当する場合に、種別影響度算出部106cは、図29に示す特性のひな型関数Fw(X)を用いる。この関数は、2つのピークを持っており、2つのピークの座標は、それぞれ(Xcs,Ycs)と(Xch,Ych)である。新規のアイテム利用権が付与されてからかなり時間が経過している下旬は、基本的には、種別情報の小さいアイテムの方がユーザに受容され易い。このため、第1のピークである(Xcs,Ycs)を用いて、種別情報の小さいアイテムを推薦情報に入れるようにしている。一方で、翌月までに保有しているアイテム利用権(ポイント)を使い切りたいと考えるユーザも少なからず存在する。そのようなユーザに対しては、比較的種別情報の大きいアイテムを推薦すると、ユーザはより少ない手間(少ない操作)で、保有しているポイントを使えるので、アイテム利用が促進され易い。このため、第2のピークである(Xch,Ych)を用いて、比較的種別情報の大きいアイテムを推薦情報に入れるようにしている。本実施例では、第1のピークの座標は固定とし、利用種別情報に応じて、この第2のピークの座標を設定する例を説明するが、これに限定する訳ではなく、第1のピークと第2のピークの両方を変化させてもよい。
ケース1)種別水準値L[u]が小さい場合、具体的には所定の閾値δ5未満(L[u]<δ5)の場合、2つのピーク間のX方向の幅Xdを比較的小さな値Xd1に設定し、底部と第2のピークとのY方向の差であるYωも比較的小さな値Yω1に設定する。第2のピークのX方向の幅であるXωは、標準的な値Xω1に設定する。このような関数特性に設定すると、種別情報の大きいアイテムは、ほとんど推薦情報に入らなくなる。
ケース2)種別水準値L[u]が、閾値δ5以上かつδ6未満であり、かつ種別分散値V[u]が閾値ε5未満(δ5≦L[u]<δ6 ∩ V[u]<ε5)の場合、すなわち、種別水準値が中程度であり、かつ種別分散値が比較的小さい場合、Xdを中程度の値Xd2に設定し、Yωを中程度の値Yω2に設定し、Xωを標準よりも小さな値Xω2(Xω2<Xω1)に設定する。このような関数特性に設定すると、種別情報の小さいアイテムの他に、中程度の種別情報を中心とした比較的狭い範囲のアイテムが推薦情報に入り易くなる。
ケース3)種別水準値L[u]が、閾値δ5以上かつδ6未満であり、かつ種別分散値V[u]が閾値ε5以上(δ5≦L[u]<δ6 ∩ V[u]≧ε5)の場合、すなわち、種別水準値が中程度であり、かつ種別分散値が比較的大きい場合、Xdを中程度の値Xd2に設定し、Yωを中程度の値Yω2に設定し、Xωを標準よりも大きな値Xω3(Xω3>Xω1)に設定する。このような関数特性に設定すると、種別情報の小さいアイテムの他に、中程度の種別情報を中心とした比較的広い範囲のアイテムが推薦情報に入り易くなる。
ケース4)種別水準値L[u]が、δ6以上であり、かつ種別分散値V[u]が閾値ε5以上(L[u]≧δ6 ∩ V[u]≧ε5)の場合、すなわち、種別水準値が比較的大きく、かつ種別分散値が比較的大きい場合、Xdを大きな値Xd3に設定し、Yωを大きな値Yω3(Yω3>Yω2)に設定し、Xωを標準よりも大きな値Xω3(Xω3>Xω1)に設定する。このような関数特性に設定すると、種別情報の小さいアイテムの他に、大きい種別情報を中心とした比較的広い範囲のアイテムが推薦情報に入り易くなる。なお、第2のピークの高さYchを第1のピークの高さYcsよりも高くしてもよい。
ケース5)種別水準値L[u]が、δ6以上であり、かつ種別分散値V[u]が閾値ε5未満(L[u]≧δ6 ∩ V[u]<ε5)の場合、すなわち、種別水準値が比較的大きく、かつ種別分散値が比較的小さい場合、Xdを大きな値Xd3に設定し、Yωを大きな値Yω3(Yω3>Yω2)に設定し、Xωを標準よりも小さな値Xω2(Xω2<Xω1)に設定する。このような関数特性に設定すると、種別情報の小さいアイテムの他に、大きい種別情報を中心とした比較的狭い範囲のアイテムが推薦情報に入り易くなる。なお、第2のピークの高さYchを第1のピークの高さYcsよりも高くしてもよい。
このように第3実施例では、利用種別情報に応じて、ユーザごとに関数F(X)の特性を設定することにより、ユーザのアイテム利用状況に応じて、適応的に種別影響関数を設定することができるので、ユーザに受容される可能性の高いアイテムを、より正確に推薦情報に入れることができる。以上がステップS410cの説明である。
なお、上述の説明では、1つの種別水準値と、1つの種別分散値とを使って関数の特性を設定したが、より多くの利用種別情報を用いて関数の特性を設定してもよい。複数の利用種別情報をそれぞれ別々の関数パラメータに対応させてもよい。また、複数の利用種別情報を1つの関数パラメータに対応させてもよい。例えば、第2の利用種別情報である、ユーザの利用した複合アイテムの割合を用いた値と、第3の利用種別情報である、ユーザの複合アイテムの利用度合いに関するばらつきの大きさ(ばらつき度)を示す値とを用いて、1つの関数パラメータを決定してもよい。
また、各々の関数パラメータを複数の利用種別情報を用いて決定する場合に、各利用種別情報を各次元に対応させた多次元情報空間を用いてもよい。例えば、多次元情報空間を適当な小領域に分割し、各々の小領域に対して関数パラメータの値を対応させる方法により、関数の特性を設定してもよい。また、各利用種別情報の重み付き平均などを用いて1次元の値を算出し、それに基づいて関数パラメータを決定してもよい。なお、時間差Tpの起点である所定の時点は、全てのユーザに対して同じである必要はなく、ユーザごとに所定の時点を変えてもよい。例えば、利用種別情報算出部111が、ユーザごとに種別水準値を時系列データとして算出すると共に(例えば、1日ごとの種別水準値の時系列データ)、その周期性を検出し、種別影響度算出部106cが、周期性が存在するユーザに関して、種別水準値がピーク(極大)となる時点を所定の時点としてもよい。例えば、あるユーザ(ユーザA)の種別水準値が、毎月3日にピークとなる傾向が強い場合には、毎月3日を所定の時点とすることができる。
なお、上述の第3実施例では、ユーザの利用種別情報に基づいて、種別影響関数の特性をユーザごとに変えているが、これとは異なる方法で、種別影響関数の特性をユーザごとに変えてもよい。例えば、ユーザが過去に提供された推薦情報をどの程度受け入れたかに応じて種別影響関数の特性を変更することができる。
この場合、過去のある時点においてユーザに提供された推薦情報に含まれるアイテムのうち、推薦情報提供後にそのユーザによって実際に利用されたアイテムの数を算出し、その数に基づいてユーザの利用度を算出する。利用度を算出する処理を行なうために、利用度算出部を情報選択装置10に設けるようにしてもよい。そして、種別影響度算出部106cは、算出された利用度に応じて種別影響関数F(X)の特性を変えればよい。
具体的には、利用度の高いユーザほど、複合アイテム(種別情報の大きいアイテム)が推薦されやすくなるように処理すればよい。これは、種別水準値が大きいユーザほど、種別情報の大きいアイテムが推薦されやすくなるように処理したのと同様である。
利用度の高いユーザは、過去の推薦情報を多く受容しているので、推薦システムに対する信頼感をある程度持っていると考えられる。また、推薦情報が表示された画面から直接利用していない場合であっても、そのユーザの嗜好に合致した推薦アイテムを選択できたと考えられる。このため、このようなユーザに種別情報の大きいアイテム)をより多く推薦しても、ユーザの購買意欲の低下につながるリスクが小さいと考えられるからである。
一方、利用度の低いユーザに、種別情報の大きいアイテムをより多く推薦すると、ユーザの購買意欲の低下につながるリスクが大きいと考えられる。このため、利用度の低いユーザには、種別情報の小さいアイテムもある程度推薦されやすくなる処理を行なうようにする。
このようにユーザの推薦情報に対する利用度に応じて、種別影響関数の特性を変化させることにより、さらにユーザの購買意欲が減少するリスクを減らしつつ、種別情報の大きいアイテムを推薦することができる。また、ユーザの推薦情報に対する利用度と、ユーザの利用種別情報を両方用いて、種別影響関数の特性を変えてもよい。
利用度の具体的な算出方法としては、例えば、1日に1回の頻度で推薦情報を作成しており、前回(前日)にユーザAに対して10個の推薦アイテムを提供している場合、次に新たな推薦情報を作成(提供)するまでの期間(約1日間)で、ユーザAが10個の推薦アイテムのうち何個を利用したかを、利用履歴格納部102とを推薦情報格納部108とを参照しながらカウントし、これを利用度とすればよい。
また、ユーザAが1つの推薦アイテムを2回以上利用した場合、その回数を考慮して利用度を算出してもよいし、2回以上利用しても1回だけ利用しても同等に扱って利用度を算出してもよい。あるいは、ユーザAが10個の推薦アイテムのうちの1つ以上利用した場合に、利用度を「1」、1つも利用しない場合に利用度を「0」などとして、ユーザAが推薦情報を1回以上利用したか否かの情報を利用度としてもよい。
ユーザAが推薦アイテムを利用した場合に、図12に示すような推薦画面(推薦ページ)から直接利用したのか、他のページで推薦アイテムを偶然見つけて利用したのかを区別するために、利用リクエストが発行された際にユーザが閲覧していたページ情報(閲覧ページ情報)を利用履歴格納部102に格納した上で、推薦ページから直接利用された分だけを利用度に反映させるようにしてもよいし、推薦アイテムが利用されたページの種類を区別せずに利用度を算出してもよい。
なお、上述の説明では、推薦情報を作成する期間と同じ期間の利用種別情報を用いているが、それに限定される訳ではない。例えば、期間3の推薦情報を作成する際に、期間3の利用種別情報に加えて、期間1および期間2の少なくとも一方の利用種別情報を用いてもよい。あるいは、期間1および期間2の少なくとも一方の利用種別情報を用い、期間3の利用種別情報を用いなくてもよい。例えば、期間1の種別水準値と、期間2の種別水準値の合計値または代表値を算出し、その値を期間3の種別水準値の代わりに用いて、期間3の推薦情報を作成してもよい。また、所定の時点以降の利用履歴から算出される利用種別情報を用いて、推薦情報を作成してもよい。
例えば、所定の時点を2013年1月1日午前0時とし、推薦情報を作成する時点あるいは推薦情報を提供開始する時点を2013年1月25日午前0時とした場合、2013年1月1日から2013年1月24日までの利用履歴を用いて、利用種別情報を算出し、それに基づいて種別影響関数の特性を設定してもよい。このようにすると、当月(2013年1月)にユーザが利用したアイテムの種別に応じて種別影響関数の特性を設定することができるので、推薦情報に入れるアイテムの種別をより適切に設定できる場合がある。例えば、普段は毎月の前半に相対的に価格の高い複合アイテムを多く利用するユーザが、当月(2013年1月1日から2013年1月24日までの期間)に、複合アイテムをあまり利用していない場合、これから当月の月末にかけて複合アイテムを利用する確率が高いと推定し、普段の月よりも複合アイテムが多く推薦情報に入るようにしてもよい。あるいは、ユーザの購買力が何らかの理由で低下したと推定し、普段の月よりも、相対的に価格の安い単体アイテムが多く推薦情報に入るようにしてもよい。
また上述の説明では、図25に示すように、利用主体識別子ごとに利用種別情報を算出、格納しているが、利用主体識別子ごとではなく、ユーザ集団の全体的な利用種別情報を算出し、それに応じて種別影響関数を設定してもよい。例えば、ある期間の利用履歴を用いて、複数のユーザ(ユーザ集団)が、その期間に利用したアイテム全体において複合アイテムが占める割合を算出し、それに応じて、そのユーザ集団に対して用いる種別影響関数を設定してもよい。また、全ユーザを1つのユーザ集団とみなして、全ユーザに対して共通の利用種別情報を算出してもよい。このようにすると、どのユーザに対しても同じ種別影響関数が適用されるが、利用主体識別子ごとに利用種別情報を算出および格納する必要がないので、情報選択装置1の処理負荷を軽減することができる。また、利用履歴の少ないユーザなどの場合、そのユーザ1人の利用履歴を用いて種別影響関数を設定するよりも、多くのユーザの利用履歴を用いて種別影響関数を設定した方が、適切な特性を設定できる場合がある。
また、上述の第3実施例の変形例として、以下の方法を用いることもできる。まず、利用種別情報算出部111は、利用履歴を用いて、ユーザuが時間差Tpの時点で種別情報Xのアイテムを利用する確率(条件付き確率)の分布(確率関数、確率密度関数)P(X|u,Tp)を、利用種別情報として算出する。例えば、確率関数の関数形として、正規分布や混合正規分布などを仮定し、利用履歴を用いて、確率関数のパラメータ(平均値、分散、混合比など)を算出(推定)すればよい。時間差Tpは、期間1、期間2、期間3などのように離散値として扱ってもよいし、連続量として扱ってもよい。
このような確率関数の一例を図30(a)に示す。本図は、時間差Tpを5つの離散値として扱い、それぞれのTpに対応する5つの確率関数を示した例である。また本図では、種別情報の種類が十分に多いものとして、連続量であるかのように示しているが、典型的には離散値である。例えば、種別情報が単体/複合の2種類であれば、確率関数は2本の棒グラフ状になる。本図の奥から手前にかけて、時間差TpがTp1であるときの確率関数P(X|u,Tp1)から、時間差TpがTp5であるときのP(X|u,Tp5)が順に並んでいる(Tp1<Tp2<Tp3<Tp4<Tp5)。所定の時点と図13に示す推薦情報作成処理を実行する時点との時間差Tpを算出した後、Tp1〜Tp5の中でTpに最も近いものを特定し、それに対応する確率関数を用いて種別影響関数を設定すればよい。なお、それぞれの確率関数の間を滑らかに補間する等の処理を行ってもよい。
次に、種別影響度算出部106cは、算出された確率関数P(X|u,Tp)を用いて、時間差Tpの時点でユーザuに対して用いる種別影響関数F(X|u,Tp)を算出する。具体的には、確率関数P(X|u,Tp)をそのまま種別影響関数F(X|u,Tp)として用いることができる。あるいは、確率関数P(X|u,Tp)を変形して種別影響関数F(X|u,Tp)としてもよい。確率関数を変形して種別影響関数を作成する一例を図30(b)に示す。本図では、確率関数(確率密度関数)を破線で、種別影響関数を実線で示している。本図に示すように、例えば、確率関数(確率密度関数)をX軸方向に所定値λ1倍し、所定値λ2だけ平行移動させて得られる関数を種別影響関数としてもよい。
この場合、F((X−λ2)/λ1|u,Tp)=P(X|u,Tp)となる。ただし、λ1>0である。ここで、λ1≒1、λ2>0にすると、ユーザuが過去に利用したアイテムよりも種別情報の大きい(一般的に価格が高い傾向にある)アイテムが推薦情報に入る確率を高めることができる。λ2を適切な値に設定することにより、ユーザ1人あたりの利用金額が増える可能性が高くなるため、アイテムの提供サービス全体の売上が増える可能性も高くなる。また、λ1>1にすると、ユーザuが過去に利用したアイテムの種別情報よりも幅広い種別情報のアイテムが推薦情報に入る確率を高めることができる。
このように、確率関数を変形させた種別影響関数を用いることにより、ユーザが過去に利用したアイテムの種別情報の分布を基準にできるため、ユーザが受容し易く、かつ種別情報に関する販売者の方針を反映させた推薦情報を容易に作成することができる。なお、確率関数を変形させた結果、種別影響関数に未定義の区間が生じる場合(Xが0に近い場合など)は、その区間が一定の出力値となるようにしてもよいし、確率関数を使って適当に外挿してもよい。なお、確率関数および種別影響関数において、時間差Tpを複数の期間のいずれかに対応させる等、離散値として扱う場合は、時間差Tpが対応する期間を特定し、その期間に対応する確率関数および種別影響関数を用いればよい。また、確率関数および種別影響関数の条件部にユーザuを含めずに、P(X|Tp)およびF(X|Tp)を算出するようにしてもよい。
この場合は、ユーザ個別に確率関数および種別影響関数を算出するのではなく、全てのユーザに対して共通する確率関数および種別影響関数を算出することになる。アイテム利用数が少ないユーザなどでは、個々のユーザごとに確率関数を算出(推定)するよりも、ユーザ全体の平均的な確率関数を用いた方がよい場合がある。利用種別情報算出部111が、利用種別情報として確率関数を算出し、種別影響度算出部106cが、それに基づいて種別影響関数の特性を設定し、種別影響度を算出した後、情報選択部107は、実施例1で説明した方法を用いて、選択指標を算出すればよい。
また更に別の変形例として、利用種別情報算出部111が、条件付き確率の条件部に、ユーザとアイテムとの関連度Wを加えた確率関数(確率密度関数)P(X|u,Tp,W)を算出してもよい。そして、種別影響度算出部106cは、確率関数P(X|u,Tp,W)に基づいて、種別影響関数F(X|u,Tp,W)を算出する。上述の説明と同様に、確率関数をそのまま用いてもよいし、変形して用いてもよい。なお、関連度Wを連続量として扱ってもよいし、例えば、適当な閾値を用い、大、中、小の3段階等のように離散値として扱ってもよい。
具体的には、制御部110または種別影響度算出部106cは、ステップS400により関連集合格納部105に格納された関連集合(関連識別子)を読み出す際に、各関連度も合わせて読み出し、それぞれの関連度が大、中、小のいずれの段階に該当するか特定し、特定した段階に対応する確率関数を用いて、種別影響関数を設定する。すなわち、時間差Tpがある一定の値である場合でも、各関連識別子の関連度に応じて、異なる種別影響関数を用いて、種別影響度が算出されることになる。確率関数の条件部に関連度を含めた場合は、関連度にも応じた種別影響度が算出されるので、種別影響度そのものを選択指標にしてもよい。また、確率関数および種別影響関数の条件部にユーザuを含めずに、P(X|Tp,W)およびF(X|Tp,W)を算出するようにしてもよい。この場合は、ユーザ個別に確率関数および種別影響関数を算出するのではなく、全てのユーザに対して共通する確率関数および種別影響関数を算出することになる。
第3実施例によれば、ユーザごとに利用種別情報に応じて適切な種別影響度を算出するため、ユーザに特別な操作をさせることなく、ユーザごとに適切なタイミングで、適切な種別のアイテムの情報を提供できる。すなわち、ユーザが受容しやすい推薦情報を提供できる。例えば、ある時期に種別情報の小さいアイテムだけを利用する傾向の強いユーザには、その時期に提供する推薦情報の中に、種別情報の小さいアイテムを多く入れることができる。逆に、その時期に種別情報の大きいアイテムを利用する傾向の強いユーザには、その時期に提供する推薦情報の中に、種別情報の大きいアイテムを多く入れることができる。従って、ユーザが推薦情報を納得して受け入れやすくなる。このため推薦情報に基づくアイテム利用が活発になり、アイテム提供サービスの売上をさらに増大させることが期待できる。
また、第2実施例と第3実施例とを組み合わせて、ユーザごとに利用種別情報に応じて自動的に種別影響関数を設定した上で、ユーザの好みに応じてこの特性を変更できるようにしてもよい。このようにすれば、さらに受容性の高い推薦情報を提供することができる。
なお、第1〜第3実施例において、種別情報をアイテム提供サーバ20または他の外部の装置に格納するようにした上で、種別影響度算出部106が、その種別情報を取得して利用するようにしてもよい。