本発明の実施の形態であるネットワークシステムについて図面を参照して説明する。以下では、まずシステム全体構成を説明し、その後、第1実施例〜第4実施例の順番で各構成の具体例および具体的動作例について説明する。
<システム全体構成>
図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実施例について「b」、第3実施例について「c」、第4実施例について「d」を符号の末尾に付加して説明する。
<情報選択装置>
図3は、第1実施例における情報選択装置10の構成を示すブロック図である。本図に示すように情報選択装置10は、アイテム属性格納部101と、利用履歴格納部102と、価格情報格納部103と、関連度算出部104と、関連集合格納部105と、価格影響度算出部106と、情報選択部107と、推薦情報格納部108と、送受信部109と、制御部110とを備えて構成されている。また、情報選択装置10には、情報選択装置10の管理者向けに必要な情報を表示するための表示装置120と、管理者が操作を行なうためのキーボード、マウス等の入力装置130とが接続されている。
情報選択装置10は、CPU、RAM、ROM、HDD(ハードディスクドライブ)、ネットワークインタフェース等を備える一般的なコンピュータを用いて構成することができる。すなわち、一般的なコンピュータは、以下で説明するような処理を行なうためのコンピュータプログラムを実行することにより、情報選択装置10として機能することができるようになる。
また、上述のように、情報選択装置10を複数台のコンピュータを用いて構成してもよい。例えば、負荷分散をするために、情報選択装置10のある処理ブロックに相当するコンピュータを複数台用いて、すなわち、同じ処理ブロックを備える複数台のコンピュータを用いて分散処理を行なうようにしてもよい。また、情報選択装置10の一部の処理ブロックをあるコンピュータで実施し、他の処理ブロックを別のコンピュータで実施する形態で分散処理を行なってもよい。
アイテム属性格納部101は、アイテムに関する情報が記録されたアイテム情報テーブル101Aと、カテゴリに関する情報が記録されたカテゴリ情報テーブル101Bとを格納している。
図4(a)は、アイテム情報テーブル101Aの一例を示している。本図に示すように、アイテム情報テーブル108Aは、アイテム識別子(アイテムID)と、アイテム属性情報とを対応させたテーブルである。アイテム属性情報は、アイテムの「タイトル(名称)」「カテゴリ識別子」「説明情報」「アイテム時期情報」などで構成されている。
図4(b)は、カテゴリ情報テーブル101Bの一例を示している。本図に示すように、カテゴリ情報テーブル108Bは、カテゴリ識別子(カテゴリ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つのカテゴリが設定されていてもよい。もちろん、ここで挙げたアイテム属性情報とカテゴリ属性情報は、あくまでも例示であり、上記に限定される訳ではない。例えば、アイテム属性情報に「サイズ」や「色」などの属性項目を用いてもよい。
なお、情報選択装置10が、必要に応じてアイテム提供サーバ20の後述するアイテム格納部202からアイテム情報およびカテゴリ情報を取得できるようにして、アイテム属性格納部101を省略することも可能である。
送受信部109は、ネットワーク40(図2の構成の場合は、さらにネットワーク42)を介して、アイテム提供サーバ20または端末装置30との間でデータを送受信する処理を行なう。
制御部110は、情報選択装置10の全体の制御を行なうための種々の処理を行なう。例えば、後述するように、アイテム提供サーバ20または端末装置30から送信される利用リクエストを、送受信部109を介して受信し、利用リクエストに含まれるユーザ識別子とアイテム識別子とを対応させて、利用履歴情報として利用履歴格納部102に格納させる。
利用履歴格納部102は、ユーザのアイテム利用履歴情報を記録するアイテム利用履歴テーブル102Aを格納している。アイテム利用は、ユーザからの利用リクエストに対してアイテム提供サーバ20がアイテムを提供することにより実行される。
アイテム利用履歴テーブル102Aは、利用履歴情報の格納形態として、種々の格納形態を採用することができる。例えば、図5(a)のアイテム利用履歴テーブル102A−1に示すように、ユーザ識別子とアイテム識別子とを関連付けて格納することができる。本例では、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(c)に示すアイテム利用履歴テーブル102A−3は、利用時期情報を省略し、ユーザ識別子とアイテム識別子と利用回数とを関連付けた格納形態例である。後述するように、関連度算出部104において、利用時期情報を用いない場合は、アイテム利用履歴テーブル102A−3を用いることで利用履歴格納部102の記憶容量を削減することができる。また、利用リクエストの中に、ユーザのアイテムに対する評価値が含まれる場合は、ユーザ識別子とアイテム識別子と利用回数と最新の評価値とを関連付けてアイテム利用履歴テーブル102A−3に格納するようにしてもよい。
また、利用履歴格納部102には、アイテム利用履歴テーブル102Aに加え、図5(d)に示すようなカテゴリ利用履歴テーブル102Bを格納するようにしてもよい。カテゴリ利用履歴テーブル102Bは、ユーザ識別子とカテゴリ識別子と利用時期情報とを関連付けたテーブルである。この場合、制御部110は、ユーザからの利用リクエストに際し、アイテム属性格納部101のアイテム情報テーブル101Aを参照して、利用リクエストのアイテム識別子に対応するカテゴリ識別子を特定し、カテゴリ利用履歴テーブル102Bに格納する。後述するように、カテゴリ−アイテム推薦形式およびカテゴリ−カテゴリ推薦形式に対応する関連集合を作成する際(図14のステップS410)に、カテゴリ利用履歴テーブル102Bを格納しておくと、効率よく処理が行なえる。
価格情報格納部103は、アイテムの価格情報を記録したアイテム価格情報テーブル103Aと、カテゴリの価格情報を記録したカテゴリ価格情報テーブル103Bとを格納している。図6(a)は、アイテム価格情報テーブル103Aの一例を示している。本図に示すように、アイテム価格情報テーブル103Aは、アイテム識別子と、価格情報とを対応付けて格納する。アイテムの価格情報は、そのアイテムの価格である。ただし、必ずしも円、ドル、ユーロといった実際の通貨に基づく価格である必要はない。例えば、本実施形態に係るアイテム提供サービスのみで使用できる独自のポイントサービスの値であってもよい。なお、本図の例から分かるように、価格情報(価格)が「0円」である無料のアイテムが存在してもよい。また本図に示すように、価格の安い順にアイテムを格納してもよいし、高い順に格納してもよい。もちろんアイテム識別子の順番に格納してもよい。
図6(b)は、カテゴリ価格情報テーブル103Bの一例を示している。本図に示すように、カテゴリ価格情報テーブル103Bは、カテゴリ識別子と、価格情報とを対応付けて格納する。カテゴリの価格情報は、そのカテゴリに属する各アイテムの価格の合計値または代表値とすることができる。価格の代表値は、例えば、そのカテゴリに属するアイテムの価格の平均値、中央値、最頻値、四分位値、最大値、最小値などである。
図6(b)に示したカテゴリ価格情報テーブル103Bでは、そのカテゴリに属するアイテムの価格の合計値をカテゴリの価格情報としている。なお本図から分かるように、価格が「0円」であるカテゴリ(そのカテゴリに属するアイテムがすべて無料)が存在してもよい。またカテゴリ識別子を格納する場合も、価格の安い順または高い順にアイテムを格納してもよい。なお、価格情報をアイテム属性格納部101に記録するようにして、価格情報格納部103を省略してもよい。
推薦情報格納部108は、情報選択部107で選択された推薦情報を記録する推薦情報テーブルを格納する。推薦情報は、ある識別子(以下「基準識別子」と称する)と、それに関連する他の識別子(以下「関連識別子」と称する)とを対応させた情報である。基準識別子として、アイテム識別子またはカテゴリ識別子を用いることができる。また関連識別子として、アイテム識別子またはカテゴリ識別子を用いることができる。すなわち、推薦情報格納部108は、基準識別子と関連識別子の組み合わせとして、図7(a)〜(b)に示すような4種類の推薦情報テーブルを格納する。
図7(a)は、基準識別子をアイテム識別子(基準アイテム識別子)とし、関連識別子をアイテム識別子(関連アイテム識別子)とし、さらに推薦順位を対応させて格納したアイテム−アイテム推薦情報テーブル108Aの例を示している。基準アイテム識別子は、推薦情報を出力するトリガーとなる推薦リクエスト(後述)に含まれるアイテム識別子に対応するものであり、関連アイテム識別子は、基準アイテムと関連するアイテムの識別子である。以下ではこのようなアイテムからアイテムへの推薦を「アイテム−アイテム推薦形式」と称する。
アイテム−アイテム推薦情報テーブル108Aでは、1つの基準アイテム識別子に、1つ以上の関連アイテム識別子が対応付けられている。「ItemID−1」に対応する関連アイテムはN1個格納されており、「ItemID−2」に対応する関連アイテムはN2個格納されている。ここで、N1とN2は同じであっても、異なっていてもよい。すなわち、基準識別子ごとの関連識別子の個数がすべて同じであってもよいし、基準識別子ごとに関連識別子の個数が異なっていてもよい。
推薦順位は、基準アイテム識別子ごとに関連アイテムを推薦する順位を示しており、ここでは番号が小さいほど優先順位が高く、優先的にユーザに提示されるものとする。本図では、各々の基準識別子(基準アイテム識別子)に対して、推薦順位の高い順に関連識別子(関連アイテム識別子)を格納しているが、推薦順位と対応付けて関連識別子を格納する場合は、適当な順序で格納してもよい。
なお、推薦順位の代わりに、数値が大きいほど優先順位が高く、優先的にユーザに提示されるような推薦度を格納するようにしてもよい。また、各推薦情報テーブルにおいて推薦順位を省略してもよい。この場合は、各推薦情報テーブルにおいて、基準識別子ごとに推薦順位の高い順、または推薦順位の低い順に関連識別子を格納すればよい。すなわち、ある基準識別子に対する関連識別子の推薦順位の情報を、関連識別子の格納順序(格納位置)に持たせてもよい。あるいは、記録された関連識別子をすべて同じ順位として扱ったり、各推薦情報テーブルを読み出す際に、ランダムに推薦順位を付与してもよい。
図7(b)は、基準識別子をアイテム識別子(基準アイテム識別子)とし、関連識別子をカテゴリ識別子(関連カテゴリ識別子)とし、さらに推薦順位を対応させて格納したアイテム−カテゴリ推薦情報テーブル108Bの例を示している。例えば、利用リクエストに含まれるアイテムと関連性の高いクリエイター(アイテムの作成者)を推薦情報として提供する場合に用いることができる。
なお、ここで関連性の高いクリエイターとは、あるアイテム(アイテムA)の作成者である「クリエイター1」のみならず、「クリエイター1」と作風が似ている「クリエイター2」や、「クリエイター1」とユーザ層が重なる「クリエイター3」や、アイテムAを多く利用するユーザが「クリエイター4」のアイテムを多く利用する場合の「クリエイター4」などの間接的に関連性の高いクリエイターも含められる。すなわち、アイテムとカテゴリとの関連性として、そのアイテムがそのカテゴリに属するという直接的な関連性だけでなく、上記のような間接的な関連性を用いることができる。
推薦順位は、アイテム−アイテム推薦情報テーブル108Aと同様な意味であり、同様に推薦順位の格納を省略することも可能である。以下ではこのようなアイテムからカテゴリへの推薦を「アイテム−カテゴリ推薦形式」と称する。
図7(c)は、基準識別子をカテゴリ識別子(基準カテゴリ識別子)とし、関連識別子をアイテム識別子(関連アイテム識別子)とし、さらに推薦順位を対応させて格納したカテゴリ−アイテム推薦情報テーブル108Cの例を示している。例えば、利用リクエストに含まれるクリエイターと関連性の高いアイテムを推薦情報として提供する場合に用いることができる。なお、上述したように、カテゴリとアイテムとの関連性として、間接的な関連性を用いることができる。推薦順位は、アイテム−アイテム推薦情報テーブル108Aと同様な意味であり、同様に推薦順位の格納を省略することも可能である。以下ではこのようなカテゴリからアイテムへの推薦を「カテゴリ−アイテム推薦形式」と称する。
図7(d)は、基準識別子をカテゴリ識別子(基準カテゴリ識別子)とし、関連識別子をカテゴリ識別子(関連カテゴリ識別子)とし、さらに推薦順位を対応させて格納したカテゴリ−カテゴリ推薦情報テーブル108Dの例を示している。例えば、利用リクエストに含まれるクリエイターと関連性の高いクリエイターを推薦情報として提供する場合に用いることができる。ここで関連性の高いクリエイターとは、「クリエイター1」と作風が似ている「クリエイター2」や、「クリエイター1」とユーザ層が重なる「クリエイター3」や、「クリエイター1」のアイテムと「クリエイター4」のアイテムを両方利用するユーザが多い場合の「クリエイター4」などである。推薦順位は、アイテム−アイテム推薦情報テーブル108Aと同様な意味であり、同様に推薦順位の格納を省略することも可能である。以下ではこのようなカテゴリからカテゴリへの推薦を「カテゴリ−カテゴリ推薦形式」と称する。
なお以下では、「アイテム−アイテム推薦形式」「アイテム−カテゴリ推薦形式」「カテゴリ−アイテム推薦形式」「カテゴリ−カテゴリ推薦形式」のすべてを実施する場合を例にして説明するが、これらのうちの一部のみを実施するようにしてもよい。その場合、4種類の中の必要な種類の推薦情報テーブルのみ格納すればよい。
関連度算出部104は、アイテム属性格納部101または/および利用履歴格納部102に格納されたデータを用いて、上述した「アイテム−アイテム推薦形式」「アイテム−カテゴリ推薦形式」「カテゴリ−アイテム推薦形式」「カテゴリ−カテゴリ推薦形式」に対応する4種類の関連度を算出して関連集合を作成し、関連集合格納部105に格納させる。
関連集合格納部105は、基準識別子と、関連識別子と、関連度とを対応させた関連度テーブル105A〜Dを格納する。図8は、関連度テーブル105A〜Dの一例を示している。関連度テーブル105A〜Dに格納されているある基準識別子に対応する関連識別子の集合をその基準識別子の関連集合と称する。
上述したように、基準識別子は、アイテム識別子またはカテゴリ識別子であり、関連識別子は、アイテム識別子またはカテゴリ識別子であり、基準識別子と関連識別子との組み合わせパターンに応じて、4種類の格納形式があるが、本図では簡略化して示している。
以下では、基準アイテム識別子と関連アイテム識別子との関連度を関連度テーブル105Aに記録し、基準アイテム識別子と関連カテゴリ識別子との関連度を関連度テーブル105Bに記録し、基準カテゴリ識別子と関連アイテム識別子との関連度を関連度テーブル105Cに記録し、基準カテゴリ識別子と関連カテゴリ識別子との関連度を関連度テーブル105Dに記録するものとする。
本図の例では、基準識別子「Item/Category ID−1」に対応する関連識別子をL1個、基準識別子「Item/Category ID−2」に対応する関連識別子をL2個格納している。ここで、L1とL2は同じであっても、異なっていてもよい。すなわち、すべての基準識別子に対して同じ数の関連識別子を格納してもよいし、基準識別子ごとに異なる数の関連識別子を格納してもよい。また、関連度算出部104で関連度が算出された基準識別子と関連識別子の組み合わせをすべて格納してもよいし、ある基準識別子との関連度の高い関連識別子のみを関連集合として格納してもよい。一部のみを格納することにより、関連集合格納部105記憶容量を削減することができる。また、本図に示すように、基準識別子ごとに、関連度の大きい順に関連識別子を格納してもよい。
関連集合の要素数(関連識別子の数)は、基本的には複数であるが、要素数が「1」の関連集合が存在していてもよい。ただし、少なくとも1つ以上の関連集合の要素数は「2」以上である必要がある。なお、情報選択装置10以外の他の装置で算出された関連集合および関連度を関連度テーブル105A〜Dに記録してもよく、その場合は関連度算出部104を省略することができる。
価格影響度算出部106は、価格情報格納部103および関連集合格納部105を参照しながら、関連集合の各々の関連識別子について、その価格情報(価格)が推薦結果に与える影響度である価格影響度を算出する。
情報選択部107は、価格影響度算出部106で算出された価格影響度と、関連集合格納部105の関連度テーブル105A〜Dに格納された関連度とを用いて選択指標を算出し、その選択指標に基づいて、関連集合格納部105の関連度テーブル105A〜Dに格納された基準識別子ごとに関連識別子を選択し、その選択された関連識別子と基準識別子との組み合わせを推薦情報として、推薦情報格納部108の各推薦情報テーブル108A〜Dに格納する。
<アイテム提供サーバ>
アイテム提供サーバ20は、端末装置30からの要求に応じて、アイテムおよびアイテムに関する情報を提供する装置である。図9は、アイテム提供サーバ20の構成を示すブロック図である。本図に示すように、アイテム提供サーバ20は、ユーザ管理部201と、アイテム格納部202と、データ格納部203と、送受信部204と、制御部205とを備えて構成されている。
アイテム提供サーバ20は、CPU、RAM、ROM、HDD(ハードディスクドライブ)、ネットワークインタフェース等を備える一般的なコンピュータを用いて構成することができる。すなわち、一般的なコンピュータは、以下で説明するような処理を行なうためのプログラムを実行することにより、アイテム提供サーバ20として機能することができるようになる。
送受信部204は、ネットワーク40(図2の構成の場合は、さらにネットワーク42)を介して情報選択装置10および端末装置30との間でデータを送受信する処理を行なう。制御部205は、アイテム提供サーバ20の全体の制御を行なう。
ユーザ管理部201は、端末装置30を利用するユーザを一意に識別するユーザ識別子、または端末装置30を一意に識別するための端末識別子を格納している。本実施形態では、ユーザ識別子を用いてユーザを識別するものとするが、端末装置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は、ユーザが使用する装置である。図10は、端末装置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が接続されているものとして説明する。
<システム動作>
<システム全体の動作>
図11のフローチャートを参照して、ネットワークシステム全体の基本的な動作を説明する。この基本的な動作は、多少の変更はあるがすべての実施例で共通である。まず、ステップ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にその情報を表示する。表示画面の例を図12に示す。図12(a)は、応答データにアイテムを紹介する情報が含まれる場合の表示例である。本図の例は、アイテム提供サーバ20が最近提供を開始した「新着アイテム」を紹介する表示画面である。ただし、本図に示すようなアイテムを紹介する情報は、種々のタイミングで端末装置30に送信することができる。
本図において「アイテムABC」は1番目のアイテムのタイトルであり、「SF」は1番目のアイテムのカテゴリ名であり、「このアイテムは、2001年に制作された映画で…」という表示は1番目のアイテムの説明情報である。また、各々のアイテムごとに、そのアイテムに関連するアイテム情報を表示するためのボタンやリンク等(関連アイテムリンク)と、そのアイテムに関連するカテゴリ情報を表示するためのボタンやリンク等(関連カテゴリリンク)と、そのアイテムを利用するためのボタンやリンク等(利用リンク)が表示される。2番目以降のアイテムについても同様な表示がされる。なお、関連アイテムリンクと関連カテゴリリンクを合わせて、以下では関連リンクと称する。
図12(a)の関連アイテムリンクは、「関連アイテム表示」ボタンに対応付けられており、上述したアイテム−アイテム推薦形式の推薦情報を表示させるためのリンクである。図12(a)の関連カテゴリリンクは、「関連カテゴリ表示」ボタンに対応付けられており、アイテム−カテゴリ推薦形式の推薦情報を表示させるためのリンクである。ユーザは、入力装置330を使用したクリック等の操作により、関連リンクまたは利用リンクを選択することができる。なお表示画面には表示されないが、応答データには、各々のアイテムのアイテム識別子、または各々のカテゴリのカテゴリ識別子が含まれており、各々の関連アイテムリンクおよび利用リンクには、選択対象となるアイテムのアイテム識別子が対応付けられている。また、各々の関連カテゴリリンクには、選択対象となるカテゴリのカテゴリ識別子が対応付けられている。
図12(b)は、応答データにカテゴリを紹介する情報が含まれる場合の表示例である。本図の例は、アイテム提供サーバ20の運営者が選んだ「注目クリエイター」を紹介する表示画面である。「クリエイターGHI」は1番目のクリエイターの名前(カテゴリ名)であり、「このクリエイターは、○○賞を受賞し…」という表示は、1番目のクリエイターの説明情報(カテゴリの説明情報)である。また、各々のカテゴリ(クリエイター)ごとに、そのカテゴリに関連するアイテム情報を表示するためのボタンやリンク等(関連アイテムリンク)と、そのカテゴリに関連するカテゴリ情報を表示するためのボタンやリンク等(関連カテゴリリンク)が表示されている。
図12(b)の関連アイテムリンクは、「関連アイテム表示」ボタンに対応付けられており、カテゴリ−アイテム推薦形式の推薦情報を表示させるためのリンクである。図12(b)の関連カテゴリリンクは、「関連カテゴリ表示」ボタンに対応付けられており、カテゴリ−カテゴリ推薦形式の推薦情報を表示させるためのリンクである。2番目以降のアイテムについても同様な表示がされる。
図11のフローチャートの説明に戻って、ステップS150において、端末装置30は、関連リンク(関連アイテムリンクまたは関連カテゴリリンク)がユーザから入力装置330を介して選択されたか否かを判定する。関連リンクが指定された場合(Yes)は、ステップS160に進み、指定されていない場合(No)は、ステップS190に進む。
ステップS160において、端末装置30は、関連リンクに対応するURLにリクエスト(推薦リクエスト)を送信する。本実施形態では、関連リンクが情報選択装置10の所定のURLに対応する場合を説明するが、関連リンクをアイテム提供サーバ20の所定のURLに対応させてもよい。推薦リクエストには、図12に示した表示画面で選択されたアイテムまたはカテゴリの識別子(リクエスト基準識別子)と、関連アイテムリンクであるか関連カテゴリリンクであるかを示すリンク種別情報とが含まれている。
図12(a)のように、アイテムを紹介する表示画面でのリクエスト基準識別子は、アイテム識別子であり、図12(b)のように、カテゴリを紹介する表示画面でのリクエスト基準識別子は、カテゴリ識別子である。また、推薦リクエストに必要な推薦情報(アイテムまたはカテゴリ)の個数の情報を含めたり、利用主体識別子(端末装置30を利用するユーザのユーザ識別子または端末識別子)を含めるようにしてもよい。
ステップS170において、情報選択装置10の制御部110は、送受信部109を介して、推薦リクエストを受信し、それに含まれるリクエスト基準識別子に対応する表示用推薦データを作成して端末装置30に送信する。このとき、制御部110は、以下に説明する「アイテム−アイテム推薦形式」「アイテム−カテゴリ推薦形式」「カテゴリ−アイテム推薦形式」「カテゴリ−カテゴリ推薦形式」に対応する4種類の処理を行なう。
<アイテム−アイテム推薦形式>
図7(a)に示した推薦情報格納部108のアイテム−アイテム推薦情報テーブル108Aを参照しながら、リクエスト基準識別子に一致する基準アイテム識別子を特定し、それに対応する関連アイテム識別子と推薦順位とを読み出す。さらに、その関連アイテム識別子に対応するアイテム属性情報をアイテム属性格納部101のアイテム情報テーブル101Aから読み出す。そして、関連アイテム識別子と、推薦順位と、アイテム属性情報とを対応させた表示用推薦データを作成する。
例えば、図7(a)に示した例において、リクエスト基準識別子が「ItemID−1」である場合は、それと同じ基準アイテム識別子に対応した関連アイテム識別子である「ItemID−1000」「ItemID−1020」…「ItemID−1035」と、その推薦順位「1」「2」…「N1」を読み出す。ただし、特定した基準アイテム識別子に対応する関連アイテム識別子をすべて読み出してもよいし、推薦順位の高い順に所定個数読み出してもよい。また推薦リクエストに推薦情報の個数が指定されている場合は、推薦順位の高い順にその個数だけを読み出す。
このとき、推薦リクエスト送信(ステップS160)において推薦リクエストに利用主体識別子を含めた上で、利用履歴格納部102のアイテム利用履歴テーブル102Aを参照しながら、その利用主体識別子が過去に利用したアイテム識別子(利用済みアイテム識別子)を特定し、利用済みアイテム識別子を読み出して対象から除外する処理を行ってもよい。このような処理を行なうことで、ユーザが1回しか同じアイテムを購入しない性質を持つようなアイテム提供サービスにおいて、精度の高い推薦が可能になる。例えば、1度購入したデジタルコンテンツは、端末装置30で繰り返し利用(再生)できる、といったサービスに適している。
そして制御部110は、アイテム属性格納部101を参照しながら、読み出した関連アイテム識別子に対応する「タイトル」「説明情報」などのアイテム属性情報と、「カテゴリ名」などのカテゴリ属性情報とを読み出し、関連アイテム識別子と2つの属性情報と推薦順位とを合わせて表示用推薦データを作成する。
<アイテム−カテゴリ推薦形式>
図7(a)に示した推薦情報格納部108のアイテム−カテゴリ推薦情報テーブル108Bを参照しながら、リクエスト基準識別子に一致する基準アイテム識別子を特定し、それに対応する関連カテゴリ識別子と推薦順位とを読み出す。ここで、特定した基準アイテム識別子に対応する関連カテゴリ識別子をすべて読み出してもよいし、推薦順位の高い順に所定個数読み出してもよい。さらに、その関連カテゴリ識別子に対応するカテゴリ属性情報(カテゴリ名およびカテゴリ説明情報)をアイテム属性格納部101から読み出す。そして、関連カテゴリ識別子と、推薦順位と、カテゴリ属性情報とを対応させた表示用推薦データを作成する。
このとき、ユーザが過去に利用したカテゴリを除外して表示用推薦データを作成してもよい。具体的には、推薦リクエスト送信(ステップS160)において推薦リクエストに利用主体識別子を含めた上で、利用履歴格納部102のアイテム利用履歴テーブル102Aとアイテム情報テーブル101Aとを参照しながら、推薦リクエストの利用主体識別子が、過去に利用したアイテムについてのカテゴリ識別子(利用済みカテゴリ識別子)を特定する。なお、カテゴリ利用履歴テーブル102Bを用いている場合は、カテゴリ利用履歴テーブル102Bを参照すればよい。
そして、アイテム−カテゴリ推薦情報テーブル108Bから関連カテゴリ識別子を読み出す際に、利用済みカテゴリ識別子を除外する処理を行なう。このような処理を行なうことで、にユーザが1回しか同じカテゴリのアイテムを購入しない性質を持つようなアイテム提供サービスにおいて、精度の高い推薦が可能になる。
<カテゴリ−アイテム推薦形式>
図7(c)に示した推薦情報格納部108のカテゴリ−アイテム推薦情報テーブル108Cを参照しながら、リクエスト基準識別子に一致する基準カテゴリ識別子を特定し、それに対応する関連アイテム識別子と推薦順位とを読み出す。ここで、特定した基準カテゴリ識別子に対応する関連アイテム識別子をすべて読み出してもよいし、推薦順位の高い順に所定個数読み出してもよい。
さらに、その関連アイテム識別子に対応するアイテム属性情報をアイテム情報テーブル101Aから読み出す。そして、関連アイテム識別子と、推薦順位と、アイテム属性情報とを対応させた表示用推薦データを作成する。このとき、ユーザが過去に利用したアイテムを除外して表示用推薦データを作成してもよい。
<カテゴリ−カテゴリ推薦形式>
図7(d)に示した推薦情報格納部108のカテゴリ−カテゴリ推薦情報テーブル108Dを参照しながら、リクエスト基準識別子に一致する基準カテゴリ識別子を特定し、それに対応する関連カテゴリ識別子と推薦順位とを読み出す。ここで、特定した基準カテゴリ識別子に対応する関連カテゴリ識別子をすべて読み出してもよいし、推薦順位の高い順に所定個数読み出してもよい。さらに、その関連カテゴリ識別子に対応するカテゴリ属性情報(カテゴリ名およびカテゴリ説明情報)をカテゴリ情報テーブル101Bから読み出す。そして、関連カテゴリ識別子と、推薦順位と、カテゴリ属性情報とを対応させた表示用推薦データを作成する。このとき、ユーザが過去に利用したカテゴリを除外して表示用推薦データを作成してもよい。
なお、上述した「アイテム−アイテム推薦形式」「アイテム−カテゴリ推薦形式」「カテゴリ−アイテム推薦形式」「カテゴリ−カテゴリ推薦形式」の表示用推薦データに、リクエスト基準識別子と、リクエスト基準識別子に対応するタイトル等の属性情報とを含めてもよい。
また、推薦リクエストの種別に対応する推薦情報テーブルにおいて、推薦順位が格納されておらず、関連識別子の格納順序が推薦順位の情報を持っている場合は、その格納順序に従って、表示用推薦データにおける関連識別子の順序を決めればよい。例えば、格納順序が1番目の関連アイテム識別子を表示用推薦データの1番目にし、格納順序が2番目の関連アイテム識別子を表示用推薦データの2番目にすればよい。また、表示用推薦データを作成する際に、ランダムな推薦順位を生成して付与したり、表示用推薦データにおける関連識別子の順序をランダムに決定してもよい。
図11のフローチャートの説明に戻って、ステップS180において、端末装置30は、ステップS170で情報選択装置10から送信された表示用推薦データを受信し、例えば、図13に示す形式で表示装置120に推薦リストとして表示する。図13(a)は、「アイテム−アイテム推薦形式」および「カテゴリ−アイテム推薦形式」に対応する処理が行われた場合に「○○○の関連アイテム」を表示する画面の一例である。
「○○○」には、リクエスト基準識別子に対応する文字が表示され、「アイテム−アイテム推薦形式」の場合はアイテムのタイトル、「カテゴリ−アイテム推薦形式」の場合はカテゴリ名が表示される。
アイテムの表示順序は、推薦順位に従って決められており、推薦順位が上位のアイテムほど、ユーザの目に留まりやすい位置に表示される。例えば、本図に示すように上下方向に各々のアイテムの情報を配置する場合は、推薦順位が上位のアイテムの表示画面の上側に表示するとよい。また、左右方向に各々のアイテムの情報を配置する場合は、表示画面の左側に表示するとよい。「アイテムOPQ」は1番目のアイテム(推薦順位が「1」のアイテム)のタイトルであり、「サスペンス」は1番目のアイテムのカテゴリ名であり、「このアイテムは、目が離せない…」という表示は、1番目のアイテムの説明情報である。図12(a)に示した表示例と同様に、各々のアイテムに対して、関連アイテムリンクに対応付けられた「関連アイテム表示」ボタンと、関連カテゴリリンクに対応付けられた「関連カテゴリ表示」ボタンと、利用リンクに対応付けられた「アイテム利用」ボタンとが表示される。2番目以降のアイテムについても同様な表示がされる。
図13(b)は、表示用推薦データ作成・送信処理(ステップS170)で「アイテム−カテゴリ推薦形式」および「カテゴリ−カテゴリ推薦形式」に対応する処理が行われた場合に「×××の関連カテゴリ」を表示する画面の一例である。
カテゴリの表示順序は、推薦順位に従って決められている。「×××」には、リクエスト基準識別子に対応する文字が表示され、「アイテム−カテゴリ推薦形式」の場合はアイテムのタイトル、「カテゴリ−カテゴリ推薦形式」の場合はカテゴリ名が表示される。「カテゴリRST」は1番目のカテゴリ(推薦順位が「1」のカテゴリ)のカテゴリ名であり、「このカテゴリは、最近非常に注目され…」という表示は、1番目のカテゴリの説明情報である。図12(b)に示した表示例と同様に、各々のカテゴリに対して、関連アイテムリンクに対応付けられた「関連アイテム表示」ボタンと、関連カテゴリリンクに対応付けられた「関連カテゴリ表示」ボタンとが表示される。2番目以降のアイテムについても同様な表示がされる。
図11のフローチャートの説明に戻って、ステップ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が推薦情報を作成する動作について図14のフローチャートを参照して説明する。
情報選択装置10の制御部110は、所定のタイミングで情報選択装置10の各処理部に指示を出し、推薦情報を作成する処理を開始する。推薦情報作成のタイミングとして、次の3種類を用いることができる。
推薦情報作成の第1のタイミングは、所定の日時または所定の時間間隔である。例えば、「毎日午前6時と午後6時」「毎週月曜の午前10時30分」「12時間ごと」「24時間ごと」などである。このとき、「平日は午前6時、土日は午前6時と午後6時」「平日は3時間ごと、土曜日は6時間ごと、日曜日は12時間ごと」などのように時間間隔が変動してもよい。また、夏は時間間隔を短くして、冬は時間間隔を長くするなど、季節に応じて時間間隔を変えてもよい。この第1のタイミングを用いると、他のタイミングを用いた場合より情報選択装置10の処理負荷を減らすことができる。特に、推薦リクエスト数が少ない時間帯に推薦情報を作成するように設定すれば、情報選択装置10の処理負荷の低減に効果的である。
推薦情報作成の第2のタイミングは、端末装置30の推薦リクエスト送信処理(図11ステップS160)による端末装置30からの推薦リクエストを所定回数受信するごとである。この場合は、まず推薦情報を作成し、その後に、表示用推薦データ作成・送信処理(ステップS170)を行なうようにする。所定回数を調整することにより、情報選択装置10の処理負荷の大きさと、推薦情報の新しさとのバランスを調整することができる。例えば、所定回数を1回として、推薦リクエストを受信するごとに推薦情報を作成すると、情報選択装置10の処理負荷は大きくなるが、最新の推薦情報を提供することができる。
推薦情報作成の第3のタイミングは、アイテム提供サーバ20を中継して送られる(ステップS210)、端末装置30の利用リクエスト送信(ステップ200)による利用リクエストを所定回数受信するごとである。この所定回数を調整することにより、情報選択装置10の処理負荷の大きさと、推薦情報の新しさとのバランスを調整することができる。所定回数を1回として、利用リクエストを受信するごとに推薦情報を作成するようにすれば、情報選択装置10の処理負荷は大きくなるが、最新の推薦情報を提供することができる。
以下の説明において、推薦情報を作成する対象となる基準識別子の集合を「推薦基準集合」と称する。第1のタイミングで推薦情報を作成する場合は基本的に、推薦基準集合の要素数が多数となる。第2および第3のタイミングで推薦情報を作成する場合は、推薦基準集合の要素数は基本的に1つであるが、複数の場合もある。
まず、ステップS400において、制御部110の指示を受けた関連度算出部104が、「アイテム−アイテム推薦形式」および「アイテム−カテゴリ推薦形式」に対応する2種類の関連度を算出し、これに基づき関連集合を作成し、関連集合を関連集合格納部105に格納させる。
ステップS410において、制御部110の指示を受けた関連度算出部104が、「カテゴリ−アイテム推薦形式」および「カテゴリ−カテゴリ推薦形式」に対応する2種類の関連度を算出して関連集合を作成し、これに基づき関連集合を作成し、関連集合を関連集合格納部105に格納させる。
ステップS420において、制御部110の指示を受けた価格影響度算出部106が、価格情報格納部103を参照しながら、アイテムおよびカテゴリの価格が推薦結果に与える影響の度合いを示す価格影響度を算出する。
ステップS430において、制御部110の指示を受けた情報選択部107が、ステップS400〜S410で算出された関連度、およびステップS420で算出された価格影響度を用いて、選択指標を算出する。
ステップS440において、情報選択部107が、選択指標に基づいて、アイテムまたはカテゴリを選択して、推薦情報格納部108に格納させる。そして、推薦情報作成動作が終了した旨を制御部110に通知する。
<アイテム−アイテム/カテゴリ推薦形式の関連集合作成処理>
「アイテム−アイテム推薦形式」および「アイテム−カテゴリ推薦形式」に対応する関連集合作成処理(ステップS400)について図15のフローチャートを参照して説明する。
ステップS500において、関連度算出部104は、利用履歴格納部102のアイテム利用履歴テーブル102Aに記録されている利用履歴を読み出す。ここでは、すべての利用履歴を読み出してもよいし、所定の条件を満たす利用履歴を読み出してもよい。例えば、図6(b)に示したアイテム利用履歴テーブル102A−2のように利用時期情報を記録した上で、「利用時期が過去4ヶ月以内」「利用時期と現在との差が3日以上かつ30日未満」などのように、「利用履歴の利用時期情報が所定の範囲にある」という条件を満たす利用履歴を読み出してもよい。
また、アイテムごとに利用時期が新しい順に所定個数以内の利用履歴を読み出してもよい。例えば、所定個数を20個とした場合、利用回数が20回以上のアイテムに対しては、利用時期が新しい順に20個ずつの利用履歴を読み出し、利用回数が20回未満のアイテムに対しては、そのアイテムに関するすべての利用履歴を読み出すようにする。このようにすれば、利用頻度が少なく、最近利用されていないようなアイテムに対しても効率よく関連集合を作成することができる。
そして、このステップS500で読み出した利用履歴に含まれるアイテム(アイテム識別子)の集合σを作成する。以下では、このステップで読み出した利用履歴に含まれるアイテムの数(アイテム識別子の種類数)をMs、ユーザの数(ユーザ識別子の種類数)をUsとする。
ステップS510において、関連度算出部104は、推薦基準集合K1を作成する。上述したように、第2タイミングで推薦情報を作成する場合には、推薦リクエストにアイテム識別子(リクエスト基準識別子)が含まれていれば、それを推薦基準集合K1に入れる。推薦リクエストにアイテム識別子ではなくカテゴリ識別子が含まれている場合は、推薦基準集合K1には何も入れず、空集合とする。
第3のタイミングで推薦情報を作成する場合には、利用リクエストに含まれる利用基準アイテム識別子を推薦基準集合K1に入れる。これらのリクエストには、通常は高々1つのアイテム識別子が含まれているが、複数のアイテム識別子が含まれていれば、それらをすべて推薦基準集合K1に入れる。
第1のタイミングで推薦情報を作成する場合は、ステップ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の関連度W[x][y]を算出することができる。
また、ステップS500で読み出された利用履歴から、利用回数に関する情報やユーザがアイテムに対して行なった評価の情報(評価値)が得られる場合は、コサイン尺度やピアソン積率相関係数を用いて関連度を算出してもよい。例えば、ユーザuのアイテムxに対する利用回数または評価値をE[x][u]、ユーザuのアイテムyに対する利用回数または評価値をE[y][u]としたとき、[数2]に示すように、コサイン尺度を用いてアイテムxとアイテムyとの関連度W[x][y]を算出することができる。ここで、Usは、ステップS500で読み出された利用履歴に含まれるユーザの数(ユーザ識別子の種類数)である。
また、[数3]に示すように、ピアソン積率相関係数を用いて、関連度W[x][y]を算出してもよい。
ここで、Ic[x][y]は、アイテムxとアイテムyを共に利用または評価したユーザの集合であり、Ea[x]は、Ic[x][y]に属するユーザによってアイテムxが利用された回数の平均値、または評価された評価値の平均値である。Ea[y]は、Ic[x][y]に属するユーザによってアイテムyが利用された回数の平均値または評価値の平均値である。また、E[x][u]とE[y][u]とのユークリッド距離あるいはその他の距離を用いて、関連度W[x][y]を算出してもよい。
また、利用履歴格納部102に利用時期情報が格納されている場合は、E[x][u]などを算出する際に、利用時期が古い利用履歴より、新しい利用履歴の重みを大きくして算出してもよい。
さらに、ユーザuのアイテムxに対する利用回数または評価値であるE[x][u](x=1〜Ms,u=1〜Us)を行列要素とする行列に対して、主成分分析や数量化3類などの多変量解析を適用し、次元数を削減したベクトルを生成し、コサイン尺度やユークリッド距離などを用いて関連度を算出してもよい。また、上記以外にも、2つのアイテム間の関連性を表わす指標であれば、どのような方法を用いてもよい。
ステップS540において、関連度算出部104は、基準アイテムxに関する関連アイテム集合Ω[x]を作成し、関連集合格納部105に格納させる。関連アイテム集合Ω[x]は、関連識別子がすべてアイテム識別子であるような関連集合である。
関連アイテム集合作成の第1の方法は、ステップS530において基準アイテムxとの関連度を算出したすべてのアイテムを関連アイテム集合Ω[x]に入れる方法である。この方法は、なるべく多くの推薦結果を出力したい場合に適している。
関連アイテム集合作成の第2の方法は、基準アイテムxとの関連度が高いアイテムを選出して関連アイテム集合Ω[x]に入れる方法である。具体的には、基準アイテムxとの関連度が閾値以上の他のアイテムをアイテム集合σから選出する。また、基準アイテムxとの関連度が大きい順に所定値を超えない範囲で他のアイテムを選出してもよい。例えば、基準アイテムxとの関連度が算出されたアイテムの数が所定数に満たない場合は、関連度が算出されたすべてのアイテムを選出し、そうでない場合は、関連度が大きい順に所定数のアイテムを選出すればよい。
さらに、基準アイテムxとの関連度が所定値以上の他のアイテムの中から、関連度が大きい順に所定数を超えない範囲でアイテムを選出し、それらを関連アイテム集合Ω[x]としてもよい。また関連アイテム集合Ω[x]の要素が所定数以上得られるように、関連度の閾値を基準アイテムxごとに調整して選出してもよい。この第2の方法によれば、関連集合格納部105に必要な記憶容量を削減でき、さらにステップS420〜S440の処理を効率よく行なうことができる。
そして、関連度算出部104は、基準アイテムxのアイテム識別子と、関連アイテム集合Ω[x]の各アイテム識別子と、その関連度とを対応させて、関連集合格納部105の関連度テーブル105Aに記録する。具体的には、基準アイテムxのアイテム識別子を図8に示した関連度テーブル105Aの基準アイテム識別子に対応させ、関連アイテム集合Ω[x]の各アイテム識別子を関連度テーブル105Aの関連アイテム識別子に対応させて記録する。
ステップS550において、関連度算出部104は、基準アイテムxに関する関連カテゴリ集合Φ[x]を作成し、関連集合格納部105に格納させる。関連カテゴリ集合Φ[x]は、関連識別子がすべてカテゴリ識別子であるような関連集合である。
関連度算出部104は、図4(a)に示したアイテム情報テーブル101Aを参照しながら、ステップS540で作成された関連アイテム集合Ω[x]を用いて、関連カテゴリ集合Φ[x]を作成する。
関連カテゴリ集合Φ[x]作成の第1の方法では、関連アイテム集合Ω[x]の各要素に対応するカテゴリ識別子を特定し、特定されたカテゴリ識別子ごとの要素数をカウントし、この要素数をアイテムxとカテゴリとの関連度とする。そして、この要素数が所定数以上のカテゴリ識別子を関連カテゴリ集合Φ[x]に入れる。なお、この所定数を「1」として、特定されたカテゴリ識別子をすべて関連カテゴリ集合Φ[x]に入れてもよい。
関連カテゴリ集合Φ[x]作成の第2の方法では、関連アイテム集合Ω[x]の各要素に対応するカテゴリ識別子を特定し、特定されたカテゴリ識別子ごとに、関連アイテム集合Ω[x]の各要素に対応する関連度の合計値を算出し、この合計値を関連度とする。そして、この合計値が所定値以上のカテゴリ識別子を選出して、関連カテゴリ集合Φ[x]に入れる。例えば、関連アイテム集合に、A、B、Cの3つの要素(関連アイテム)が存在し、各々の関連度が「1.0」、「0.8」、「0.4」であり、要素Aはカテゴリ1に対応し、要素Bがカテゴリ2に対応し、要素Cもカテゴリ2に対応する場合、基準アイテムとカテゴリ1との関連度を「1.0」、基準アイテムとカテゴリ2との関連度を「0.8+0.4=1.2」とすればよい。
ある要素に対応するカテゴリ識別子が複数存在する場合は、各要素に対応する関連度をそのまま用いて合計値を算出してもよいし、各要素に対応する関連度をカテゴリ識別子の数で割った値を用いて合計値を算出してもよい。例えば、基準アイテムと要素A(関連アイテムA)との関連度が「1.0」であり、要素Aに、カテゴリ1とカテゴリ3の2つのカテゴリが対応する場合、基準アイテムとカテゴリ1との関連度の要素Aに係る部分を「1.0」としてもよいし、「1.0÷2=0.5」としてもよい。
なお、この所定値を十分小さな値にして、特定されたカテゴリ識別子をすべて関連カテゴリ集合Φ[x]に入れてもよい。また、合計値の大きい順に所定数を越えない数のカテゴリ識別子を選出し、関連カテゴリ集合Φ[x]に入れてもよい。また、アイテム情報テーブル101Aにおいてアイテムxに対応するカテゴリを、関連カテゴリ集合Φ[x]から除外することにより、意外性が比較的大きいカテゴリのみを推薦結果に入れるようにしてもよい。逆に、自明なカテゴリが推薦結果に含まれないことでユーザに違和感を与える可能性がある場合は、除外しなくてもよい。
そして、関連度算出部104は、基準アイテムxのアイテム識別子と、関連カテゴリ集合Φ[x]の各カテゴリ識別子と、その関連度とを対応させて、関連集合格納部105の関連度テーブル105Bに記録する。具体的には、基準アイテムxのアイテム識別子を図8に示した関連度テーブル105Bの基準アイテム識別子に対応させ、関連カテゴリ集合Φ[x]の各カテゴリ識別子を関連度テーブル105Bの関連カテゴリ識別子に対応させて記録する。
ステップS560において、関連度算出部104は、他の基準アイテムを選択可能か判定する。ステップS510で作成された推薦基準集合K1の中で、まだ処理を行なっていないアイテムが存在する場合に「Yes」と判定し、未処理のアイテムが存在しない場合は、「No」と判定する。「Yes」と判定した場合は、ステップS520に戻って処理を繰り返し、「No」と判定した場合は、関連度算出処理を終了する。
この結果、関連集合格納部105の関連度テーブル105A、Bには、ステップS510で作成された推薦基準集合K1の基準識別子それぞれに対応し、「アイテム−アイテム推薦形式」および「アイテム−カテゴリ推薦形式」に対応する関連集合が格納される。
<カテゴリ−アイテム/カテゴリ推薦形式の関連集合作成処理>
「カテゴリ−アイテム推薦形式」および「カテゴリ−カテゴリ推薦形式」に対応する関連集合作成処理(ステップS410)について図16のフローチャートを参照して説明する。
ステップS600において、関連度算出部104は、まずステップS500と同様に利用履歴読み出し処理を行なう。ステップS500で読み出された利用履歴をそのまま使用してもよいし、別の条件で利用履歴を読み出してもよい。そして、アイテム情報テーブル101Aを参照しながら、読み出された利用履歴に含まれるアイテム識別子に対応するカテゴリ識別子を特定し、特定されたカテゴリ識別子の集合であるカテゴリ集合ρを作成する。なお、図5(d)に示したような、ユーザ識別子とカテゴリ識別子とを直接対応させたカテゴリ利用履歴テーブル102Bを利用履歴格納部102に格納している場合は、アイテム情報テーブル101Aを参照する必要がないため、効率よく処理を行なうことができる。
ステップS610において、関連度算出部104は、推薦基準集合K2を作成する。第2のタイミングで推薦情報を作成する場合には、推薦リクエストに含まれるカテゴリ識別子(リクエスト基準識別子)が含まれていれば、それを推薦基準集合K2に入れる。推薦リクエストにカテゴリ識別子ではなくアイテム識別子が含まれている場合は、推薦基準集合K2には何も入れず、空集合とする。
また、第3のタイミング推薦情報を作成する場合には、アイテム情報テーブル101Aを参照しながら、利用リクエストに含まれる利用基準アイテム識別子に対応するカテゴリ識別子を特定し、これを推薦基準集合K2に入れる。
第2のタイミングの場合、推薦基準集合K2には、通常は1つのカテゴリ識別子が含まれるが、複数のカテゴリ識別子識別子が含まれていてもよい。第1のタイミングで推薦情報を作成する場合は、ステップS600で作成されたカテゴリ集合ρを推薦基準集合K2とする。なお、ここで作成された推薦基準集合K2は、情報選択部107、制御部110などの他の処理部から参照することができる。
ステップS620において、関連度算出部104は、ステップS610で作成された推薦基準集合K2の中から未処理のカテゴリを1つ選択する。この処理対象となるカテゴリを基準カテゴリpとする。
ステップS630において、関連度算出部104は、ステップS600で読み出された利用履歴を用いて、基準カテゴリpと、カテゴリ集合ρに属する他カテゴリq(q∈ρ、p≠q)との関連度を算出する。ステップS530におけるxをpに対応させ、yをqに対応させ、アイテムごとの利用回数やユーザ数をカテゴリごとの利用回数やユーザ数に置き換えることで、ステップS530と同様に、種々の算出方法を用いることができる。また、ユーザのアイテムに対する評価値が得られる場合は、アイテム情報テーブル101Aを参照しながら、そのアイテムに対応するカテゴリを特定し、カテゴリごとに評価値の平均値を算出して用いればよい。
ステップS640において、関連度算出部104は、基準カテゴリpに関する関連カテゴリ集合Π[p]を作成し、関連集合格納部105に格納させる。関連カテゴリ集合Π[p]は、関連識別子がすべてカテゴリ識別子であるような関連集合である。ステップS540におけるアイテムをカテゴリに置き換えて同様の処理を行なえばよく、ステップS540で説明した第1または第2の方法により、関連カテゴリ集合Π[p]を作成し、基準カテゴリpを図8に示した関連度テーブル105Dの基準カテゴリ識別子に対応させ、関連カテゴリ集合Π[p]の各カテゴリ識別子を関連度テーブル105Dの関連カテゴリ識別子に対応させて記録する。
ステップS650において、関連度算出部104は、基準カテゴリpに関する関連アイテム集合Δ[p]を作成し、関連集合格納部105に格納させる。関連度算出部104は、アイテム情報テーブル101Aを参照しながら、ステップS600で読み出した利用履歴と、ステップS640で作成された関連カテゴリ集合Π[p]とを用いて、関連アイテム集合Δ[p]を作成する。
関連アイテム集合Δ[p]作成の第1の方法では、関連カテゴリ集合Π[p]の各要素に対応するアイテム識別子をすべて特定し、特定されたアイテム識別子ごとの要素数をカウントし、この要素数をカテゴリpとアイテムとの関連度とする。そして、この要素数が所定数以上のアイテム識別子を関連アイテム集合Δ[p]に入れる。なお、この所定数を「1」として、特定されたアイテム識別子をすべて関連アイテム集合Δ[p]に入れてもよい。
関連アイテム集合Δ[p]作成の第2の方法では、関連カテゴリ集合Π[p]の各要素に対応するアイテム識別子をすべて特定し、特定されたアイテム識別子ごとに、関連カテゴリ集合Π[p]の各要素に対応する関連度の合計値、あるいは関連度をアイテム識別子の数で割った値の合計値を算出し、この合計値を基準カテゴリとアイテムとの関連度とする。例えば、関連カテゴリ集合に、AとBの2つの要素があり、各々の関連度が「1.0」と「0.9」であり、要素Aはアイテム1に対応し、要素Bはアイテム1、アイテム2、アイテム3に対応する場合、基準カテゴリとアイテム1との関連度を「1.0+0.9=1.9」として算出してもよいし、「1.0+0.9÷3=1.3」として算出してもよい。
そして、この合計値が所定値以上のアイテム識別子を選出して、関連アイテム集合Δ[p]に入れる。なお、この所定値を十分小さな値にして、特定されたアイテム識別子をすべて関連アイテム集合Δ[p]に入れてもよい。また、合計値の大きい順に所定数を越えないアイテム識別子を選出し、関連アイテム集合Δ[p]に入れてもよい。なお、アイテム情報テーブル101Aにおいて、カテゴリpに対応するアイテムを、関連アイテム集合Δ[p]から除外してもよいし、除外しなくてもよい。
そして、関連度算出部104は、基準カテゴリpのカテゴリ識別子と、関連アイテム集合Δ[p]の各アイテム識別子と、その関連度とを対応させて、関連集合格納部105に格納する。具体的には、基準カテゴリpのカテゴリ識別子を図8に示した関連度テーブル105Cの基準カテゴリ識別子に対応させ、関連アイテム集合Δ[p]の各アイテム識別子を関連度テーブル105Dの関連アイテム識別子に対応させて記録する。
ステップS660において、関連度算出部104は、他の基準カテゴリを選択可能か判定する。ステップS610で作成された推薦基準集合K2の中で、まだ処理を行なっていないカテゴリが存在する場合に「Yes」と判定し、未処理のカテゴリが存在しない場合は、「No」と判定する。「Yes」と判定した場合は、ステップ620に戻って処理を繰り返し、「No」と判定した場合は、関連度算出処理を終了する。
この結果、関連集合格納部105の関連度テーブル105C、Dには、には、ステップS610で作成された推薦基準集合の基準識別子それぞれに対応し、「カテゴリ−アイテム推薦形式」および「カテゴリ−カテゴリ推薦形式」に対応する関連集合が格納される。
<アイテム−アイテム/カテゴリ推薦形式の関連集合作成処理の変形例>
「アイテム−アイテム推薦形式」および「アイテム−カテゴリ推薦形式」に対応する関連集合作成処理(ステップS400)の変形例について図17のフローチャートを参照して説明する。この方法は、利用履歴格納部102に格納された利用履歴を用いる代わりに、アイテム情報テーブル101Aのデータを用いる。すなわち、この方法を用いる場合は、アイテム提供サーバ20の利用リクエスト中継処理(ステップS210)、情報選択装置10の利用履歴情報格納処理(ステップS220)、および利用履歴格納部102を省略することができる。ただし、アイテム属性格納部101のアイテム情報テーブル101Aにおいて、なるべく多くのアイテムが複数のカテゴリに対応していることが望ましい。
まず、ステップS710において、関連度算出部104は、推薦基準集合K1を作成する。第2のタイミングで推薦情報を作成する場合には、推薦リクエストにアイテム識別子(リクエスト基準識別子)が含まれていれば、それを推薦基準集合K1に入れる。推薦リクエストにアイテム識別子ではなくカテゴリ識別子が含まれている場合は、推薦基準集合K1には何も入れず、空集合とする。推薦リクエストには、通常は高々1つのアイテム識別子が含まれているが、複数のアイテム識別子が含まれていれば、それらをすべて推薦基準集合K1に入れる。第1のタイミングで推薦情報を作成する場合は、アイテム情報テーブル101Aに記録されているすべてのアイテム(アイテム識別子)の集合Λを推薦基準集合K1とする。
ステップS720において、関連度算出部104は、ステップS710で作成された推薦基準集合K1の中から未処理のアイテムを1つ選択する。この処理対象となるアイテムを基準アイテムxとする。
ステップS730において、関連度算出部104は、基準アイテムxと、アイテム集合Λに属する他アイテムy(y∈Λ、x≠y)との関連度を算出する。具体的には、アイテム情報テーブル101Aを参照しながら、基準アイテムxとアイテムyとに共通するカテゴリの数|H[x]∩H[y]|を算出し、これを関連度とすることができる。また、アイテムxとアイテムyの少なくとも一方に対応するカテゴリの数を|H[x]∪H[y]|としたとき、[数4]に示すように、ジャカード(Jaccard)係数を用いてアイテムxとアイテムyの関連度W[x][y]を算出することができる。
また、これ以外にも、2つのアイテム間の類似性を表わす指標であれば、どのような方法を用いてもよい。なお、アイテムの価格情報をアイテム情報テーブル101Aに記録し、アイテムxとアイテムyの価格情報の差を反映させて関連度を算出してもよい。
ステップS740において、関連度算出部104は、基準アイテムxに関する関連アイテム集合Ω[x]を作成し、関連集合格納部105に格納させる。ステップS540と同様な方法を用いて、関連アイテム集合Ω[x]を作成すればよい。
ステップS750において、関連度算出部104は、基準アイテムxに関する関連カテゴリ集合Φ[x]を作成し、関連集合格納部105に格納させる。ステップS550と同様な方法を用いて、関連カテゴリ集合Φ[x]を作成すればよい。
ステップS760において、関連度算出部104は、別の基準アイテムを選択可能か判定する。ステップS710で作成された推薦基準集合K1の中で、まだ処理を行なっていないアイテムが存在する場合に「Yes」と判定し、未処理のアイテムが存在しない場合は、「No」と判定する。「Yes」と判定した場合は、ステップS720に戻って処理を繰り返し、「No」と判定した場合は、関連度算出処理を終了する。
<カテゴリ−アイテム/カテゴリ推薦形式の関連集合作成処理の変形例>
次に、「カテゴリ−アイテム推薦形式」および「カテゴリ−カテゴリ推薦形式」に対応する関連集合作成処理(ステップS410)の変形例について図18のフローチャートを参照して説明する。この方法は、利用履歴格納部102に格納された利用履歴を用いる代わりに、アイテム情報テーブル101Aのデータを用いる。すなわち、この方法を用いる場合は、アイテム提供サーバ20の利用リクエスト中継処理(ステップS210)、情報選択装置10の利用履歴情報格納処理(ステップS220)、および利用履歴格納部102を省略することができる。ただし、アイテム属性格納部101のアイテム情報テーブル101Aにおいて、なるべく多くのアイテムが複数のカテゴリに対応していることが望ましい。
まず、ステップS810において、関連度算出部104は、推薦基準集合K2を作成する。第2のタイミングで推薦情報を作成する場合には、推薦リクエストに含まれるカテゴリ識別子(リクエスト基準識別子)が含まれていれば、それを推薦基準集合K2に入れる。推薦リクエストにカテゴリ識別子ではなくアイテム識別子が含まれている場合は、推薦基準集合K2には何も入れず、空集合とする。推薦リクエストには、通常は高々1つのカテゴリ識別子が含まれるが、複数のカテゴリ識別子識別子が含まれていてもよい。第1のタイミングで推薦情報を作成する場合は、アイテム情報テーブル101Aに格納されているすべてのカテゴリ(カテゴリ識別子)の集合μを推薦基準集合K2とする。
ステップS820において、関連度算出部104は、ステップS810で作成された推薦基準集合K2の中から未処理のカテゴリを1つ選択する。この処理対象となるカテゴリを基準カテゴリpとする。
次に、ステップS830において、関連度算出部104は、基準カテゴリpと、カテゴリ集合μに属する他カテゴリq(q∈μ、p≠q)との関連度を算出する。具体的には、アイテム情報テーブル101Aを参照しながら、基準カテゴリpおよびカテゴリqに共通に対応するアイテムの数|J[p]∩J[q]|を算出し、これを関連度とすることができる。また、基準カテゴリpとカテゴリqとの少なくとも一方に対応するアイテムの数を|J[p]∪J[q]|としたとき、[数5]に示すように、ジャカード(Jaccard)係数を用いて基準カテゴリpとカテゴリqの関連度W[p][q]を算出することができる。また、これ以外にも、2つのカテゴリ間の類似性を表わす指標であれば、どのような方法を用いてもよい。
ステップS840において、関連度算出部104は、基準カテゴリpに関する関連カテゴリ集合Π[p]を作成し、関連集合格納部105に格納させる。ステップS640と同様な方法を用いて、関連カテゴリ集合Π[p]を作成すればよい。
ステップS850において、関連度算出部104は、基準カテゴリpに関する関連アイテム集合Δ[p]を作成し、関連集合格納部105に格納させる。ステップS650と同様な方法を用いて、関連アイテム集合Δ[p]を作成すればよい。
ステップS860において、関連度算出部104は、他の基準カテゴリを選択可能か判定する。ステップS810で作成された推薦基準集合K2の中で、まだ処理を行なっていないカテゴリが存在する場合に「Yes」と判定し、未処理のカテゴリが存在しない場合は、「No」と判定する。「Yes」と判定した場合は、ステップ820に戻って処理を繰り返し、「No」と判定した場合は、関連度算出処理を終了する。
なお、上述したそれぞれの関連度算出工程において、関連度の最大値や合計値が所定値(例えば「1」)になるように、正規化処理を行なってもよい。
<価格影響度算出処理>
ステップS420における価格影響度算出処理を詳細に説明する。制御部110は、ステップS400およびS410により関連集合格納部105に格納された関連集合(関連識別子)を読み出し、価格情報格納部103を参照しながら、各関連識別子に対応する価格情報を価格影響度算出部106に入力し、価格影響度を算出させる。
例えば、関連識別子がアイテム識別子「ItemID−3」である場合は、図6(a)に示したアイテム価格情報テーブル103Aを参照し、その価格情報である「300円」を価格影響度算出部106に入力する。また例えば、関連識別子がカテゴリ識別子「CategoryID−3」である場合は、図6(b)に示したカテゴリ価格情報テーブル103Bを参照し、その価格情報である「6000円」を価格影響度算出部106に入力する。
価格影響度算出部106は、価格情報(価格)を入力Xとし、価格情報が推薦結果に与える影響を決める価格影響度を出力Yとする価格影響関数F(X)を内部の記憶領域に記憶している。この関数(対応規則)F(X)は、Xの増加に対して、Yが増加する単調増加区間を有し、かついずれの区間においてもYが減少しない特性を有しており、種々の形状を採用することができる。関数F(X)の特性の例を図19および図20に示す。
図19(a)に示す関数F1(X)は、関数の定義域(0≦X≦Xγ)すべてにおいて、X1<X2である入力に対して、Y1<Y2が常に成立する関数である。すなわち、単調増加関数である。また、Xγは価格情報格納部103に格納されている価格情報の上限である。このように、価格情報格納部103に格納されている価格情報に応じて、関数の入力の上限を設定してもよいし、関数の入力の上限を特に設定しなくてもよい。このような全区間が単調増加の線形関数を用いると、処理が比較的単純になり、情報選択装置10の処理負荷を低減することができる。また本図の例のように、X=0のときにY=0となる関数を用いると、後述するように、価格が「0」の無料のアイテムおよびカテゴリを推薦結果に含めないことが容易にできる。
図19(a)に示した関数F1(X)は線形関数であるが、以下のような非線形関数を用いることもできる。非線形関数を用いることにより、価格影響度をよりきめ細かく、高い精度で算出することができる。
図19(b)に示す関数F2(X)は、0≦X≦XαにおいてY=Yαで一定であり、Xα<X<Xβにおいて単調増加し、Xβ≦XにおいてY=Yβで一定であるような特性を持つ関数である。すなわち、一部の区間は単調増加であり、かつ単調減少区間を持たない関数である。ここで、単調減少区間とは、X1<X2である入力に対して、Y2>Y1である出力が得られる区間である。
なお本図の例では、単調増加区間が1つであるが、複数の単調増加区間を持つ関数を用いてもよい。また本図の例では関数の中央の区間(Xα<X<Xβ)が単調増加であり、その両側の区間が出力一定区間であるが、他の特性であってもよい。例えば、左側の出力一定区間を無くし、0≦X<Xβの区間を単調増加としてもよいし、右側の出力一定区間を無くし、Xα<Xの区間を単調増加としてもよい。また、Yαを0としてもよい。
本図の例のように、単調増加区間と出力一定区間とを組み合せた関数を用いると、価格影響度の算出の自由度を大きくすることができる。例えば、Yαをある程度大きな値にすれば、価格の安いアイテムおよびカテゴリもある程度推薦結果に入りやすくなる。
図19(c)に示す関数F3(X)は、階段状の離散的特性を持つ関数である。本図の例ように、価格影響度算出部106aで用いる関数は連続関数でなくてもよい。本図の線分の端点の黒丸はその値を含み、白丸はその値を含まないことを示している。例えば、価格情報格納部103にX3<X<X4の区間に対応する価格情報が存在しない場合は、本図に示すように、関数F3(X)のX3<X<X4の区間を定義しないようにしてもよい。また、Yの値は2種類以上であれば、何種類であってもよい。
本図の例のように離散的な関数を用いると、処理が比較的単純になり、情報選択装置10の処理負荷を低減することができる。また出力一定区間が多数ある関数は、細かな価格の違いを価格影響度にあまり反映したくない場合に適している。
図20(a)に示す関数F4(X)は、滑らかな非線形関数である。中央部分で最も勾配(微分係数)が大きく、両側に行くほど勾配が小さくなる特性を持つ。例えば、ロジスティック関数を用いればこのような特性が得られる。本図の例のように滑らかな関数を用いると、価格影響度が急激に変化するのを防ぐことができる。
また、[数6]に示す関数F(x)を用いてもよい。
ここでα1は0より大きい定数であり、α2は0以上の定数であり、γは0より大きい定数である。α2は0であっても、正の値であってもどちらでもよい。γ>1とすると、図20(b)に示す関数F5(X)のように、入力Xが大きいほど勾配(微分係数)が大きい単調増加関数(下に凸な関数)となる。この関数F5(X)は、価格が高いアイテム(カテゴリ)をより多く推薦結果に入れたい場合に適している。
また、0<γ<1とすると、図20(c)に示す関数F6(X)ように、入力が大きいほど勾配が小さい単調増加関数(上に凸な関数)となる。この関数F6(X)は、価格が安いアイテムもある程度推薦結果に入れたい場合に適している。この他に、対数関数や指数関数を用いることができる。
上述した関数F1(X)〜F6(X)はあくまでも例示であり、少なくとも一部の区間で単調増加し、かつ単調減少区間を持たない関数であれば、どのような関数(対応規則)を用いてもよい。そのような関数を用いることにより、価格情報(価格)の大きなアイテム(カテゴリ)の価格影響度がより大きな値となるので、関連度など他の条件が同じであれば、価格の高いアイテムおよびカテゴリを優先的に推薦情報に入れることできる。なお、関連識別子がアイテム識別子であるか、カテゴリ識別子であるかに応じて、特性の異なる関数を用いてもよい。
またさらに、基準識別子の価格情報に応じて、特性の異なる関数を用いてもよい。この場合、制御部110は、価格情報格納部103を参照しながら、各基準識別子に対応する価格情報を価格影響度算出部106に入力し、価格影響度算出部106は、入力された価格情報に応じて、基準識別子ごとに価格影響関数の特性を変える。
例えば、基準識別子の価格情報が所定値以上の場合に、図19(b)に示す関数F2(X)のXαおよびXβを比較的大きな値とし、所定値未満である場合にXαおよびXβを比較的小さな値にするとよい。また、基準識別子の価格情報が大きいほど、図20(b)に示すように、価格影響関数の下に凸の度合いを大きくし、基準識別子の価格情報が小さいほど、図20(c)に示すように、上に凸の度合いが大きくなるようにしてもよい。
このような方法を用いると、基準アイテム(カテゴリ)の価格が高い場合には、価格の比較的高いアイテム(カテゴリ)をより多く推薦結果に入れることができ、基準アイテム(カテゴリ)の価格が安い場合には、価格の比較的安いアイテム(カテゴリ)もある程度推薦結果に入れることができる。基準アイテム(カテゴリ)の価格が高い場合には、推薦結果に価格の高いアイテム(カテゴリ)が多く入っていても、ユーザに不自然な印象を与える可能性が低いので、ユーザの購買意欲が減少するリスクを減らしつつ、価格の高いアイテム(カテゴリ)を推薦することができる。
価格影響度算出部106は、価格影響関数F(X)を数式として内部の記憶領域に記憶しておき、入力が与えられるごとに、その数式に従って価格影響度を算出してもよい。この方式によれば、必要なメモリ量を少なくすることができ、価格影響度を精度よく(高い解像度で)算出することができる。
あるいは、関数F(X)に従って、入力Xに対する出力Yをあらかじめ算出しておき、算出結果の(X,Y)の情報を記憶領域に格納しておいてもよい。例えば、記憶領域のXに相当するアドレスにYの値を格納するLUT(Look-Up Table)方式を用いることができる。この方式によれば、入力が与えられてから出力するまでに、数式を計算する必要がないので、処理量を少なくすることができ、応答時間を短くすることができる。また価格影響度の値が所定の範囲(0以上1以下など)に収まるような正規化を行なってもよいし、行なわなくてもよい。
<選択指標算出処理>
ステップS430における選択指標算出処理を詳細に説明する。制御部110の指示を受けた情報選択部107は、ステップS420で価格影響度が算出された各関連識別子について、その関連度Wと価格影響度Yとを用いて選択指標Sを算出する。この選択指標Sは、関連度Wが大きいほど、かつ価格影響度が大きいほど大きな値となる数値であり、以下の方法で算出する。
選択指標算出の第1の方法は、[数7]を用いる方法である。
すなわち、基準識別子iと関連識別子jとの関連度W[i][j]を基数としてγaを指数とする累乗値を算出し、価格影響度Y[j]を基数としてγbを指数とする累乗値を算出し、それらの乗算値を用いて選択指標S[i][j]を算出する方法である。ここで、βc、γaおよびγbは0より大きな定数である。
この第1の方法では、関連度と価格影響度が両方とも大きい関連識別子が推薦結果に入りやすい。また図19(a)に示したような、価格情報が0のときに価格影響度も0になる特性の関数を用いた場合、価格が0の無料アイテムの選択指標は0になるので、無料アイテムを推薦結果から除外することも簡単にできる。さらにγaおよびγbを調整することにより、推薦結果に入る関連識別子を変えることができる。
例えば、γaを大きくすることにより、関連度W[i][j]が大きい関連識別子がより推薦結果に入りやすくなる。またγbを大きくすることにより、価格影響度Y[j]が大きい関連識別子がより推薦結果に入りやすくなる。なお、βc=γa=γb=1として、関連度と価格影響度との積を選択指標にしてもよい。
選択指標算出の第2の方法は、[数8]を用いる方法である。
すなわち、関連度W[i][j]とβaとの乗算値と、価格影響度Y[j]とβbとの乗算値を算出し、それらの加算値を選択指標S[i][j]とする方法である。ここで、βaおよびβbは0より大きな定数であり、重み係数である。[数8]は、関連度と価格影響度とをそれぞれ重み付けして加算した値といえる。
第2の方法でも、関連度と価格影響度が両方とも大きな関連識別子が最も推薦結果に入りやすいが、第1の方法と比べると、関連度と価格影響度のいずれかが大きい関連識別子も推薦結果に比較的入りやすい。さらにβaおよびβbを調整することにより、推薦結果に入る関連識別子を変えることができる。
例えば、βaを大きくすることにより、関連度W[i][j]が比較的大きい関連識別子がより推薦結果に入りやすくなる。またβbを大きくすることにより、価格影響度Y[j]が比較的大きい関連識別子がより推薦結果に入りやすくなる。なお、βa=βb=1として、関連度と価格影響度との和を選択指標にしてもよい。
選択指標算出の第3の方法は、[数9]を用いる方法である。
すなわち、関連度W[i][j]の対数値とβdとの乗算値と、価格影響度Y[j]の対数値とβeとの乗算値を算出し、それらの加算値を選択指標S[i][j]とする方法である。ここで、βdおよびβeは0より大きな定数であり、重み係数である。[数9]は、関連度の対数値と価格影響度の対数値とをそれぞれ重み付けして加算した値といえる。また、βdおよびβeを調整することにより、推薦結果に入る関連識別子を変えることができる。なお、βd=βe=1として、関連度と価格影響度との和を選択指標にしてもよい。第3の方法は、関連度または価格影響度のダイナミックレンジが広い場合や、両者のダイナミックレンジが大きく異なる場合に適している。
関連度の代わりに、関連度の順位を用いて、順位が高いほど、かつ価格影響度が大きいほど、大きな値となるように選択指標を算出してもよい。例えば、推薦情報格納部108と同様に、関連度が大きいほど高い順位を示す番号(順位番号)を関連集合格納部105に格納しておき、それを用いるようにすればよい。
また、関連度および価格影響度だけでなく、さらに他の情報を用いて選択指標を算出してもよい。例えば、情報選択部107がアイテム属性格納部101を参照して、関連識別子jのアイテム時期情報T[j]を読み出し、関連度W[i][j]が大きいほど、かつ価格影響度Y[j]が大きいほど、かつアイテム時期情報T[j]が新しいほど(処理時点とアイテム時期情報との差が小さいほど)、大きな値となるように選択指標を算出してもよい。
<推薦情報選択処理>
ステップS440における推薦情報選択処理を詳細に説明する。ステップS440において、情報選択部107は、ステップS430で算出された選択指標に基づいて、関連集合の中から関連識別子を選択する。
具体的には、選択指標S[i][j]が所定値θ1以上の関連識別子を関連集合から選択する。または、選択指標S[i][j]が大きい順に所定数η1を超えない数の関連識別子を選択してもよい。例えば、関連集合の要素数が所定数η1に満たない場合は、関連集合の要素をすべて選択し、そうでない場合は、選択指標が大きい順に所定数η1の関連識別子を選択すればよい。
さらに、選択指標が所定値θ2以上の関連識別子を対象にして、選択指標が大きい順に所定数η2を超えない範囲で選択してもよい。この場合、選択指標がθ2以上の関連識別子の数がη2に満たない場合は、θ2以上の関連識別子をすべて選択する。また、基準識別子iに対して、所定数η3個以上の関連識別子が選択できるように所定値θ3を基準識別子ごとに設定し、選択指標がθ3以上の関連識別子を選択してもよい。
なお、第2のタイミングで推薦リクエストを1回受信するごとに推薦情報を作成する場合において、その推薦リクエストに利用主体識別子が含まれていれば、利用履歴格納部102を参照しながら、その利用主体識別子が既に利用したアイテムおよびカテゴリを特定し、それらを除外して(利用済み除外処理を行って)選択集合を作成してもよい。ユーザが1回しか同じアイテム(カテゴリ)を購入しない性質を持つようなアイテム提供サービスでは、このステップS440において利用済みのものを選択集合から除外しておくと、推薦情報格納部108の記憶容量を節約できる。ステップS440において利用済み除外処理を行なう場合、ステップS170での利用済み除外処理を省略してもよいし、再度行なってもよい。ステップS440を実行した後、ステップS170を実行するまでの間に、新たな利用履歴が格納される可能性がある場合は、両方のステップで利用済み除外処理を行なう方が、推薦精度の向上の面では確実である。
このような方法で選択された関連識別子の選択指標に従って、推薦順位を付与する。すなわち、選択指標が大きいほど、高い推薦順位を付与する。そして、基準識別子と、関連識別子と、推薦順位とを対応させて、図7(a)〜図7(d)に示す形式で、推薦情報テーブル108A〜Dを推薦情報格納部108に格納させる。以上、推薦情報選択処理を説明した。
第1実施例の最後に、図21を用いて、推薦情報の具体例を説明する。関連集合格納部105には図21(a)に示すデータが格納されており、基準識別子と関連識別子は共にアイテム識別子であるとする。本図に示すように、「ItemID−1」の関連集合は、「ItemID−3」〜「ItemID−7」の5つのアイテムである。「ItemID−2」の関連集合もまったく同じ5つのアイテムであるが、各々の関連度は異なっているものとする。また、図21(b)に示すように価格情報格納部103には、「ItemID−1」〜「ItemID−7」の7つのアイテムの価格情報が格納されている。
説明を簡単にするため、価格影響度算出部106では、図19(a)に示した関数F1(X)を用いることとし、この関数の傾きが「1」であるとする。情報選択部107では、[数7]を用いて選択指標を算出し、βc=γa=γb=1であるとする。また、情報選択部107は、選択指標の大きい順に3つのアイテムを選択して推薦情報を作成するものとする。
以上の条件において、仮に、価格情報を使わずに関連度だけでアイテムを選択したとすると、図21(a)から明らかなように、「ItemID−1」に対応する推薦アイテムは、1位が「ItemID−3」、2位が「ItemID−4」、3位が「ItemID−5」になる。これらの価格は各々「1000円」「200円」「400円」である。
一方、上述の本実施例を適用した方法で選択指標を算出すると、「ItemID−3」については、「1000×1.0=1000」となる。他のアイテムについても同様に算出した結果を図21(c)に示す。本図において選択指標の大きい順に3つ選択すると、1位が「ItemID−6」、2位が「ItemID−3」、3位が「ItemID−5」となる。各々の価格は「1500円」「1000円」「400円」である。このように、本実施例の方法によれば、関連度だけでアイテムを選択する場合に比べて、価格の高いアイテムを推薦結果に入れることができる。
また、価格情報を使わずに関連度だけでアイテムを選択したとすると、「ItemID−2」に対応する推薦アイテムは、1位が「ItemID−4」、2位が「ItemID−5」、3位が「ItemID−7」になる。これらの価格は各々「200円」「400円」「800円」である。
一方、上述の本実施例を適用した方法で選択指標を算出すると、1位が「ItemID−7」、2位が「ItemID−5」、3位が「ItemID−4」となり、各々の価格は「800円」「400円」「200円」である。この場合は3つのアイテムの価格の合計は、関連度のみを用いた場合と同じになるが、価格の高いアイテムが上位の推薦順位となり、ユーザの目に留まりやすくなる。
また、「ItemID−1」に関する推薦結果には、価格の高い「ItemID−6」と「ItemID−3」が入るが、「ItemID−2」の推薦結果には、これらが入らない。このことからも分かるように、本実施例では、基準アイテムとの関連度が高い場合にのみ価格の高いアイテムが推薦されるので、ユーザに不自然な印象を与えることが少なく、価格の高いアイテムの推薦によって、ユーザの購入意欲が低下してしまうリスクを従来技術よりも減らすことができる。このため、アイテム提供サービスの売上を増大させることが期待できる。
従来技術では、推薦アイテムの価格が所定の範囲(所定の価格帯)に制限されてしまうため、推薦結果のバリエーション(多様性)が少なかったり、推薦アイテム数が少ない場合があった。しかしながら、上記の例で、「ItemID−1」の推薦アイテムの価格が、「1500円」「1000円」「400円」となり、これらの間の「800円」が抜けていることからも分かるように、本実施例の方法では、1つの推薦結果においても価格が所定の範囲に制限されておらず、多様性がある。
また、「ItemID−1」と「ItemID−2」とで推薦アイテムの価格がかなり異なることからも分かるように、基準アイテムの異なる複数の推薦結果の間では、さらに価格のバリエーションが増える。このように、第1実施例の方法によれば、推薦アイテムの価格が所定の範囲(所定の価格帯)に制限されることがない。従って、従来よりも推薦結果のバリエーションが多くなる。また、価格が所定の範囲にある推薦アイテムが少ししか存在しない場合でも、従来技術と異なり、必要十分な数の推薦情報を提供しやすい。このため、長期間にわたり同じユーザに推薦情報を提供する場合であっても、ユーザが推薦情報に飽きてしまうことが少なく、継続的に推薦情報を利用してもらうことができる。
また、従来技術では、価格が所定の範囲にある推薦アイテムが多数存在する場合、それらを精度良く絞り込むことができず、推薦情報が多くなり過ぎる場合があった。推薦情報は本来、多くの情報の中からユーザに有用な情報を絞り込んで提供するものであり、端末装置30の表示装置において、推薦情報が表示できる領域にも限りがあることから、推薦情報を必要十分な数にすることは非常に重要である。第1実施例の方法によれば、算出した選択指標に応じて推薦順位を決め、推薦順位の上位のアイテムを優先的にユーザに提供するので、必要十分な数のアイテムを精度良く絞り込んでユーザに提供できる。
また第1実施例の方法によれば、基準アイテムに関連する価格の高い関連アイテムだけでなく、基準アイテムに関連する価格の高いカテゴリ、基準カテゴリに関連する価格の高いアイテム、基準カテゴリに関連する価格の高いカテゴリの推薦が可能である。すなわち、多様な推薦形式でユーザに情報提供できるので、ユーザの利便性が向上する他、アイテム提供サービスの売上を増大させることが期待できる。
なお、第1実施例では、情報選択装置10が、価格影響度を算出し、選択指標を算出して推薦情報を作成するようにしていたが、これらの処理、あるいは、これらの処理の一部を端末装置30側で行なうようにしてもよい。
この場合、端末装置30のアプリケーション部304に、価格影響度算出部106および情報選択部107に相当する動作を行なわせるようにする。例えば、ステップS160に先立つ適当なタイミングで、アプリケーション部304が、アイテム提供サーバ20を経由して、あるいは直接情報選択装置10から、アイテム情報テーブル101A、カテゴリ情報テーブル101B、関連度テーブル105A〜D、およびアイテム価格情報テーブル103A、カテゴリ価格情報テーブル103Bのデータを取得する。このとき、各々のテーブルの全部のデータを取得してもよいし、リクエスト基準識別子に関係するデータ等の必要なデータのみを取得するようにしてもよい。そして、ステップS160において、推薦リクエストを送信する代わりに、上述の手順に従って価格影響度を算出し、算出した価格影響度と取得した関連度とを用いて、選択指標を算出することで推薦情報を作成する。具体的には、ステップS420、S430、S440、S170に相当する処理をアプリケーション部304が実行すればよい。この場合、アプリケーション部304に、データ取得部、価格影響度算出部、情報選択部が形成されることになる。以下の実施例においても同様に、情報選択装置10の一部の動作を端末装置30で行なうようにしてもよい。
本実施形態に係るネットワークシステムの第3実施例について説明する。第3実施例では、端末装置30を利用するユーザが過去に利用したアイテムの価格に基づいて、価格影響度を算出する関数の特性をユーザごとに変えることができるようになっている。第3実施例において、アイテム提供サーバ20および端末装置30は、第1実施例と同様とすることができる。
図27は、第3実施例における情報選択装置10cの構成を示すブロック図である。本図に示すように、情報選択装置10cは、アイテム属性格納部101と、利用履歴格納部102と、価格情報格納部103と、関連度算出部104と、関連集合格納部105と、価格影響度算出部106cと、情報選択部107cと、送受信部109と、制御部110cと、利用価格情報算出部111と、利用価格情報格納部112とを備えて構成されている。また、情報選択装置10には、情報選択装置10の管理者向けに必要な情報を表示するための表示装置120と、管理者が操作を行なうためのキーボード、マウス等の入力装置130とが接続されている。
すなわち、第3実施例の情報選択装置10bは、第1実施例の情報選択装置10から推薦情報格納部108を省略し、利用価格情報算出部111および利用価格情報格納部112を追加している。また、価格影響度算出部106、情報選択部107、制御部110の動作が一部異なる構成となっている。
制御部110cは、第1実施例と同様に、所定のタイミングで推薦情報作成動作を開始する。ただし本実施形態では、図14のフローチャートにおいてステップS410の後に、図示しないステップS415を実行し、ステップS415が終了した段階で推薦情報作成動作を終了する。価格影響度算出を行なうステップS420以降に相当する処理は、後述するステップS170cにおいて、表示用推薦データを作成する際に行なう。
ステップS415において、制御部110cの指示を受けた利用価格情報算出部111は、利用履歴格納部102を参照しながら、ユーザが利用したアイテムの価格に関する情報である利用価格情報をユーザごとに算出する。
利用価格情報算出部111は、利用履歴格納部102に格納されたすべての利用履歴を読み出してもよいし、図15のステップS500で説明した利用履歴読出処理と同様な方法で、所定の条件を満たす利用履歴を読み出してもよい。
そして、読み出した利用履歴に対応するユーザを対象にして、それぞれのユーザの利用価格情報を算出する。利用価格情報として、例えば、ユーザが過去に利用したアイテムの価格の高さを指標化した価格水準値と、ユーザの利用したアイテムの価格のばらつき度合いを指標化した価格分散値とを用いることができる。ここでは、利用価格情報算出部111は、以下に示す第1〜第6の利用価格情報のうち、1つ以上の値を算出するものとする。
第1の利用価格情報である第1の価格水準値は、ユーザの利用したアイテムの価格の合計値(合計額)を価格水準値とするものである。第1の価格水準値を算出する場合、利用価格情報算出部111は、読み出した利用履歴を参照しながら、ある利用主体識別子(あるユーザ)が利用したアイテムを特定する。そして、価格情報格納部103を参照しながら、特定したアイテムの価格の合計値を算出し、その利用主体識別子に対応する第1の価格水準値とする。第1の価格水準値が大きいユーザは、購買能力の高いユーザと推測できる。なお、合計値そのものではなく、合計値に所定の値を乗じた値や、合計値を所定の値で割った値を第1の価格水準値としてもよい。例えば、合計値の桁数が大きくなるような場合に、所定の値で割って扱い易い桁数の値にしたり、各々の利用価格情報の最大値が「1」になるような正規化を行ってもよい。
第2の利用価格情報である第2の価格水準値は、ユーザの利用したアイテム1つあたりの価格の高さを示す値(代表値)を価格水準値とするものである。第2の価格水準値を算出する場合、利用価格情報算出部111は、読み出した利用履歴を参照しながら、ある利用主体識別子(あるユーザ)が利用したアイテムを特定する。そして、価格情報格納部103を参照しながら、特定したアイテムの価格の分布を求め、その代表値を算出し、その利用主体識別子に対応する第2の価格水準値とする。代表値としては、平均値、中央値、最頻度、四分位値、最大値、最小値などを用いることができる。また、利用回数の多いアイテムに大きな重みを付ける等、利用回数に応じた重みづけ行って代表値を算出してもよい。
第2の価格水準値が大きいユーザは、高額アイテムや高級アイテムを好むユーザと推測できる。また、第2の価格水準値は、アイテムの価格が広い範囲に分布している場合に適している。
第3の利用価格情報である第3の価格水準値は、ユーザの利用したアイテムの価格の所定期間ごとの合計額に関する代表値を価格水準値とするものである。この第3の価格水準値は、ユーザの利用したアイテムの価格の合計額を用いた値であり、所定期間としては、1日間、1週間、1ヶ月間などを用いればよい。また、1回の購入において、複数のアイテムをまとめて利用(購入)できるようなアイテム提供サービスでは、所定期間の合計額の代わりに、1回の利用の合計額に関する代表値を用いてもよい。
第3の価格水準値を算出する場合、利用価格情報算出部111は、読み出した利用履歴を参照しながら、ある利用主体識別子(あるユーザ)が利用したアイテムを所定期間ごとに特定する。そして、価格情報格納部103を参照しながら、特定したアイテムの価格の合計額を所定期間ごとに算出し、その代表値を算出して、その利用主体識別子に対応する第3の価格水準値とする。代表値としては、第2の価格水準値と同様なものを用いることができる。
第3の価格水準値は、ユーザがアイテム提供サービスを利用している期間の長さの影響を受けずに、ユーザの購買能力を判断するのに適している。また第3の価格水準値は、アイテムの価格が狭い範囲に分布していたり、多くのアイテムの価格がほぼ同じような場合に適している。
第4の利用価格情報である第1の価格分散値は、ユーザの利用したアイテム1つあたりの価格のばらつきの大きさ(ばらつき度)を示す値を価格分散値とするものである。第1の価格分散値を算出する場合、利用価格情報算出部111は、読み出した利用履歴を参照しながら、ある利用主体識別子(あるユーザ)が利用したアイテムを特定する。そして、価格情報格納部103を参照しながら、特定したアイテムの価格の分布を求め、そのばらつき度を示す値を算出し、その利用主体識別子に対応する第1の価格分散値とする。具体的には、ばらつき度を示す値として、分散、標準偏差、範囲(最大値−最小値)、四分位範囲(第3四分位値−第1四分位値)などを用いることができる。
第1の価格分散値が大きいユーザは、様々な価格のアイテムを利用するユーザと推測できる。また、第1の価格分散値は、アイテムの価格が広い範囲に分布している場合に適している。
第5の利用価格情報である第2の価格分散値は、ユーザの利用したアイテムの価格の合計額に関するばらつきの大きさ(ばらつき度)を示す値を価格分散値とするものである。この合計額として、例えば、所定期間ごとの合計額を用いることができる。具体的には、第2の価格分散値を算出する場合、利用価格情報算出部111は、読み出した利用履歴を参照しながら、ある利用主体識別子(あるユーザ)が利用したアイテムを所定期間ごとに特定する。そして、価格情報格納部103を参照しながら、特定したアイテムの価格の合計額を所定期間ごとに算出し、そのばらつき度を示す値を算出して、その利用主体識別子に対応する第2の価格分散値とする。ばらつき度を示す値は、第1の価格分散値と同様である。また、1回の利用(購入)あたりの合計額を算出し、そのばらつき度を示す値を算出して、第2の価格分散値としてもよい。
この第2の価格分散値は、アイテムの価格が狭い範囲に分布していたり、多くのアイテムの価格がほぼ同じような場合に適している。第2の価格分散値が小さいユーザは、コンスタントに安定してアイテムを利用するユーザと推測できる。
上述した方法では、ある利用主体識別子(あるユーザ)が利用したアイテム(あるユーザの利用履歴)のみを用いて、第1〜第5の利用価格情報を算出するが、あるユーザおよび他のユーザの利用履歴を用いて算出してもよい。すなわち、あるユーザおよび他のユーザが利用したアイテムの価格に基づいて、あるユーザの利用価格情報を算出してもよい。
例えば、利用価格情報算出部111が利用履歴格納部102から読み出した利用履歴に、Nu人の利用主体識別子が含まれているとして、利用主体識別子ごとにアイテム価格の合計値Ps[u](u=1〜Nu)を算出し、Ps[u]の平均値Paと標準偏差Pbとを算出する。そして[数10]に従ってユーザuの標準得点S[u]、または偏差値等を算出し、第1の利用価格情報に相当する情報である第6の利用価格情報として用いることができる。
この第6の利用価格情報は、あるユーザ(ユーザu)が利用したアイテム価格の合計値が、ユーザ集団の中でどの位置にあるかを相対的に示す情報である。第2〜第5の利用価格情報についても、同様にユーザ集団の中での相対値を算出することができる。
また利用価格情報算出部111は、ある利用主体識別子に対して、アイテム区分ごとに利用価格情報を算出してもよい。ここで、アイテム区分とは、アイテムを所定の基準で分類した情報であり、通常はカテゴリよりも上位の概念の分類である。例えば、アイテム提供サービスにおいて、種々のコンテンツを提供する場合、「音楽」「映画」「書籍」といった上位の階層の分類をアイテム区分とし、アイテム区分が「音楽」のアイテムに対しては、「ロック」「ジャズ」「クラシック」「フォーク」等のジャンル情報をカテゴリとすることができる。アイテム区分が「映画」のアイテムに対しては、「SF」「アクション」「コメディ」「アニメ」「サスペンス」等のジャンル情報をカテゴリとすればよい。
この場合は、アイテム属性格納部101に、各アイテムまたは各カテゴリと、各アイテム区分とを対応させたアイテム区分情報を格納しておく。そして、利用価格情報算出部111はアイテム区分情報を参照しながら、ユーザが利用したアイテムのアイテム区分を特定し、アイテム区分ごとに利用価格情報を算出する。上記の例では、「音楽」に対応する利用価格情報と、「映画」に対応する利用価格情報と、「書籍」に対応する利用価格情報とを算出する。ただし、カテゴリをそのままアイテム区分とするようにしてもよい。
利用価格情報算出部111は、算出した利用価格情報を利用価格情報格納部112に格納させる。利用価格情報格納部112は、図28に示すような形式で、利用主体識別子と、利用価格情報とを対応させて格納する。図28(a)は、アイテム区分を用いない場合の格納形式である利用価格情報テーブル112Aを示している。複数種類(Np個)の利用価格情報が格納されているが、1種類の利用価格情報を格納するようにしてもよい。
図28(b)は、アイテム区分を用いる場合の格納形式である利用価格情報テーブル112Bを示している。アイテム区分1に対応するNp1個の利用価格情報と、アイテム区分2に対応するNp2個の利用価格情報を格納している。ここで、Np1≠Np2として、アイテム区分ごとに異なる数の利用価格情報を算出して格納するようにしてもよい。以上がステップS415の説明である。
第3実施例におけるシステム全体の動作は、処理ステップ間の関係において図11に示したフローチャートと同様であり、ステップS160とS170の具体的内容において第1実施例と一部異なる。第3実施例におけるこれらの処理ステップは、末尾に「c」を付加して表記する。
ステップSl60cにおいて、端末装置30は、関連リンクに対応するURLに推薦リクエストを送信する。第3実施例の推薦リクエストには、利用主体識別子を必ず含めるものとする。
ステップS170cにおいて、情報選択装置10cの制御部110cは、送受信部109を介して、推薦リクエストを受信し、それに含まれるリクエスト基準識別子に対応する表示用推薦データを作成して端末装置30に送信する。以下では、このステップS170cの処理を詳細に説明する。
ステップSl70cでは、第1実施例の推薦情報作成動作の一部である、図14に示したステップS420〜S440に相当する処理(ステップS420c、S430c、S440c)を行なった後に、図示しないステップS450で表示用推薦データを作成する。なお、第2のタイミングで推薦情報を作成する場合は、利用価格情報を算出した後(ステップS415の後)にステップS420c〜440cを実行すればよい。このうち、ステップS430c、S440c、S450は、それぞれ第2実施例のステップS430b、S440b、S450と同じであるため説明を省略し、ステップS420cにおける価格影響度算出処理について詳細に説明する。
制御部110cは、関連集合格納部105の中から、推薦リクエスト(リクエスト基準識別子)に一致する基準識別子を特定し、その基準識別子に対応する関連集合(関連識別子)を読み出す。リクエスト基準識別子が複数ある場合は、対応するすべての関連集合を読み出す。以下では、ここで読み出され関連集合を集合Ψとする。
そして、制御部110cは、価格情報格納部103を参照しながら、集合Ψの各関連識別子に対応する価格情報を取得し、その価格情報と、受信した利用リクエストの利用主体識別子とを価格影響度算出部106cに入力する。利用価格情報格納部112に、図28(b)に示したアイテム区分ごとに利用価格情報が格納されている利用価格情報テーブル112Bを格納している場合には、制御部110cは、アイテム属性格納部101のアイテム情報テーブル101Aを参照しながら、関連識別子に対応するアイテム区分を特定し、そのアイテム区分も加えて価格影響度算出部106cに入力する。
価格影響度算出部106cは、利用価格情報格納部112を参照しながら、入力された利用主体識別子に応じて、価格情報を入力Xとし価格影響度を出力Yとする価格影響関数F(X)の特性を変える。この関数(対応規則)は、第1実施例と同様に、少なくとも一部の区間で単調増加し、かつ単調減少区間を持たない関数であり、図19、図20に示したような種々の特性の関数を用いることができる。
価格影響度算出部106cは、入力された利用主体識別子に対応する利用価格情報を利用価格情報格納部112から読み出す。利用価格情報格納部112に、図28(b)に示した利用価格情報テーブル112Bを格納している場合には、入力された利用主体識別子に対応し、かつ入力されたアイテム区分に対応する利用価格情報を読み出す。
ここでは、利用価格情報格納部112に、ユーザuの価格水準値L[u]が1つ、ユーザuの価格分散値V[u]が1つ格納されており、これらを読み出して利用することとする。ただし、価格水準値と価格分散値のどちらか一方を利用してもよいし、3つ以上の利用価格情報を利用して関数F(X)の特性を決定してもよい。第2実施例と同様に、図25を参照して、関数F(X)の特性の決定方法(選択方法)について説明する。
上述のように、図25(a)は、Fa1(X)〜Fa5(X)(Fa1〜Fa5)の5つの関数を示している。添字の大きい関数ほど、所定の出力値を得るための入力値が大きく、添字の小さい関数ほど所定の出力値を得るために必要な入力が小さくて済む。また、添字の大きい関数ほど所定の入力値に対応する出力値が小さくなるともいえる。また、X≦Xαにおいて、出力値はYαで一定となり、価格がこの区間に相当するアイテム(カテゴリ)は推薦情報に入り難くなるが、添字の大きい関数ほどXαが大きくなる。また、X≧Xβにおいて、出力値はYβで一定となり、価格がこの区間に相当するアイテム(カテゴリ)は推薦情報に入りやすくなるが、添字の大きい関数ほどXβが大きくなる。価格影響度算出部106cは、ユーザuの価格水準値L[u]に応じて、いずれかの関数を選択する。
具体的には、価格水準値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を選択する。すなわち、価格水準値L[u]が大きいほど添字の大きい関数を選択することにより、価格水準値が大きいほど、所定の出力値を得るための入力値が大きくなる傾向で価格影響関数を変化させているといえる。
従って、第3実施例では、どのようなユーザにおいても、関連度が同程度であれば、価格の安いアイテム(カテゴリ)よりも価格の高いものが推薦されやすいという効果に加えて、価格水準値の小さいユーザ、すなわち購買能力の低いユーザや低額アイテムをよく利用するユーザ対しては、価格の安いアイテム(カテゴリ)も比較的推薦結果に入りやすいという効果が得られる。
別の選択方法を、図25(b)を参照して説明する。上述のように、本図は、Fb1(X)〜Fb5(X)(Fb1〜Fb5)の5つの関数を示しており、添字の大きい関数ほど、最大値Yβと最小値Yαとの差(最小値Yαに対する最大値Yβの倍率)が大きく、添字の小さい関数ほど、その差および倍率が小さくなっている。
図25(a)の例と同様に、価格水準値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]が大きいほど添字の大きい関数を選択することにより、価格水準値が大きいほど、出力最大値と出力最小値との差(出力最小値に対する出力最大値の倍率)が大きくなる傾向で価格影響関数を変化させているといえる。また、価格水準値が大きいほど、入力が最小値であるときの出力値(X=0のときの出力値)が小さくなる傾向で価格影響関数を変化させているともいえる。この結果、価格水準値が小さいユーザでは、価格の安いアイテム(カテゴリ)も比較的推薦結果に入りやすいという効果が得られる。
また、ユーザuの価格分散値V[u]を用いて、Fb1〜Fb5を選択してもよい。価格水準値L[u]の場合と同様に、価格分散値V[u]に関する閾値ε1〜ε4(ε1<ε2<ε3<ε4)を用意しておき、価格分散値V[u]が大きいほど添字の大きい関数を選択する。すなわち、価格分散値が大きいほど、出力最大値と出力最小値との差(出力最小値に対する出力最大値の倍率)が大きくなる傾向で価格影響関数を変化させたり、入力が最小値であるときの出力値が小さくなる傾向で価格影響関数を変化させてもよい。また同様に、Fa1〜Fa5を用いて、価格分散値V[u]が大きいほど添字の大きな関数を選択することにより、価格分散値が大きいほど、所定の出力値を得るための入力値が大きくなる傾向で価格影響関数を変化させてもよい。
一般に、価格分散値が小さなユーザは、限られた価格帯のアイテムを利用する傾向や、所定期間ごとの利用アイテムの合計額が安定している傾向がある。すなわち、自分なりの利用パターンが確立しているユーザであるといえる。このようなユーザでは、価格の高いアイテムだけを推薦した場合に受容されないリスクがより高いため、関数Fb1などを用いて、価格の高いアイテムと安いアイテムとの価格影響度の差があまり大きくないようにし、価格の安いアイテム(カテゴリ)も比較的推薦結果に入りやすいようにする。
また、図25(c)に示す関数を用いて、ユーザuの価格水準値L[u]が大きいほど、添字の大きい関数を選択してもよい。すなわち、価格水準値が大きいほど、下に凸の度合いが強くなる傾向で価格影響関数を変化させてもよい。また、価格水準値が大きいほど、入力が最小値であるときの出力値が小さくなる傾向で価格影響関数を変化させてもよい。また、ユーザuの価格分散値V[u]が大きいほど、添字の大きい関数を選択してもよい。
次に、図29を参照して、ユーザuの価格水準値L[u]と価格分散値V[u]を両方用いて、関数F(X)の特性を動的に設定する方法を説明する。価格影響度算出部106cは、図29(a)に示す特性のひな型関数Fu(X)の数式を内部の記憶領域に記憶している。そして、価格影響度算出部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)の特性について、図29(b)および図29(c)を参照し、ユーザu1〜ユーザu5の5人のユーザを例にして説明する。
ユーザu1は、価格の安いアイテムのみを利用するため、ユーザu1の価格水準値L[u1]が5人のユーザの中で最も小さく、価格分散値V[u1]も小さいものとする。図29(b)に示すように、ユーザu1に対応した関数Fu1(X)は、Xc1、Xα1、Xβ1、Xω1、Yω1が小さく、Yα1が大きい。このため、価格の安いアイテムと価格の高いアイテムとの価格影響度の差(倍率)が小さい等により、5人のユーザの中で価格の安いアイテムが最も推薦結果に入りやすくなる。
ユーザu2は、価格の安いアイテムと高いアイテムの両方を利用するが、安いアイテムをより多く利用するため、価格水準値L[u2]が5人の中で2番目に小さく、価格分散値V[u2]は大きいものとする。図29(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に比べると、価格の安いアイテムが推薦結果に入りにくくなる。
ユーザu3は、価格が中程度のアイテムのみ利用するため、価格水準値L[u3]は、ユーザu2の価格水準値L[u2]と同じであり、価格分散値V[u3]は、ユーザu2よりも小さいものとする。図29(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と同程度に大きいものとする。図29(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と同程度に小さいものとする。図29(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であり、価格水準値の小さいユーザに比べて、価格の高いアイテムが推薦結果に入りやすいことは明らかである。
このように第3実施例では、利用価格情報に応じて、ユーザごとに関数F(X)の特性を設定することにより、価格の高いアイテムを優先的に推薦結果に入れることができることに加えて、価格の安いアイテムを主に利用するユーザ等に対しては、価格の安いアイテムも推薦結果に入れることができる。なお、図29で説明に用いた関数Fu(X)は、あくまでも一例であり、他の特性の関数を用いてもよい。
例えば、図30に示す特性の関数Fg(X)を用いて価格影響度を算出してもよい。この場合は、Fu(X)と同様な方法で、関数Fg(X)のパラメータXc、Xω、Yα、Yωを設定する他、価格水準値が小さければ、本図の関数Fg1のように上に凸の度合いが強い特性とし、価格水準値が中程度であれば、本図の関数Fg2のように線形に近い特性とし、価格水準値が大きければ、本図の関数Fg3のように下に凸の度合いが強い特性とする。
また、上述した説明では、1つの価格水準値と、1つの価格分散値とを使って関数の特性を設定したが、より多くの利用価格情報を用いて関数の特性を設定してもよい。複数の利用価格情報をそれぞれ別々の関数パラメータに対応させてもよい。また、複数の利用価格情報を1つの関数パラメータに対応させてもよい。例えば、第2の利用価格情報である、ユーザの利用したアイテム1つあたりの価格の高さを示す値(代表値)と、第3の利用価格情報である、ユーザの利用したアイテムの価格の合計額に関する代表値とを用いて、1つの関数パラメータを決定してもよい。
また、各々の関数パラメータを複数の利用価格情報を用いて決定する場合に、各利用価格情報を各次元に対応させた多次元情報空間を用いてもよい。例えば、多次元情報空間を適当な小領域に分割し、各々の小領域に対して関数パラメータの値を対応させる方法により、関数の特性を設定してもよい。また、各利用価格情報の重み付き平均などを用いて1次元の値を算出し、それに基づいて関数パラメータを決定してもよい。
第3実施例においても、第1実施例と同様に基準識別子の価格情報に応じて、価格影響関数の特性を設定することができる。例えば、図29に示した関数Fu(X)において、価格水準値L[u]が大きいほど、かつ基準識別子の価格情報が大きいほど、Xcの値が大きくなるような規則を用いて関数の特性を設定してもよい。また、図30に示した関数Fg(X)において、価格水準値L[u]が大きいほど、かつ基準識別子の価格情報が大きいほど、下に凸の度合いが強くなる規則や、価格水準値が小さいほど、かつ基準識別子の価格情報が小さいほど、上に凸の度合いが強くなる規則を用いて、関数の特性を設定してもよい。以上がステップS420cの説明である。
第3実施例によれば、価格の高いアイテムおよびカテゴリを推薦結果に多く入れることが可能である等、第1実施例と同様な効果が得られる。さらにそれらに加えて、ユーザごとに利用価格情報に応じて適切な価格影響度を算出するため、ユーザに特別な操作をさせることなく、ユーザが受容しやすい推薦情報を提供できる。例えば、価格の安いアイテムだけを利用するユーザには、推薦情報の中に、価格の高いアイテムだけでなく、価格の安いアイテムもある程度入れることができる。従って、ユーザが推薦情報を納得して受け入れやすくなる。このため推薦情報に基づくアイテム利用が活発になり、アイテム提供サービスの売上をさらに増大させることが期待できる。
なお、第2実施例と第3実施例とを組み合わせて、ユーザごとに利用価格情報に応じて価格影響関数を設定した上で、ユーザの好みに応じてこの特性を変更できるようにしてもよい。このようにすれば、さらに受容性の高い推薦情報を提供することができる。