JP6060785B2 - 情報選択装置、情報選択方法、および情報選択プログラム - Google Patents

Description

本発明は、アイテムを提供するネットワークシステムにおいて、ユーザに推薦するアイテムを選択する情報選択技術に関する。

近年、デジタル技術やネットワーク技術の進展により、ネットワークを使ってデジタルコンテンツや物品などのアイテムを配信したり、販売することが増えている。これに伴い、多数のアイテムの中から、ユーザにとって有用なアイテムを推薦する技術へのニーズが高まっている。このニーズに応えるため、ユーザのアイテムに対する評価情報や利用情報を用いてアイテムを推薦する技術がいくつか提案されている。

例えば、特許文献１には、ユーザが過去に購入した商品の価格帯情報に基づいてそのユーザに推薦する商品の価格帯を設定することで、ユーザが購入する可能性が高い商品を効果的に推薦することが提案されている。このとき、過去の購入価格帯よりも所定価格分高い価格帯あるいは所定価格分低い価格帯の商品を推薦することで、売上の増加を図ったり、ユーザに割安感を感じさせたりするようにしている。
また、特許文献２には、ユーザの金融資産等の変動額に基づいて、価格帯の異なるカテゴリの商品を推薦することが提案されている。

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

販売側の視点からは、高い価格帯のアイテムを推薦することで売上が増加することが好ましい。一方で、ユーザは他の条件が同じであれば、基本的に価格の安い商品を好むため、むやみに価格の高い商品を推薦することは、推薦情報がユーザに受容されず、購入意欲を低下させるというリスクを伴っている。

ところで、ユーザが高いと感じるか安いと感じるかは、単にアイテムの価格のみならず、アイテムを推薦するタイミングにも依存するため、価格が高いアイテムであっても、ユーザの購入意欲が低下しない場合もある。また逆に、価格が高いアイテムを推薦すると、ユーザの購入意欲が低下するため、価格が安いアイテムを推薦した方が、全体の売上が増大する場合もある。しかしながら、特許文献１に開示の技術では、特定の価格帯の商品を推薦する場合に、推薦するタイミングを考慮していない。特許文献２に開示の技術では、ユーザの金融資産の変動情報に基づいて、推薦する商品の価格帯を決定しているため、ユーザの金融資産の情報を遅延なく取得する必要がある。しかしながら、ユーザの金融資産に関する情報は極めて厳重な管理が必要な個人情報であるため、そのような情報を利用できるサービスや事業者は、極めて限られたものになり、幅広いサービスに応用することはできない。

そこで、本発明は、所定の時点からの経過時間に応じて、情報選択における価格の優先度を調整してアイテム又はカテゴリを選択することを目的とする。

本発明は上記課題を解決するため、下記の装置、方法及びプログラムを提供する。
（１）アイテムを識別する識別子またはアイテムごとに定められたカテゴリを識別する識別子それぞれに係る価格情報を取得し、価格影響関数を用いて、前記価格情報を前記価格影響関数に入力して得られる価格影響度を、識別子それぞれについて算出する価格影響度算出部（１０６）と、前記価格影響度が算出された識別子の中から、前記価格影響度に基づき決定された選択指標の大きな識別子を優先的に選択する情報選択部（１０７）とを備え、前記価格影響度算出部は、所定の時点からの経過時間に応じて前記価格影響関数の特性を設定し、前記価格影響度を算出することを特徴とする情報選択装置。

（２）アイテムを識別する識別子またはアイテムごとに定められたカテゴリを識別する識別子それぞれに係る価格情報を取得し、価格影響関数を用いて、前記価格情報を前記価格影響関数に入力して得られる価格影響度を、識別子それぞれについて算出する価格影響度算出ステップと、前記価格影響度が算出された識別子の中から、前記価格影響度に基づき決定された選択指標の大きな識別子を優先的に選択する情報選択ステップとを備え、前記価格影響度算出ステップは、所定の時点からの経過時間に応じて前記価格影響関数の特性を設定し、前記価格影響度を算出することを特徴とする情報選択方法。

（３）コンピュータに、アイテムを識別する識別子またはアイテムごとに定められたカテゴリを識別する識別子それぞれに係る価格情報を取得し、価格影響関数を用いて、前記価格情報を前記価格影響関数に入力して得られる価格影響度を、識別子それぞれについて算出する価格影響度算出工程と、前記価格影響度が算出された識別子の中から、前記価格影響度に基づき決定された選択指標の大きな識別子を優先的に選択する情報選択工程とを実行させ、前記価格影響度算出工程は、所定の時点からの経過時間に応じて前記価格影響関数の特性を設定し、前記価格影響度を算出することを特徴とする情報選択プログラム。

本発明によれば、所定の時点からの経過時間に応じて、情報選択における価格の優先度を調整してアイテム又はカテゴリを選択することができる。

本実施形態に係るネットワークシステム全体の構成を示すブロック図である。 本実施形態に係るネットワークシステム全体の別構成を示すブロック図である。 第１実施例における情報選択装置の構成を示すブロック図である。 アイテム属性格納部に格納されているアイテム情報テーブルとカテゴリ情報テーブルの例を示す図である。 利用履歴格納部に格納されるアイテム利用履歴テーブルとカテゴリ利用履歴テーブルの例を示す図である。 価格情報格納部に格納されるアイテム価格情報テーブルとカテゴリ価格情報テーブルの例を示す図である。 推薦情報格納部に格納される推薦情報テーブルの例を示す図である。 関連集合格納部に格納される関連度テーブルの例を示す図である。 アイテム提供サーバの構成を示すブロック図である。 端末装置の構成を示すブロック図である。 システム全体の動作を説明するフローチャートである。 情報提供に係る初期画面を表示する画面例を示す図である。 推薦リストを表示する画面例を示す図である。 情報選択装置が推薦情報を作成する動作について説明するフローチャートである。 「アイテム推薦形式」および「カテゴリ推薦形式」に対応する関連集合作成処理について説明するフローチャートである。 価格情報を入力Ｘとし、価格影響度を出力Ｙとする価格影響関数Ｆ（Ｘ）の特性例を示す図である。 価格情報を入力Ｘとし、価格影響度を出力Ｙとする価格影響関数Ｆ（Ｘ）の特性例を示す図である。 価格情報を入力Ｘとし、価格影響度を出力Ｙとする価格影響関数Ｆ（Ｘ）の特性例を示す図である。 推薦情報の具体例を説明するための図である。 第２実施例における情報選択装置の構成を示すブロック図である。 第２実施例における情報提供に係る初期画面を表示する画面例を示す図である。 価格影響度を調整するために必要なデータの入力画面例を示す図である。 価格影響関数Ｆ（Ｘ）の特性の変化の例を示す図である。 指定された価格影響度を含んだ推薦リストを表示する画面例を示す図である。 第３実施例における情報選択装置の構成を示すブロック図である。 利用価格情報格納部に格納される利用価格情報テーブルの例を示す図である。 価格水準値と価格分散値を両方用いて、関数Ｆ（Ｘ）の特性を動的に設定する方法を説明する図である。 関数Ｆ（Ｘ）の特性を動的に設定する方法の別例を説明する図である。 関数Ｆ（Ｘ）の特性を動的に設定する方法の別例を説明する図である。 関数Ｆ（Ｘ）の特性を動的に設定する方法の別例を説明する図である。 利用価格情報として算出される確率関数と、それに基づく価格影響関数を説明する図である。

本発明の一実施の形態であるネットワークシステムについて図面を参照して説明する。以下では、まずシステム全体構成を説明し、その後、第１実施例〜第３実施例の順番で各構成の具体例および具体的動作例について説明する。
＜システム全体構成＞

図１は、本実施形態に係るネットワークシステム全体の構成を示すブロック図である。本図に示すように、ネットワークシステムは、アイテム等の情報を選択する情報選択装置１０と、アイテム提供サーバ２０と、１台以上の端末装置３０（図中では３０Ａ〜３０Ｎ、本実施形態では「端末装置３０」と総称する）がネットワーク４０を介して接続されて構成される。ここで、情報選択装置１０とアイテム提供サーバ２０により、端末装置３０を使用するユーザに対してアイテム提供等のサービスを行なうアイテム提供システム１を構成している。ネットワーク４０は、インターネットに代表される広域ネットワークとすることができる。また、端末装置３０とネットワーク４０との接続形態は、有線・無線を問わない。

ネットワークシステムは、図２に示すような構成としてもよい。すなわち、ネットワーク４０にアイテム提供サーバ２０と１台以上の端末装置３０（３０Ａ〜３０Ｎ）が接続され、情報選択装置１０がネットワーク４０とは別のネットワーク４２を介してアイテム提供サーバ２０と接続している構成である。この場合、ネットワーク４２を介して接続された情報選択装置１０とアイテム提供サーバ２０により、アイテム提供システム２を構成する。ネットワーク４２は、例えば、ＬＡＮ（Local
Area Network）等とすることができ、セキュリティ確保の観点から、端末装置３０から情報選択装置１０への直接的なアクセスは制限することが望ましい。

ただし、ネットワークシステムは、上記の例に限られず、種々の構成を用いることができる。例えば、情報選択装置１０とアイテム提供サーバ２０とを同一の装置で構成してもよいし、それぞれを複数台の装置で構成するようにしてもよい。以下では、図１に示した構成でネットワークシステムを実現した場合を例に説明する。

本実施形態におけるアイテムは、ユーザに対して提供対象となるものであり、テキスト、音声、音楽、画像、映像、プログラム等のデジタルコンテンツ、様々な物品、金融商品、不動産、人物情報、ネットワークサービス等を含めることができ、有形か無形かを問わない。また、本実施形態では、各アイテムには、アイテムを分類するための情報であるカテゴリが１つ以上定められているものとするが、カテゴリを用いないで動作することも可能である。

本実施形態に係るアイテム提供サービスにおいて、アイテムは基本的に有料であるが、無料のアイテムが存在してもよい。また、アイテム提供の都度、ユーザに対する課金を行ってもよいが、所定の期間ごとに所定金額を課金してもよい。例えば、毎月１日または入会日に月会費として１０００円を徴収し、その月に合計１０００円（１０００ポイント）相当のアイテムを自由に組合せて利用できるようにしてもよい。ユーザがその月に１０００円を超えてアイテムを利用したい場合は、追加ポイント（例えば、５００円、１０００円、２０００円など）を購入して、追加ポイントに相当する金額までのアイテムを利用できるようにすればよい。また追加ポイントをユーザに購入させることなく、月会費を越えた分のアイテムに関して、個別に課金を行ってもよい。また、月会費の徴収は、ユーザが会員である限り、自動的に継続するようにしてもよい。また、月会費に相当するポイントをその月に使い切らなかった場合、翌月には繰り越せない（翌月には失効する）ようにしてもよいし、余ったポイントを翌月以降に繰り越して使えるようにしてもよい。また、繰り越しを認める場合、最大６ヶ月後まで繰り越し可などのように、期限を設けてもよい。また、月会費制だけではなく、週単位、年単位、３ヶ月毎など、任意の期間（任意の周期）ごとに会費を徴収し、その対価として一定金額までのアイテムを利用させるようにしてもよい。

以下、上記構成のネットワークシステムについての実施例を説明する。各実施例について同じブロックについては同じ符号を付すものとし、同じブロックで動作が異なる場合は、第２実施例について「ｂ」、第３実施例について「ｃ」を符号の末尾に付加して説明する。
（実施例１）
＜情報選択装置＞

図３は、第１実施例における情報選択装置１０の構成を示すブロック図である。本図に示すように情報選択装置１０は、アイテム属性格納部１０１と、利用履歴格納部１０２と、価格情報格納部１０３と、関連度算出部１０４と、関連集合格納部１０５と、価格影響度算出部１０６と、情報選択部１０７と、推薦情報格納部１０８と、送受信部１０９と、制御部１１０とを備えて構成されている。また、情報選択装置１０には、情報選択装置１０の管理者向けに必要な情報を表示するための表示装置１２０と、管理者が操作を行なうためのキーボード、マウス等の入力装置１３０とが接続されている。

情報選択装置１０は、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＨＤＤ（ハードディスクドライブ）、ネットワークインタフェース等を備える一般的なコンピュータを用いて構成することができる。すなわち、一般的なコンピュータは、以下で説明するような処理を行なうためのコンピュータプログラムを実行することにより、情報選択装置１０として機能することができるようになる。

また、上述のように、情報選択装置１０を複数台のコンピュータを用いて構成してもよい。例えば、負荷分散をするために、情報選択装置１０のある処理ブロックに相当するコンピュータを複数台用いて、すなわち、同じ処理ブロックを備える複数台のコンピュータを用いて分散処理を行なうようにしてもよい。また、情報選択装置１０の一部の処理ブロックをあるコンピュータで実施し、他の処理ブロックを別のコンピュータで実施する形態で分散処理を行なってもよい。また、図３に示す処理ブロックを全て備えるコンピュータを複数台用いて分散処理を行ってもよい。

アイテム属性格納部１０１は、アイテムに関する情報が記録されたアイテム情報テーブル１０１Ａと、カテゴリに関する情報が記録されたカテゴリ情報テーブル１０１Ｂとを格納している。

図４（ａ）は、アイテム情報テーブル１０１Ａの一例を示している。本図に示すように、アイテム情報テーブル１０１Ａは、アイテム識別子（アイテムＩＤ）と、アイテム属性情報とを対応させたテーブルである。アイテム属性情報は、アイテムの「タイトル（名称）」「カテゴリ識別子」「説明情報」「アイテム時期情報」などで構成されている。

図４（ｂ）は、カテゴリ情報テーブル１０１Ｂの一例を示している。本図に示すように、カテゴリ情報テーブル１０１Ｂは、カテゴリ識別子（カテゴリＩＤ）とカテゴリ属性情報とを対応させたテーブルである。カテゴリ属性情報は、「カテゴリ名」「カテゴリ説明」などで構成されている。２つのテーブルに存在する「カテゴリ識別子」を介して、アイテム情報テーブル１０１Ａのアイテム情報とカテゴリ情報テーブル１０１Ｂのカテゴリ情報とを関連付けることができる。

ここで、カテゴリとは、アイテムを所定の基準で分類した情報であり、１つのアイテムについて１個以上設定される。カテゴリは、例えば、アイテムの「クリエイター（作成者）」とすることができる。なお「クリエイター」は、アイテムの制作者、監督、プロデューサー、執筆者、作曲者、作詞者、演奏者、出演者等である。

また、アイテムが音楽コンテンツの場合、「ロック」「ジャズ」「クラシック」「フォーク」等のジャンル情報をカテゴリとすることができ、アイテムが映画の場合、「ＳＦ」「アクション」「コメディ」「アニメ」「サスペンス」等のジャンル情報をカテゴリとすることができる。さらには、「日本」「アメリカ」「イギリス」など作成者の国や地域を用いた分類情報や、「癒し系」「エキサイティング」「ドラマティック」といったアイテムの雰囲気やムードを示す情報をカテゴリとして用いてもよい。

アイテム属性情報の「説明情報」は、アイテムのあらすじや要約、制作された背景説明などの情報である。「アイテム時期情報」は、アイテムの作成された時期（時点）を示す情報である。ただし、アイテム提供サーバ２０にアイテムが登録された時期や、アイテムが提供開始された時期を用いてもよい。本実施形態では、時期（時点）の表現形式として、「２０１０年１月１日」などの日付を用いるが、他の表現形式を用いてもよい。例えば、「２０１０年１月１日 １０時１５分２０秒」などの秒単位までの日時でもよいし、ミリ秒単位までの日時でもよい。あるいは、「２０１０年１月」などの月単位の表現形式でも、「２０１０年 １Ｑ」などの四半期単位の表現形式でも、「２０１０年」などの年単位の表現形式でも、「２０００年代」などの年単位より大まかな年代の表現形式でもよい。

アイテム情報テーブル１０１Ａのアイテム属性情報においては、１つのアイテムに同じ種類の属性項目が複数存在していてもよい。例えば、１つのアイテムに、「クリエイター１」「クリエイター２」「クリエイター３」「ジャンル１」「ジャンル２」の合計５つのカテゴリが設定されていてもよい。もちろん、ここで挙げたアイテム属性情報とカテゴリ属性情報は、あくまでも例示であり、上記に限定される訳ではない。例えば、アイテム属性情報に「サイズ」や「色」などの属性項目を用いてもよい。

なお、情報選択装置１０が、必要に応じてアイテム提供サーバ２０の後述するアイテム格納部２０２からアイテム情報およびカテゴリ情報を取得できるようにして、アイテム属性格納部１０１を省略することも可能である。

送受信部１０９は、ネットワーク４０（図２の構成の場合は、さらにネットワーク４２）を介して、アイテム提供サーバ２０または端末装置３０との間でデータを送受信する処理を行なう。

制御部１１０は、情報選択装置１０の全体の制御を行なうための種々の処理を行なう。例えば、後述するように、アイテム提供サーバ２０または端末装置３０から送信される利用リクエストを、送受信部１０９を介して受信し、利用リクエストに含まれるユーザ識別子とアイテム識別子とを対応させて、利用履歴情報として利用履歴格納部１０２に格納させる。

利用履歴格納部１０２は、ユーザのアイテム利用履歴情報を記録するアイテム利用履歴テーブル１０２Ａを格納している。アイテム利用は、ユーザからの利用リクエストに対してアイテム提供サーバ２０がアイテムを提供することにより実行される。ただし、アイテム利用は、購入を伴う提供に限られず、アイテムに関する情報の閲覧、視聴等を含めるようにしてもよい。

アイテム利用履歴テーブル１０２Ａは、利用履歴情報の格納形態として、種々の格納形態を採用することができる。例えば、図５（ａ）のアイテム利用履歴テーブル１０２Ａ−１に示すように、利用主体識別子とアイテム識別子とを関連付けて格納することができる。ここで、「利用主体識別子」は、端末装置３０を利用するユーザを一意に識別するユーザ識別子、または端末装置３０を一意に識別するための端末識別子であり、ユーザ識別子と端末識別子とを合わせた概念である。本実施形態では、ユーザ識別子を用いてユーザを識別するものとするが、端末装置３０として携帯電話を用いた場合等には、端末装置３０との接続時に取得可能な端末識別子を用いるようにしてもよい。

本例では、１つの利用リクエストが、テーブルの１行に対応している。テーブルの１行目と４行目がともに「ＵｓｅｒＩＤ−１」と「ＩｔｅｍＩＤ−３」の組み合わせであることから分かるように、利用主体識別子とアイテム識別子の組み合わせが同じであっても、利用リクエストごとにテーブル行のデータを追加して格納している。このため、アイテム識別子が示すアイテムごとの利用回数、およびアイテムごとの利用ユーザ数を他の処理部が容易にカウントすることができる。なお、１つの利用リクエストに複数のアイテム識別子が含まれている場合は、アイテム識別子の数だけのテーブル行を割り当てて格納する。

図５（ｂ）に示すアイテム利用履歴テーブル１０２Ａ−２は、利用主体識別子とアイテム識別子と利用時期情報とを関連付けて格納する格納形態例である。図５（ａ）に示したアイテム利用履歴テーブル１０２Ａ−１と同様に、１つの利用リクエストが、テーブルの１行に対応している。利用リクエストに利用時期情報が含まれている場合は、その情報を取り出して利用時期情報として格納する。利用リクエストに利用時期情報が含まれていない場合は、制御部１１０に内蔵等されている時計を用いて、情報選択装置１０が利用リクエストを受信した時期（時点）を利用時期情報として格納する。

本実施形態では、利用時期情報の表現形式として、「２０１０年１月１日 １０時１５分２０秒」などの秒単位までの日時を用いるが、それ以外にも、ミリ秒単位までの日時、日単位までの日付、月単位、年単位など種々の形式を用いることができる。なお、利用リクエストの中に、ユーザのアイテムに対する評価値（好き＝３、どちらでもない＝２、嫌い＝１、などの好き嫌いの度合いを示す数値）を含ませた上で、ユーザ識別子とアイテム識別子と利用時期情報と評価値とを関連付けてアイテム利用履歴テーブル１０２Ａ−２に格納するようにしてもよい。

なお、図５（ａ）および（ｂ）には示していないが、利用リクエストが発行された際にユーザが閲覧していたページ情報（閲覧ページ情報）を、利用主体識別子およびアイテム識別子と関連付けて格納してもよい。例えば、ユーザが推薦ページを閲覧して利用リクエストを発行したのか、あるいは新着アイテムを紹介するページを閲覧して利用リクエストを発行したのかを区別できる情報を格納する。このような閲覧ページ情報は、推薦情報を提供した効果を詳細に測定するために用いることができる。

図５（ｃ）に示すアイテム利用履歴テーブル１０２Ａ−３は、利用時期情報を省略し、ユーザ識別子とアイテム識別子と利用回数とを関連付けた格納形態例である。後述するように、関連度算出部１０４において、利用時期情報を用いない場合は、アイテム利用履歴テーブル１０２Ａ−３を用いることで利用履歴格納部１０２の記憶容量を削減することができる。また、利用リクエストの中に、ユーザのアイテムに対する評価値が含まれる場合は、ユーザ識別子とアイテム識別子と利用回数と最新の評価値とを関連付けてアイテム利用履歴テーブル１０２Ａ−３に格納するようにしてもよい。

なお、図５（ｃ）に示すアイテム利用履歴テーブル１０２Ａ−３では、利用時期情報を格納していないが、あるユーザがあるアイテムを利用した最新の利用時期情報を格納してもよい。すなわち、ユーザ識別子とアイテム識別子と利用回数と最新の利用時期情報とを関連付けて格納してもよい。あるいは、ユーザ識別子とアイテム識別子と利用回数と最初の（最も古い）利用時期情報とを関連付けて格納してもよい。

また、利用履歴格納部１０２には、アイテム利用履歴テーブル１０２Ａに加え、図５（ｄ）に示すようなカテゴリ利用履歴テーブル１０２Ｂを格納するようにしてもよい。カテゴリ利用履歴テーブル１０２Ｂは、ユーザ識別子とカテゴリ識別子と利用時期情報とを関連付けたテーブルである。この場合、制御部１１０は、ユーザからの利用リクエストに際し、アイテム属性格納部１０１のアイテム情報テーブル１０１Ａを参照して、利用リクエストのアイテム識別子に対応するカテゴリ識別子を特定し、カテゴリ利用履歴テーブル１０２Ｂに格納する。後述するように、カテゴリ推薦形式に対応する関連集合を作成する際（図１４のステップＳ４００）に、カテゴリ利用履歴テーブル１０２Ｂを格納しておくと、効率よく処理が行なえる場合がある。

価格情報格納部１０３は、アイテムの価格情報を記録したアイテム価格情報テーブル１０３Ａと、カテゴリの価格情報を記録したカテゴリ価格情報テーブル１０３Ｂとを格納している。図６（ａ）は、アイテム価格情報テーブル１０３Ａの一例を示している。本図に示すように、アイテム価格情報テーブル１０３Ａは、アイテム識別子と、価格情報とを対応付けて格納する。アイテムの価格情報は、そのアイテムの価格である。ただし、必ずしも円、ドル、ユーロといった実際の通貨に基づく価格である必要はない。例えば、本実施形態に係るアイテム提供サービスや、提携している関連サービスで使用できる独自のポイントの値であってもよい。なお、本図の例から分かるように、価格情報（価格）が「０円」である無料のアイテムが存在してもよい。また本図に示すように、価格の安い順にアイテムを格納してもよいし、高い順に格納してもよい。もちろんアイテム識別子の順番に格納してもよい。

図６（ｂ）は、カテゴリ価格情報テーブル１０３Ｂの一例を示している。本図に示すように、カテゴリ価格情報テーブル１０３Ｂは、カテゴリ識別子と、価格情報とを対応付けて格納する。カテゴリの価格情報は、そのカテゴリに属する各アイテムの価格の合計値または代表値とすることができる。価格の代表値は、例えば、そのカテゴリに属するアイテムの価格の平均値、中央値、最頻値、四分位値、最大値、最小値などである。

図６（ｂ）に示したカテゴリ価格情報テーブル１０３Ｂでは、そのカテゴリに属するアイテムの価格の合計値をカテゴリの価格情報としている。なお本図から分かるように、価格が「０円」であるカテゴリ（そのカテゴリに属するアイテムがすべて無料）が存在してもよい。またカテゴリ識別子を格納する場合も、価格の安い順または高い順にアイテムを格納してもよい。

推薦情報格納部１０８は、情報選択部１０７で選択された推薦情報を記録する推薦情報テーブルを格納する。推薦情報は、利用主体識別子と、それに関連する識別子（以下「関連識別子」と称する）とを対応させた情報である。ここで、関連識別子としては、アイテム識別子またはカテゴリ識別子を用いることができる。すなわち、推薦情報格納部１０８は、図７（ａ）、図７（ｂ）に示すような２種類の推薦情報テーブルを格納する。

図７（ａ）は、関連識別子をアイテム識別子（関連アイテム識別子）とし、利用主体識別子と関連アイテム識別子と推薦順位とを対応させて格納したアイテム推薦情報テーブル１０８Ａの例を示している。関連アイテム識別子は、利用主体識別子と関連するアイテムの識別子である。以下では、利用主体識別子に対して関連アイテム識別子に対応するアイテムを推薦する形式を「アイテム推薦形式」と称する。

アイテム推薦情報テーブル１０８Ａでは、１つの利用主体識別子に、１つ以上の関連アイテム識別子が対応付けられている。「ＵｓｅｒＩＤ−１」に対応する関連アイテムはＮ１個格納されており、「ＵｓｅｒＩＤ−２」に対応する関連アイテムはＮ２個格納されている。ここで、Ｎ１とＮ２は同じであっても、異なっていてもよい。すなわち、利用主体識別子ごとの関連識別子の個数がすべて同じであってもよいし、利用主体識別子ごとに関連識別子の個数が異なっていてもよい。

推薦順位は、利用主体識別子ごとに関連アイテムを推薦する順位を示しており、ここでは番号が小さいほど優先順位が高く、優先的にユーザに提示されるものとする。本図では、各々の利用主体識別子に対して、推薦順位の高い順に関連識別子（関連アイテム識別子）を格納しているが、推薦順位と対応付けて関連識別子を格納する場合は、適当な順序で格納してもよい。

なお、推薦順位の代わりに、数値が大きいほど優先順位が高く、優先的にユーザに提示されるような推薦度を格納するようにしてもよい。また、各推薦情報テーブルにおいて推薦順位を省略してもよい。この場合は、各推薦情報テーブルにおいて、利用主体識別子ごとに推薦順位の高い順、または推薦順位の低い順に関連識別子を格納すればよい。すなわち、ある利用主体識別子に対する関連識別子の推薦順位の情報を、関連識別子の格納順序（格納位置）に持たせてもよい。あるいは、記録された関連識別子をすべて同じ順位として扱ったり、各推薦情報テーブルを読み出す際に、ランダムに推薦順位を付与してもよい。

図７（ｂ）は、関連識別子をカテゴリ識別子（関連カテゴリ識別子）とし、利用主体識別子と関連カテゴリ識別子と推薦順位とを対応させて格納したカテゴリ推薦情報テーブル１０８Ｂの例を示している。関連カテゴリ識別子は、利用主体識別子と関連するカテゴリの識別子である。以下では、利用主体識別子に対して関連カテゴリ識別子に対応するカテゴリを推薦する形式を「カテゴリ推薦形式」と称する。カテゴリ推薦形式は、例えば、ユーザにクリエイター（アイテムの作成者）やジャンルに関する推薦情報を提供する場合に用いることができる。

推薦順位は、アイテム推薦情報テーブル１０８Ａと同様な意味であり、同様に推薦順位の格納を省略することも可能である。

以下では、アイテム推薦情報テーブル１０８Ａを用いた情報提供（アイテム推薦形式）とカテゴリ推薦情報テーブル１０８Ｂを用いた情報提供（カテゴリ推薦形式）とを両方実施する場合を例にして説明するが、これらのうちの一方のみを実施するようにしてもよい。その場合、必要な種類の推薦情報テーブルのみ格納すればよい。

関連度算出部１０４は、利用履歴格納部１０２に格納されたデータを用いて、上述した「アイテム推薦形式」「カテゴリ推薦形式」に対応する２種類の関連度を算出して関連集合を作成し、関連集合格納部１０５に格納させる。

関連集合格納部１０５は、利用主体識別子と、関連識別子と、関連度とを対応させた関連度テーブル１０５Ａ／１０５Ｂを格納する。関連度とは、利用主体識別子と関連識別子との関連性の高さを示す数値であり、利用主体識別子に係るユーザが関連識別子に係るアイテムまたはカテゴリを好む程度を予測した数値である。

図８は、関連度テーブル１０５Ａ／１０５Ｂの一例を示している。関連度テーブル１０５Ａ、１０５Ｂに格納されている、ある１つの利用主体識別子に対応する関連識別子の集合をその利用主体識別子の関連集合と称する。

上述したように、関連識別子は、アイテム識別子またはカテゴリ識別子であり、それぞれに応じて、２種類の格納形式があるが、本図では簡略化して示している。以下では、利用主体識別子と関連アイテム識別子との関連度を関連度テーブル１０５Ａに記録し、利用主体識別子と関連カテゴリ識別子との関連度を関連度テーブル１０５Ｂに記録するものとする。

本図の例では、利用主体識別子「ＵｓｅｒＩＤ−１」に対応する関連識別子をＬ１個、利用主体識別子「ＵｓｅｒＩＤ−２」に対応する関連識別子をＬ２個格納している。ここで、Ｌ１とＬ２は同じであっても、異なっていてもよい。すなわち、すべての利用主体識別子に対して同じ数の関連識別子を格納してもよいし、利用主体識別子ごとに異なる数の関連識別子を格納してもよい。また、関連度算出部１０４で関連度が算出された利用主体識別子と関連識別子の組み合わせをすべて格納してもよいし、利用主体識別子との関連度の高い関連識別子のみを関連集合として格納してもよい。一部のみを格納することにより、関連集合格納部１０５の記憶容量を削減することができる。また、本図に示すように、利用主体識別子ごとに、関連度の大きい順に関連識別子を格納してもよい。

１つの関連集合の要素数（関連識別子の数）は、基本的には複数であるが、要素数が「１」の関連集合が存在していてもよい。ただし、少なくとも１つ以上の関連集合の要素数は「２」以上である必要がある。なお、情報選択装置１０以外の他の装置で算出された関連集合および関連度を関連度テーブル１０５Ａ、１０５Ｂに記録してもよく、その場合は関連度算出部１０４を省略することができる。

価格影響度算出部１０６は、価格情報格納部１０３および関連集合格納部１０５を参照しながら、関連集合の各々の関連識別子について、その価格情報（価格）が推薦結果に与える影響度である価格影響度を算出する。

情報選択部１０７は、価格影響度算出部１０６で算出された価格影響度と、関連集合格納部１０５の関連度テーブル１０５Ａ、１０５Ｂに格納された関連度とを用いて選択指標を算出し、その選択指標に基づいて、関連集合格納部１０５の関連度テーブル１０５Ａ、１０５Ｂに格納された利用主体識別子ごとに関連識別子を選択し、その選択された関連識別子と利用主体識別子との組み合わせを推薦情報として、推薦情報格納部１０８の各推薦情報テーブル１０８Ａ、１０８Ｂに格納する。
＜アイテム提供サーバ＞

アイテム提供サーバ２０は、端末装置３０からの要求に応じて、アイテムおよびアイテムに関する情報を提供する装置である。図９は、アイテム提供サーバ２０の構成を示すブロック図である。本図に示すように、アイテム提供サーバ２０は、ユーザ管理部２０１と、アイテム格納部２０２と、データ格納部２０３と、送受信部２０４と、制御部２０５とを備えて構成されている。

アイテム提供サーバ２０は、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＨＤＤ（ハードディスクドライブ）、ネットワークインタフェース等を備える一般的なコンピュータを用いて構成することができる。すなわち、一般的なコンピュータは、以下で説明するような処理を行なうためのプログラムを実行することにより、アイテム提供サーバ２０として機能することができるようになる。

送受信部２０４は、ネットワーク４０（図２の構成の場合は、さらにネットワーク４２）を介して情報選択装置１０および端末装置３０との間でデータを送受信する処理を行なう。制御部２０５は、アイテム提供サーバ２０の全体の制御を行なう。

ユーザ管理部２０１は、端末装置３０を利用するユーザを一意に識別するユーザ識別子、または端末装置３０を一意に識別するための端末識別子である利用主体識別子を少なくとも格納している。アイテム提供サーバ２０は、例えば、ユーザにアイテム利用を開始させるに先立ち、入会処理等を行なって、入会処理の終了した利用主体識別子をユーザ管理部２０１に格納する。また、必要に応じて、利用主体識別子に対応させて、ログイン名、パスワード、氏名、生年月日、連絡先、決済方法等のユーザ属性情報をユーザ管理部２０１に格納するようにしてもよい。

アイテム格納部２０２は、アイテム提供サーバ２０が提供するアイテムに関する情報を格納する。アイテム格納部２０２は、情報選択装置１０のアイテム属性格納部１０１と同様な情報を格納する。ただし、アイテムが有体の物品ではなく、デジタルコンテンツ等であって、ネットワーク４０を介して端末装置３０に配信可能である場合には、アイテム属性格納部１０１のデータに加えて、アイテム識別子と、アイテム本体（デジタルコンテンツ等のデータ）とを対応させて格納する。

なお、制御部２０５は、アイテム格納部２０２が更新されるごと、または所定のスケジュールに基づいて、アイテム格納部２０２のデータを、送受信部２０４を介して情報選択装置１０に送信し、アイテム属性格納部１０１に格納させるようにしてもよい。また逆に制御部２０５は、情報選択装置１０から送信されるアイテム属性格納部１０１のデータを受信し、アイテム格納部２０２に格納させるようにしてもよい。あるいは、情報選択装置１０からアイテム提供サーバ２０にアイテム属性情報を要求するメッセージを送信するようにし、制御部２０５が、それに応じたデータをアイテム格納部２０２から読み出して、送受信部２０４を介して情報選択装置１０に送信するようにしてもよい。

データ格納部２０３は、様々なデータを格納することができる。例えば、情報選択装置１０の推薦情報格納部１０８に格納されたデータをコピーしてデータ格納部２０３に格納することができる。この場合、端末装置３０は、アイテム提供サーバ２０から推薦情報を受信することができるので、情報選択装置１０の処理負荷を低減することができる。また、情報選択装置１０の利用履歴格納部１０２と同様なデータを格納してもよい。この場合、情報選択装置１０からデータ格納部２０３を参照できるようにして、情報選択装置１０の利用履歴格納部１０２を省略することも可能である。
＜端末装置＞

端末装置３０は、ユーザが使用する装置である。図１０は、端末装置３０の構成を示すブロック図である。本図に示すように、端末装置３０は、制御部３０１と、送受信部３０２と、ブラウザ部３０３と、アプリケーション部３０４とを備えて構成されている。端末装置３０は、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＨＤＤ（ハードディスクドライブ）、ネットワークインタフェース等を備える一般的なコンピュータ等を用いることができる。すなわち、一般的なコンピュータは、以下で説明するような処理を行なうためのプログラムを実行することにより、端末装置３０として機能することができるようになる。また、端末装置３０は、Ｗｅｂブラウザ機能等を備えた携帯電話や、携帯端末装置等を用いて構成することもできる。

端末装置３０には、Ｗｅｂブラウザに代表されるＷｅｂページにアクセスしてその情報を表示するプログラムがインストールされており、ブラウザ部３０３を構成している。また、種々のアプリケーションプログラムを実行することにより、アプリケーション部３０４が構成される。

端末装置３０としてコンピュータを用いた場合には、ディスプレイ等の表示装置３２０や、キーボード、マウス、トラックボール、リモコン等のユーザからの操作指示を受け付けるための入力装置３３０が接続される。端末装置３０として携帯電話や、携帯端末装置等を用いた場合は、表示装置、入力装置は内蔵されているが、以下では、便宜的に表示装置３２０、入力装置３３０が接続されているものとして説明する。
＜システム動作＞
＜システム全体の動作＞

図１１のフローチャートを参照して、ネットワークシステム全体の基本的な動作を説明する。この基本的な動作は、多少の変更はあるがすべての実施例で共通である。まず、ステップＳ１００において、端末装置３０は、ブラウザ部３０３を用いて、アイテム提供サーバ２０のＵＲＬ（Uniform
Resource Locator）にアクセスする。具体的には、アイテム提供サーバ２０の提供する所定のＷｅｂページへのリクエスト（利用開始リクエスト）をアイテム提供サーバ２０に送信する。

端末装置３０としてパーソナルコンピュータ等を用いる場合は、端末装置３０を利用するユーザに、事前に設定させたログイン名（ユーザＩＤ）とパスワードとを入力させ、これらを利用開始リクエストに含めて送信する。あるいは、Ｃｏｏｋｉｅ等の技術を用いて、端末装置３０を利用するユーザを識別可能なデータを利用開始リクエストに含めて送信すれば、ログイン名とパスワードの送信を省略できる。ログイン名とパスワードを利用開始リクエストに含めて送信する場合は、ステップＳ１００の前に、アイテム提供サーバ２０から端末装置３０に、ログイン名とパスワードの入力を受け付けるためのＨＴＭＬ（Hyper
Text Markup Language）データ等を送信しておけばよい。

また、端末装置３０として携帯電話等を用いる場合は、端末固有の端末識別子を利用開始リクエストに含めて送信すればよい。この場合は、ログイン名とパスワードの送信を省略することができる。

ステップＳ１１０において、アイテム提供サーバ２０の制御部２０５は、送受信部２０４を介して端末装置３０からの利用開始リクエストを受信し、ユーザ管理部２０１を参照しながら、登録済のユーザか否かを判定する。具体的には、利用開始リクエストにログイン名とパスワードが含まれている場合は、それらをユーザ管理部２０１に格納されているログインおよびパスワードと照合する。また、利用開始リクエストに端末識別子が含まれる場合は、それがユーザ管理部２０１に格納されている利用主体識別子と一致するか判定する。登録済のユーザである場合（Ｙｅｓ）は、ステップＳ１３０に進み、そうでない場合（Ｎｏ）は、ステップＳ１２０に進む。

ステップＳ１２０において、アイテム提供サーバ２０の制御部２０５は、送受信部２０４を介して、端末装置３０に入会処理を行なうためのＷｅｂページ（ＨＴＭＬ）を送信する。本図には示していないが、端末装置３０を利用するユーザは、入力装置３３０を利用して入会処理のＷｅｂページに必要な情報を入力し、アイテム提供サーバに送信する等の操作を行い、アイテム提供サーバ２０は、その情報をユーザ管理部２０１に格納する等の入会処理が行われる。端末装置３０は、入会処理完了後に、改めて利用開始リクエストを送信することができる。

ステップＳ１３０において、アイテム提供サーバ２０の制御部２０５は、アイテム格納部２０２を参照しながら、利用開始リクエストに対応するＷｅｂページの応答データであり、アイテムまたは／およびカテゴリを紹介する情報を含む応答データを作成し、送受信部２０４を介して端末装置３０に送信する。応答データは、ＨＴＭＬデータ、画像データ、映像データ、音声データなどで構成されており、複数回に分けて端末装置３０に送信される場合がある。また、応答データには、あるアイテム（またはカテゴリ）に関連する関連アイテム（または関連カテゴリ）をユーザに表示するための情報と、ユーザにアイテムを利用させるための情報とが含まれている。またＣｏｏｋｉｅ等の技術を用いて、応答データにユーザや端末装置３０を識別するための情報を含めてもよい。

ステップＳ１４０において、端末装置３０は、アイテム提供サーバ２０から応答データを受信し、表示装置３２０にその情報を表示する。表示画面の例を図１２に示す。図１２は、応答データにアイテムを紹介する情報が含まれる場合の表示例である。本図の例は、アイテム提供サーバ２０が最近提供を開始した「新着アイテム」を紹介する表示画面である。ただし、本図に示すようなアイテムを紹介する情報は、種々のタイミングで端末装置３０に送信することができる。なお、情報選択装置１の表示制御情報作成部（図示せず）が、このような応答データを作成し、端末装置３０に送信するようにしてもよい。

本図において「アイテムＡＢＣ」は１番目のアイテムのタイトルであり、「ＳＦ」は１番目のアイテムのカテゴリ名であり、「このアイテムは、２００１年に制作された映画で…」という表示は１番目のアイテムの説明情報である。また、各々のアイテムごとに、そのアイテムを利用するためのボタンやリンク等（利用リンク）が表示される。２番目以降のアイテムについても同様な表示がされる。

また図１２に示すように、「あなたへお薦めのアイテム」等のボタン、リンク等を表示してもよい。これは、端末装置３０を利用するユーザに対して、そのユーザとの関連度の高い（そのユーザの嗜好や興味に合う可能性の高い）アイテム情報を表示するためのボタンやリンク等（関連アイテムリンク）である。また、「あなたへお薦めのカテゴリ」等のボタン、リンク等を表示してもよい。これは、そのユーザとの関連度の高いカテゴリ情報を表示するためのボタンやリンク等（関連カテゴリリンク）である。以下では、関連アイテムリンクと関連カテゴリリンクを合わせて、関連リンクと称する。

図１２の関連アイテムリンクは、上述したアイテム推薦形式の推薦情報を表示させるためのリンクである。図１２の関連カテゴリリンクは、カテゴリ推薦形式の推薦情報を表示させるためのリンクである。ユーザは、入力装置３３０を使用したクリック等の操作により、関連リンクまたは利用リンクを選択することができる。なお表示画面には表示されないが、応答データには、各々のアイテムのアイテム識別子、および端末装置３０を利用するユーザに係る利用主体識別子が含まれている。なお、本図には示していないが、新着アイテム等を紹介する表示画面において、アイテムごとにその価格情報を表示してもよい。

図１１のフローチャートの説明に戻って、ステップＳ１５０において、端末装置３０は、関連リンク（関連アイテムリンクまたは関連カテゴリリンク）がユーザから入力装置３３０を介して選択されたか否かを判定する。関連リンクが指定された場合（Ｙｅｓ）は、ステップＳ１６０に進み、指定されていない場合（Ｎｏ）は、ステップＳ１９０に進む。

ステップＳ１６０において、端末装置３０は、関連リンクに対応するＵＲＬにリクエスト（推薦リクエスト）を送信する。本実施形態では、関連リンクが情報選択装置１０の所定のＵＲＬに対応する場合を説明するが、関連リンクをアイテム提供サーバ２０の所定のＵＲＬに対応させてもよい。推薦リクエストには、利用主体識別子（端末装置３０を利用するユーザのユーザ識別子または端末装置３０の端末識別子）と、関連アイテムリンクであるか関連カテゴリリンクであるかを示すリンク種別情報とが含まれている。以下では、この推薦リクエストに含まれる利用主体識別子を「リクエスト利用主体識別子」（情報選択に係る利用主体識別子）と称する。

ステップＳ１７０において、情報選択装置１０の制御部１１０は、送受信部１０９を介して、推薦リクエストを受信し、それに含まれるリクエスト利用主体識別子に対応する表示用推薦データを作成して端末装置３０に送信する。このとき、制御部１１０は、以下に説明する「アイテム推薦形式」と「カテゴリ推薦形式」とに対応する２種類の処理を行なう。
＜アイテム推薦形式＞

図７（ａ）に示した推薦情報格納部１０８のアイテム推薦情報テーブル１０８Ａを参照しながら、リクエスト利用主体識別子に一致する利用主体識別子を特定し、それに対応する関連アイテム識別子と推薦順位とを読み出す。さらに、その関連アイテム識別子に対応するアイテム属性情報をアイテム属性格納部１０１のアイテム情報テーブル１０１Ａから読み出す。そして、関連アイテム識別子と、推薦順位と、アイテム属性情報とを対応させた表示用推薦データを作成する。

例えば、図７（ａ）に示した例において、リクエスト利用主体識別子が「ＵｓｅｒＩＤ−１」である場合は、それと同じ利用主体識別子に対応した関連アイテム識別子である「ＩｔｅｍＩＤ−１０００」「ＩｔｅｍＩＤ−１０２０」…「ＩｔｅｍＩＤ−１０３５」と、その推薦順位「１」「２」…「Ｎ１」を読み出す。ただし、特定した利用主体識別子に対応する関連アイテム識別子をすべて読み出してもよいし、推薦順位の高い順に所定個数読み出してもよい。また推薦リクエストの中に、読み出す推薦情報の個数が含まれている場合は、推薦順位の高い順にその個数だけを読み出す。

このとき、利用履歴格納部１０２のアイテム利用履歴テーブル１０２Ａを参照しながら、リクエスト利用主体識別子に係るユーザが過去に利用したアイテム識別子（利用済みアイテム識別子）を特定し、利用済みアイテム識別子（利用済みアイテム）を推薦情報に含めない処理を行なってもよい。このような処理を行なうことで、ユーザが１回しか同じアイテムを購入しない性質を持つようなアイテム提供サービスにおいて、精度の高い推薦が可能になる。例えば、１度購入したデジタルコンテンツは、端末装置３０で繰り返し利用（再生）できる、といったサービスに適している。

また、過去の利用回数が所定数以上のアイテムを推薦情報に含めない処理や、最近３ヶ月以内等の所定期間内に利用したアイテムを推薦情報に含めない処理を行なってもよい。このような処理を行なうことで、ユーザが利用しない可能性の高いアイテムが推薦情報に入り難くなるので、推薦情報に対するユーザの信頼感や興味の度合いを高めることができる。

そして制御部１１０は、アイテム属性格納部１０１を参照しながら、読み出した関連アイテム識別子に対応する「タイトル」「説明情報」などのアイテム属性情報と、「カテゴリ名」などのカテゴリ属性情報とを読み出し、関連アイテム識別子と２つの属性情報と推薦順位とを合わせて表示用推薦データを作成する。また、価格情報格納部１０３を参照しながら、読み出した関連アイテム識別子に対応する価格情報を読み出し、表示用推薦データに含めてもよい。
＜カテゴリ推薦形式＞

図７（ｂ）に示した推薦情報格納部１０８のカテゴリ推薦情報テーブル１０８Ｂを参照しながら、リクエスト利用主体識別子に一致する利用主体識別子を特定し、それに対応する関連カテゴリ識別子と推薦順位とを読み出す。ここで、特定した利用主体識別子に対応する関連カテゴリ識別子をすべて読み出してもよいし、推薦順位の高い順に所定個数読み出してもよい。さらに、その関連カテゴリ識別子に対応するカテゴリ属性情報（カテゴリ名およびカテゴリ説明情報）をアイテム属性格納部１０１から読み出す。そして、関連カテゴリ識別子と、推薦順位と、カテゴリ属性情報とを対応させた表示用推薦データを作成する。また、価格情報格納部１０３を参照しながら、関連カテゴリ識別子に対応する価格情報を読み出し、表示用推薦データに含めてもよい。

このとき、ユーザが過去に利用したカテゴリを除外して表示用推薦データを作成してもよい。具体的には、利用履歴格納部１０２のアイテム利用履歴テーブル１０２Ａとアイテム情報テーブル１０１Ａとを参照しながら、リクエスト利用主体識別子に係るユーザが、過去に利用したアイテムについてのカテゴリ識別子（利用済みカテゴリ識別子）を特定する。なお、カテゴリ利用履歴テーブル１０２Ｂを用いている場合は、カテゴリ利用履歴テーブル１０２Ｂを参照すればよい。

そして、カテゴリ推薦情報テーブル１０８Ｂから関連カテゴリ識別子を読み出す際に、利用済みカテゴリ識別子を除外する処理を行なう。このような処理を行なうことで、ユーザが１回しか同じカテゴリのアイテムを購入しない性質を持つようなアイテム提供サービスにおいて、精度の高い推薦が可能になる。また、過去の利用回数が所定数以上のカテゴリを推薦情報に含めない処理や、最近３ヶ月以内等の所定期間内に利用したカテゴリを推薦情報に含めない処理を行なってもよい。このような処理を行なうことで、ユーザが利用しない可能性の高いカテゴリが推薦情報に入り難くなるので、推薦情報に対するユーザの信頼感や興味の度合いを高めることができる。

なお、アイテム提供サーバ２０のユーザ管理部２０１に、ユーザの氏名やログイン名などのユーザ属性情報が格納されている場合には、上述した「アイテム推薦形式」、「カテゴリ推薦形式」の表示用推薦データを作成する際にこれらを読み出して、表示用推薦データの中に、リクエスト利用主体識別子と、リクエスト利用主体識別子に対応するユーザ属性情報とを含めてもよい。

また、推薦リクエストの種別に対応する推薦情報テーブルにおいて、推薦順位が格納されておらず、関連識別子の格納順序が推薦順位の情報を持っている場合は、その格納順序に従って、表示用推薦データにおける関連識別子の順序を決めればよい。例えば、格納順序が１番目の関連アイテム識別子を表示用推薦データの１番目にし、格納順序が２番目の関連アイテム識別子を表示用推薦データの２番目にすればよい。また、表示用推薦データを作成する際に、ランダムな推薦順位を生成して付与したり、表示用推薦データにおける関連識別子の順序をランダムに決定してもよい。

図１１のフローチャートの説明に戻って、ステップＳ１８０において、端末装置３０は、ステップＳ１７０で情報選択装置１０から送信された表示用推薦データを受信し、例えば、図１３に示す形式で表示装置１２０に推薦リストとして表示する。図１３（ａ）は、「アイテム推薦形式」に対応する処理が行われた場合に、推薦リクエストを発行したユーザとの関連度が高いアイテムを「○○○さんへのおすすめアイテム」として表示する画面の一例である。

「○○○」には、リクエスト利用主体識別子に対応するユーザの氏名やログイン名が表示される。このような表示を行なうことにより、他のユーザに対する推薦情報と共通のものではなく、そのユーザ専用に作成された推薦情報であることをユーザに明確に伝えることができるので、推薦情報に対するユーザの信頼感や興味の度合いを高めることができる。なお、氏名やログイン名を表示しなくても、「あなただけにお知らせする、とっておきアイテムです」など、そのユーザ専用に作成された推薦情報であることが分かる表示を行なうことで、同様の効果を得ることができる。

アイテムの表示順序は、推薦順位に従って決められており、推薦順位が上位のアイテムほど、ユーザの目に留まりやすい位置に表示される。例えば、本図に示すように上下方向に各々のアイテムの情報を配置する場合は、推薦順位が上位のアイテムの表示画面の上側に表示するとよい。また、左右方向に各々のアイテムの情報を配置する場合は、表示画面の左側に表示するとよい。「アイテムＯＰＱ」は１番目のアイテム（推薦順位が「１」のアイテム）のタイトルであり、「サスペンス」は１番目のアイテムのカテゴリ名であり、「このアイテムは、目が離せない…」という表示は、１番目のアイテムの説明情報である。図１２に示した表示例と同様に、各々のアイテムに対して、利用リンクに対応付けられた「アイテム利用」ボタンが表示される。２番目以降のアイテムについても同様な表示がされる。なお、本図には示していないが、表示用推薦データに価格情報が含まれている場合は、アイテムごとにその価格情報を表示してもよい。

図１３（ｂ）は、表示用推薦データ作成・送信処理（ステップＳ１７０）で「カテゴリ推薦形式」に対応する処理が行われた場合に、推薦リクエストを発行したユーザとの関連度が高いカテゴリを「○○○さんへのおすすめカテゴリ」として表示する画面の一例である。

カテゴリの表示順序は、推薦順位に従って決められている。「カテゴリＲＳＴ」は１番目のカテゴリ（推薦順位が「１」のカテゴリ）のカテゴリ名であり、「このカテゴリは、最近非常に注目され…」という表示は、１番目のカテゴリの説明情報である。各々のカテゴリに対して、「アイテム一覧表示」ボタンが表示される。ユーザが「アイテム一覧表示」ボタンを押すと、この画面あるいは別の画面に、そのカテゴリに属するアイテムの一覧と、それを利用するための利用ボタン（利用リンク）が表示される。なお、図１３（ｂ）に示す画面に、各々のカテゴリに属する代表的なアイテムのタイトル等をあらかじめ表示してもよい。２番目以降のアイテムについても同様な表示がされる。なお、本図には示していないが、表示用推薦データに価格情報が含まれている場合は、カテゴリごとにその価格情報（カテゴリに属するアイテムの価格の代表値など）を表示してもよい。

図１１のフローチャートの説明に戻って、ステップＳ１９０において、端末装置３０は、利用リンクがユーザから入力装置３３０を利用して選択されたか否かを判定する。この利用リンクは、代表的には、アイテムの購入要求とすることができるが、アイテムの再生、アイテムのプレビュー、アイテムの詳細情報の表示、アイテムに対する評価情報（評価値）の登録などの種々の要求を含めることができる。利用リンクが選択された場合（Ｙｅｓ）は、ステップＳ２００に進み、そうでない場合（Ｎｏ）はステップＳ２５０に進む。

ステップＳ２００において、端末装置３０は、利用リンクに対応するＵＲＬにリクエスト（利用リクエスト）を送信する。本実施形態では、利用リンクがアイテム提供サーバ２０の所定のＵＲＬに対応する場合を説明する。なお端末装置３０は、利用リクエストをアイテム提供サーバ２０に加えて、情報選択装置１０に直接送信してもよい。

各々の利用リンクには、選択対象となるアイテムのアイテム識別子が付与されており、利用リクエストには、ユーザが選択したアイテムのアイテム識別子と、そのユーザまたは端末装置３０を識別する利用主体識別子とが含まれている。なお、ユーザが一度に複数のアイテムを利用する場合は、１つの利用リクエストに複数のアイテムのアイテム識別子を含めてもよいし、複数の利用リクエストを送信してもよい。

ステップＳ２１０において、アイテム提供サーバ２０の送受信部２０４は、端末装置３０から受信した利用リクエストを情報選択装置１０に送信し中継する。このとき、アイテム提供サーバ２０の制御部２０５が、利用リクエストからアイテム識別子や利用主体識別子などの情報を取り出し、利用情報として、データ格納部２０３に格納させるようにしてもよい。

ステップＳ２２０において、情報選択装置１０の制御部１１０が、送受信部１０９を介して、利用リクエストを受信し、利用履歴情報として利用履歴格納部１０２に格納させる。そして、制御部１１０は、送受信部１０９を介して、利用履歴情報の格納を終了したことを示すメッセージをアイテム提供サーバ２０に送信する。

ステップＳ２３０において、アイテム提供サーバ２０の制御部２０５が、送受信部２０４を介して情報選択装置１０からの格納終了メッセージを受信した後、端末装置３０にアイテムを提供する処理を行なう。例えば、提供対象のアイテムがデジタルコンテンツである場合には、アイテム格納部２０２から、利用リクエストに含まれるアイテム識別子に対応するアイテム本体を読み出して、送受信部２０４を介して端末装置３０に送信する。また、アイテムが物品である場合には、配送事業者のシステムに配送依頼の情報を送る配送処理などを行なう。このとき必要に応じて、課金処理などを行なう。また、アイテムの詳細情報が要求された場合には、アイテム格納部２０２から「説明情報」などを読み出して、端末装置３０に送信する。

ステップＳ２４０において、端末装置３０は、アイテム提供サーバ２０から提供されたアイテムの利用に係る処理を行なう。例えば、アイテムがデジタルコンテンツである場合には、アイテムの再生、表示などを行なう。また、アイテムが物品である場合には、配送処理を受付した旨のメッセージ等を画面に表示する。

ステップＳ２５０において、端末装置３０は、ユーザがブラウザを終了する等の操作終了指示があるか否かを判定する。操作終了指示がある場合（Ｙｅｓ）は、端末装置３０の処理を終了し、操作終了指示がない場合（Ｎｏ）は、ステップＳ１５０に戻って処理を継続する。

以上がシステム全体の動作の説明である。なお、本実施形態においては、ステップＳ１６０で、端末装置３０から情報選択装置１０に推薦リクエストを送信しているが、これ以外の方法を用いてもよい。例えば、端末装置３０からアイテム提供サーバ２０に推薦リクエストを送信し、アイテム提供サーバ２０が情報選択装置１０に推薦リクエストを中継してもよい。また、適当なタイミングで、情報選択装置１０の制御部１１０が、送受信部１０９を介して、推薦情報格納部１０８に格納されたデータをアイテム提供サーバ２０に送信すると共に、アイテム提供サーバ２０の制御部２０５が、送受信部２０４を介して、そのデータを受信し、データ格納部２０３に格納させておいてもよい。そして、ステップＳ１６０において、端末装置３０からアイテム提供サーバ２０に推薦リクエストを送信し、ステップＳ１７０に相当する処理として、アイテム提供サーバ２０の制御部２０５が、データ格納部２０３から推薦データを読み出し、表示用推薦データを作成して、端末装置３０に送信するようにしてもよい。この場合は、表示用推薦データ作成とその送信に伴う情報選択装置１０の処理負荷を減らすことができる。

また、本実施形態においては、ステップＳ２１０で、アイテム提供サーバ２０が端末装置３０からの利用リクエストを情報選択装置１０に中継しているが、これ以外の方法を用いてもよい。例えば、ステップＳ２００の利用リクエストの送信と同時、あるいは適当なタイミングで、端末装置３０から情報選択装置１０に直接、利用リクエストを送信してもよい。

また、ステップＳ２２０において、情報選択装置１０は、利用履歴情報の格納に加えて、利用リクエストに含まれる利用主体識別子に対応する表示用推薦データをステップＳ１７０と同様な方法で作成し、表示用推薦データをアイテム提供サーバ２０に送信してもよい。そして、ステップＳ２３０において、アイテム提供サーバ２０が、アイテム提供処理に加えて、表示用推薦データを端末装置３０に送信してもよい。すなわちこの場合、端末装置３０は、利用リクエストを送信するごとに、利用リクエストに含まれる利用主体識別子に対応する推薦情報を受信することができる。

また、携帯電話等の端末識別子を利用することができ、特別なユーザ登録処理が不要なアイテム提供サービスにおいて、ステップＳ２００で送信される利用リクエストに、利用主体識別子を含めることができる場合であれば、ステップＳ１１０の登録済ユーザ確認処理と、ステップＳ１２０の入会処理に必要なデータの送信とを省略することも可能である。
＜情報選択装置の動作＞
＜推薦情報作成動作＞

第１実施例における情報選択装置１０の処理動作について説明する。まず、情報選択装置１０が推薦情報を作成する動作について図１４のフローチャートを参照して説明する。

情報選択装置１０の制御部１１０は、所定のタイミングで情報選択装置１０の各処理部に指示を出し、推薦情報を作成する処理を開始する。推薦情報作成のタイミングとして、次の３種類を用いることができる。

推薦情報作成の第１のタイミングは、所定の日時または所定の時間間隔である。例えば、「毎日午前６時と午後６時」「毎週月曜の午前１０時３０分」「１２時間ごと」「２４時間ごと」などである。このとき、「平日は午前６時、土日は午前６時と午後６時」「平日は３時間ごと、土曜日は６時間ごと、日曜日は１２時間ごと」などのように時間間隔が変動してもよい。また、夏は時間間隔を短くして、冬は時間間隔を長くするなど、季節に応じて時間間隔を変えてもよい。この第１のタイミングを用いると、他のタイミングを用いた場合より情報選択装置１０の処理負荷を減らすことができる。特に、推薦リクエスト数が少ない時間帯に推薦情報を作成するように設定すれば、情報選択装置１０の処理負荷の低減に効果的である。

推薦情報作成の第２のタイミングは、端末装置３０の推薦リクエスト送信処理（図１１ステップＳ１６０）による端末装置３０からの推薦リクエストを所定回数受信するごとである。この場合は、基本的には所定回数を１として、推薦リクエストを受信するごとに推薦情報を作成するのがよい。以下の説明では、所定回数を１とするが、所定回数を２以上にすることも可能である。所定回数を１とする場合は、まず推薦リクエストに含まれる利用主体識別子（リクエスト利用主体識別子）に対する推薦情報を作成し、その後に表示用推薦データ作成・送信処理（ステップＳ１７０）を行なう。このようにすれば、リクエスト利用主体識別子に対して、常に最新の推薦情報を提供することができる。

推薦情報作成の第３のタイミングは、アイテム提供サーバ２０を中継して送られる（ステップＳ２１０）、端末装置３０の利用リクエスト送信（ステップＳ２００）による利用リクエストを所定回数受信するごとである。この所定回数を調整することにより、情報選択装置１０の処理負荷の大きさと、推薦情報の新しさとのバランスを調整することができる。

通常は、所定回数をある程度大きな値として、情報選択装置１０の処理負荷があまり大きくならないようにするのがよい。一般的には、ある程度の数の利用履歴が追加されないと、新たな推薦情報を作成しても前回の推薦情報と似た内容になることが多いので、所定数を適切な値に設定すれば、情報選択装置１０の処理負荷を抑えながら、比較的新しい利用状況を反映させた推薦情報を提供することができる。特に、利用リクエストの数が季節、曜日、時間帯などにより大きく変動する場合や、利用リクエスト数の増減パターンを事前に予測するのが難しい場合には、第１のタイミングで推薦情報を作成するよりも、情報選択装置１０の処理負荷の軽減と、比較的新しい利用状況を推薦情報に反映させることとを両立させやすい。

以下の説明において、推薦情報を作成する対象となる利用主体識別子（情報選択に係る利用主体識別子）の集合を「推薦基準集合」と称する。第１のタイミングおよび第３のタイミングで推薦情報を作成する場合は基本的に、推薦基準集合の要素数が多数となる。第２のタイミングで推薦情報を作成する場合は、推薦基準集合の要素数は基本的に１つであるが、複数の場合もある。

まず、ステップＳ４００において、制御部１１０の指示を受けた関連度算出部１０４が、「アイテム推薦形式」および「カテゴリ推薦形式」に対応する２種類の関連度を算出し、これに基づき関連集合を作成し、関連集合を関連集合格納部１０５に格納させる。ステップＳ４１０において、制御部１１０の指示を受けた価格影響度算出部１０６が、価格情報格納部１０３を参照しながら、アイテムおよびカテゴリの価格が推薦結果に与える影響の度合いを示す価格影響度を算出する。

ステップＳ４２０において、制御部１１０の指示を受けた情報選択部１０７が、ステップＳ４００で算出された関連度、およびステップＳ４１０で算出された価格影響度を用いて、選択指標を算出する。

ステップＳ４３０において、情報選択部１０７が、選択指標に基づいて、アイテムまたはカテゴリを選択して、推薦情報格納部１０８に格納させる。そして、推薦情報作成動作が終了した旨を制御部１１０に通知する。

「アイテム推薦形式」および「カテゴリ推薦形式」に対応する関連集合作成処理（ステップＳ４００）について図１５のフローチャートを参照して説明する。

ステップＳ５００において、関連度算出部１０４は、利用履歴格納部１０２のアイテム利用履歴テーブル１０２Ａに記録されている利用履歴を読み出す。ここでは、すべての利用履歴を読み出してもよいし、所定の条件を満たす利用履歴を読み出してもよい。例えば、図６（ｂ）に示したアイテム利用履歴テーブル１０２Ａ−２のように利用時期情報を記録した上で、「利用時期が過去４ヶ月以内」「利用時期と現在との差が３日以上かつ３０日未満」などのように、「利用履歴の利用時期情報が所定の範囲にある」という条件を満たす利用履歴を読み出してもよい。

また、ユーザ（利用主体識別子）ごとに利用時期が新しい順に所定個数以内の利用履歴を読み出してもよい。例えば、所定個数を２０個とした場合、利用回数が２０回以上のユーザに対しては、利用時期が新しい順に２０個ずつの利用履歴を読み出し、利用回数が２０回未満のユーザに対しては、そのユーザに関するすべての利用履歴を読み出すようにする。このようにすれば、利用頻度が少なく、最近アイテムを利用していないようなユーザに対しても効率よく関連集合を作成することができる。

そして、このステップＳ５００で読み出した利用履歴に含まれるユーザ（利用主体識別子）の集合σを作成する。以下では、このステップで読み出した利用履歴に含まれるアイテムの数（アイテム識別子の種類数）をＭｓ、ユーザの数（利用主体識別子の種類数）をＵｓとする。

ステップＳ５１０において、関連度算出部１０４は、推薦基準集合Ｋ１を作成する。上述したように、第２タイミングで推薦情報を作成する場合には、リクエスト利用主体識別子を推薦基準集合Ｋ１に入れる。

第１および第３のタイミングで推薦情報を作成する場合は、ステップＳ５００で作成したアイテムの集合σを推薦基準集合Ｋ１とする。この場合は、所定条件を満たす利用履歴に含まれる利用主体識別子識別子それぞれに対して関連アイテム集合が作成されることになる。なお、ここで作成された推薦基準集合Ｋ１は、情報選択部１０７、制御部１１０などの他の処理部から参照することができる。

ステップＳ５２０において、関連度算出部１０４は、ステップＳ５１０で作成された推薦基準集合Ｋ１の中から未処理のユーザを１つ選択する。この処理対象となるユーザを基準ユーザｘとする。

ステップＳ５３０において、関連度算出部１０４は、ステップＳ５００で読み出された利用履歴を用いて、基準ユーザｘと、ユーザ集合σに属する他ユーザｙ（ｙ∈σ、ｘ≠y）との類似度を算出する。

具体的には、基準ユーザｘと他のユーザｙとが共に利用したことのあるアイテムの数｜Ｉ［ｘ］∩Ｉ［ｙ］｜を算出し、これを類似度とすることができる。また、ユーザｘが利用したアイテムの集合をＩ［ｘ］、ユーザｙが利用したアイテムの集合をＩ［ｙ］、ユーザｘとユーザｙとが共に利用したことのあるアイテムの数を｜Ｉ［ｘ］∩Ｉ［ｙ］｜、ユーザｘとユーザｙの少なくとも一方が利用したことのあるアイテムの数を｜Ｉ［ｘ］∪Ｉ［ｙ］｜としたとき、［数１］に示すように、ジャカード（Ｊａｃｃａｒｄ）係数を用いてユーザｘとユーザｙとの類似度Ｄ［ｘ］［ｙ］を算出することができる。

また、ステップＳ５００で読み出された利用履歴から、利用回数に関する情報やユーザがアイテムに対して行なった評価の情報（評価値）が得られる場合は、コサイン尺度やピアソン積率相関係数を用いて類似度を算出してもよい。例えば、ユーザｘのアイテムｚに対する利用回数または評価値をＥ［ｘ］［ｚ］（ただし、Ｅ［ｘ］［ｚ］≧０）、ユーザｙのアイテムｚに対する利用回数または評価値をＥ［ｙ］［ｚ］（ただし、Ｅ［ｙ］［ｚ］≧０）としたとき、［数２］を用いて、ユーザｘとユーザｙとの類似度Ｄ［ｘ］［ｙ］を算出することができる。ここで、γは０より大きい定数であり、γ＝１に設定すると、［数２］はコサイン尺度になる。γ＞１に設定すると、通常のコサイン尺度に比べ、利用回数または評価値が大きいデータの影響力を大きくして類似度を算出できる。また、Ｍｓは、ステップＳ５００で読み出された利用履歴に含まれるアイテムの数である。

また、［数３］に示すように、ピアソン積率相関係数を用いて、類似度Ｄ［ｘ］［ｙ］を算出してもよい。

ここで、Ｉｃ［ｘ］［ｙ］は、ユーザｘとユーザｙとが共に利用または評価したアイテムの集合であり、Ｅａ［ｘ］は、Ｉｃ［ｘ］［ｙ］に属するアイテムをユーザｘが利用した回数の平均値、または評価した評価値の平均値である。Ｅａ［ｙ］は、Ｉｃ［ｘ］［ｙ］に属するアイテムをユーザｙが利用した回数の平均値または評価値の平均値である。また、Ｅ［ｘ］［ｚ］とＥ［ｙ］［ｚ］とのユークリッド距離あるいはその他の距離を用いて、類似度Ｄ［ｘ］［ｙ］を算出してもよい。

また、利用履歴格納部１０２に利用時期情報が格納されている場合は、Ｅ［ｘ］［ｚ］などを算出する際に、利用時期が古い利用履歴より、新しい利用履歴の重みを大きくして算出してもよい。

さらに、ユーザｘのアイテムｚに対する利用回数または評価値であるＥ［ｘ］［ｚ］（ｘ＝１〜Ｕｓ、ｚ＝１〜Ｍｓ）を行列要素とする行列に対して、主成分分析や数量化３類などの多変量解析を適用し、次元数を削減したベクトルを生成し、コサイン尺度やユークリッド距離などを用いてユーザ間の類似度を算出してもよい。また、上記以外にも、ユーザ間の類似性を表わす指標であれば、どのような方法を用いてもよい。

このようにして算出されたユーザｘと、ユーザｙ（ｙ∈σ、ｘ≠y）との類似度は、関連度算出部１０４内部のメモリ（図示せず）に格納される。なお、ステップＳ５２０〜Ｓ５７０のループ（繰り返し）処理において、ユーザｘと、ユーザｙとの類似度が既に算出され、関連度算出部１０４内部のメモリに格納されている場合は、新たな算出を行なわずに格納されている値を利用してもよい。

ステップＳ５４０において、関連度算出部１０４は、基準ユーザｘとアイテムｚとの関連度Ｗ［ｘ］［ｚ］を算出する。

関連度算出の第１の方法は、ステップＳ５３０で算出された類似度Ｄ［ｘ］［ｙ］が高い「類似ユーザ」を特定し、類似ユーザに多く利用されたアイテムほど関連度が高くなるように算出する方法である。

具体的にはまず、類似度Ｄ［ｘ］［ｙ］が所定値以上のユーザ、あるいは類似度Ｄ［ｘ］［ｙ］が高い順に所定数のユーザを類似ユーザとして特定する。次に、ステップＳ５００で読み出された利用履歴を対象にして、類似ユーザが利用したアイテムを特定し、アイテムごとに利用回数をカウントし、この利用回数を関連度とする。あるいは利用回数の平方根や対数値などを用いて関連度を算出してもよい。第１の方法によれば、類似ユーザに利用されたアイテムの関連度が算出される。類似ユーザに利用されていないアイテムの関連度は「０」とすればよい。

この第１の方法は、ユーザがアイテムを気に入った場合に、そのアイテムを複数回利用（購入）する性質を持つようなアイテム提供サービスに適している。例えば、端末装置３０に保存できない形式のデジタルコンテンツや、消耗品の物販などである。

関連度算出の第２の方法は、多くの類似ユーザに利用されたアイテムほど関連度が高くなるように算出する方法である。第１の方法と同様に、類似ユーザを特定した後、ステップＳ５００で読み出された利用履歴を対象にして、類似ユーザが利用したアイテムを特定し、アイテムごとに利用した人数をカウントし、この利用人数を関連度とする。

第２の方法は、ユーザが基本的に同じアイテムを１度しか利用（購入）しない性質のアイテム提供サービスに適している。例えば、アイテムが端末装置３０に保存して何回でも再生できる形式のデジタルコンテンツであれば、ユーザが再度購入するのは、ユーザが端末装置３０から間違って消去したような例外的なケースが想定され、基本的には同じアイテムを１回しか購入しないので、この第２の方法が有効である。また、第１および第２の方法によれば、類似ユーザの数を適切に設定することにより、少ない計算量で、精度よく関連度を算出することができる。

関連度算出の第３の方法は、ユーザ間の類似度を直接用いて関連度を算出する方法である。具体的にはまず、ステップＳ５００で読み出された利用履歴を対象にして、ユーザｙ（ｙ∈σ、ｘ≠y）がアイテムｚを利用した回数Ｃ［ｙ］［ｚ］をカウントする。そして、［数４］に示すように、類似度Ｄ［ｘ］［ｙ］と利用回数Ｃ［ｙ］［ｚ］との積を加算した値を用いてユーザｘとアイテムｚとの関連度Ｗ［ｘ］［ｚ］を算出する。第３の方法では、アイテムｚの利用回数が多く、かつ利用したユーザの類似度が高いほど、関連度が高く算出される。

なお［数４］では、類似度Ｄ［ｘ］［ｙ］が算出されたすべてのユーザの情報を用いて関連度を算出しているが、類似ユーザを対象にして［数４］の計算を行なってもよい。また［数４］において、ユーザｙがアイテムｚを利用した場合にＣ［ｙ］［ｚ］＝１、利用していない場合にＣ［ｙ］［ｚ］＝０として計算してもよい。このようにすれば、アイテムｚを利用したユーザ数が多く、かつ利用したユーザの類似度が高いほど、関連度が高く算出される。この第３の方法によれば、基準ユーザとアイテムとの関連度をさらに精度よく算出することができる。

さらに関連度算出の第１〜第３の方法において、アイテム属性格納部１０１のアイテム情報テーブル１０１Ａからアイテム時期情報を読み出し、これを用いて処理を行なってもよい。具体的には、アイテム時期情報が新しいアイテムほど大きな値となる重み係数を算出し、利用回数や利用ユーザ数を算出する際に、この重み係数を乗じる等の演算を行なう。このようにすれば、ユーザにとって一般的に価値の高い「新作」アイテムの関連度を高くして、優先的に推薦情報に入れることができる。

ステップＳ５５０において、関連度算出部１０４は、基準ユーザｘに関する関連アイテム集合Ω［ｘ］を作成し、関連集合格納部１０５に格納させる。関連アイテム集合Ω［ｘ］は、関連識別子がすべてアイテム識別子であるような関連集合である。

関連アイテム集合作成の第１の方法は、ステップＳ５４０において基準ユーザｘとの関連度を算出したすべてのアイテム（関連度が「０」より大きいすべてのアイテム）を関連アイテム集合Ω［ｘ］に入れる方法である。この方法は、なるべく多くの推薦結果を出力したい場合に適している。

関連アイテム集合作成の第２の方法は、基準ユーザｘとの関連度が高いアイテムを選出して関連アイテム集合Ω［ｘ］に入れる方法である。具体的には、ステップＳ５４０において関連度を算出したすべてのアイテムの中から、関連度が閾値以上のアイテムを選出する。または、関連度が大きい順に所定値を超えない範囲でアイテムを選出してもよい。例えば、基準ユーザｘとの関連度が算出されたアイテムの数が所定数に満たない場合は、関連度が算出されたすべてのアイテムを選出し、そうでない場合は、関連度が大きい順に所定数のアイテムを選出すればよい。

さらに、基準ユーザｘとの関連度が所定値以上のアイテムの中から、関連度が大きい順に所定数を超えない範囲でアイテムを選出し、それらを関連アイテム集合Ω［ｘ］としてもよい。また関連アイテム集合Ω［ｘ］の要素が所定数以上得られるように、関連度の閾値を基準ユーザｘごとに調整して選出してもよい。この第２の方法によれば、関連集合格納部１０５に必要な記憶容量を削減でき、さらにステップＳ４１０〜Ｓ４３０の処理を効率よく行なうことができる。

そして、関連度算出部１０４は、基準ユーザｘの利用主体識別子と、関連アイテム集合Ω［ｘ］の各アイテム識別子と、その関連度とを対応させて、関連集合格納部１０５の関連度テーブル１０５Ａに記録する。具体的には、基準ユーザｘの利用主体識別子を図８に示した関連度テーブル１０５Ａの利用主体識別子に対応させ、関連アイテム集合Ω［ｘ］の各アイテム識別子を関連度テーブル１０５Ａの関連アイテム識別子に対応させて記録する。

ステップＳ５６０において、関連度算出部１０４は、基準ユーザｘに関する関連カテゴリ集合Φ［ｘ］を作成し、関連集合格納部１０５に格納させる。関連カテゴリ集合Φ［ｘ］は、関連識別子がすべてカテゴリ識別子であるような関連集合である。

関連度算出部１０４は、図４（ａ）に示したアイテム情報テーブル１０１Ａを参照しながら、ステップＳ５５０で作成された関連アイテム集合Ω［ｘ］を用いて、関連カテゴリ集合Φ［ｘ］を作成する。

関連カテゴリ集合Φ［ｘ］作成の第１の方法では、関連アイテム集合Ω［ｘ］の各要素に対応するカテゴリ識別子を特定し、特定されたカテゴリ識別子ごとの要素数をカウントし、この要素数をユーザｘとカテゴリとの関連度とする。そして、この要素数が所定数以上のカテゴリ識別子を関連カテゴリ集合Φ［ｘ］に入れる。なお、この所定数を「１」として、特定されたカテゴリ識別子をすべて関連カテゴリ集合Φ［ｘ］に入れてもよい。

関連カテゴリ集合Φ［ｘ］作成の第２の方法では、関連アイテム集合Ω［ｘ］の各要素に対応するカテゴリ識別子を特定し、特定されたカテゴリ識別子ごとに、関連アイテム集合Ω［ｘ］の各要素に対応する関連度の合計値を算出し、この合計値を関連度とする。そして、この合計値が所定値以上のカテゴリ識別子を選出して、関連カテゴリ集合Φ［ｘ］に入れる。例えば、関連アイテム集合に、Ａ、Ｂ、Ｃの３つの要素（関連アイテム）が存在し、各々の関連度が「１．０」、「０．８」、「０．４」であり、要素Ａはカテゴリ１に対応し、要素Ｂがカテゴリ２に対応し、要素Ｃもカテゴリ２に対応する場合、基準ユーザとカテゴリ１との関連度を「１．０」、基準ユーザとカテゴリ２との関連度を「０．８＋０．４＝１．２」とすればよい。

ある要素に対応するカテゴリ識別子が複数存在する場合は、各要素に対応する関連度をそのまま用いて合計値を算出してもよいし、各要素に対応する関連度をカテゴリ識別子の数で割った値を用いて合計値を算出してもよい。例えば、基準ユーザと要素Ａ（関連アイテムＡ）との関連度が「１．０」であり、要素Ａに、カテゴリ１とカテゴリ３の２つのカテゴリが対応する場合、基準ユーザとカテゴリ１との関連度の要素Ａに係る部分を「１．０」としてもよいし、「１．０÷２＝０．５」としてもよい。

なお、この所定値を十分小さな値にして、特定されたカテゴリ識別子をすべて関連カテゴリ集合Φ［ｘ］に入れてもよい。また、合計値の大きい順に所定数を越えない数のカテゴリ識別子を選出し、関連カテゴリ集合Φ［ｘ］に入れてもよい。

そして、関連度算出部１０４は、基準ユーザｘのアイテム識別子と、関連カテゴリ集合Φ［ｘ］の各カテゴリ識別子と、その関連度とを対応させて、関連集合格納部１０５の関連度テーブル１０５Ｂに記録する。具体的には、基準ユーザｘの利用主体識別子を図８に示した関連度テーブル１０５Ｂの利用主体識別子に対応させ、関連カテゴリ集合Φ［ｘ］の各カテゴリ識別子を関連度テーブル１０５Ｂの関連カテゴリ識別子に対応させて記録する。

なお、上述したユーザとアイテムとの関連度、およびユーザとカテゴリとの関連度、それぞれの算出工程において、関連度の最大値や合計値が所定値（例えば「１」）になるように、正規化処理を行なってもよい。

ステップＳ５７０において、関連度算出部１０４は、他の基準ユーザを選択可能か判定する。ステップＳ５１０で作成された推薦基準集合Ｋ１の中で、まだ処理を行なっていないユーザが存在する場合に「Ｙｅｓ」と判定し、未処理のユーザが存在しない場合は、「Ｎｏ」と判定する。「Ｙｅｓ」と判定した場合は、ステップＳ５２０に戻って処理を繰り返し、「Ｎｏ」と判定した場合は、関連度算出処理を終了する。

この結果、関連集合格納部１０５の関連度テーブル１０５Ａ、Ｂには、ステップＳ５１０で作成された推薦基準集合Ｋ１の利用主体識別子それぞれに対応し、「アイテム推薦形式」および「カテゴリ推薦形式」に対応する関連集合が格納される。

なお、利用履歴格納部１０２に、図５（ｄ）に示すようなカテゴリ利用履歴テーブル１０２Ｂが格納されている場合には、上述のステップＳ５００〜ステップＳ５５０の処理におけるアイテム識別子をカテゴリ識別子に置き換えて同様の処理を行なうことにより、「カテゴリ推薦形式」に対応する関連集合を作成することができる。この方法では、ステップＳ５５０に相当する処理により関連カテゴリ集合が作成されるため、ステップＳ５６０を実行する必要がない。このため、「アイテム推薦形式」を実施せず、「カテゴリ推薦形式」のみ実施する場合には、効率的に処理を行なうことができる。
＜価格影響度算出処理＞

ステップＳ４１０における価格影響度算出処理を詳細に説明する。制御部１１０は、ステップＳ４００により関連集合格納部１０５に格納された関連集合（関連識別子）を読み出し、価格情報格納部１０３を参照しながら、各関連識別子に対応する価格情報を価格影響度算出部１０６に入力し、価格影響度を算出させる。

例えば、関連識別子がアイテム識別子「ＩｔｅｍＩＤ−３」である場合は、図６（ａ）に示したアイテム価格情報テーブル１０３Ａを参照し、その価格情報である「３００円」を価格影響度算出部１０６に入力する。また例えば、関連識別子がカテゴリ識別子「ＣａｔｅｇｏｒｙＩＤ−３」である場合は、図６（ｂ）に示したカテゴリ価格情報テーブル１０３Ｂを参照し、その価格情報である「６０００円」を価格影響度算出部１０６に入力する。

価格影響度算出部１０６は、価格情報（価格）を入力Ｘとし、価格情報が推薦結果に与える影響を決める価格影響度を出力Ｙとする価格影響関数Ｆ（Ｘ）を内部の記憶領域に記憶している。

そして、価格影響度算出部１０６は、価格影響度算出部１０６または制御部１１０が備えるリアルタイムクロック等の計時機能を用いて、所定の時点と推薦情報の作成に係る時点との時間差、または所定の時点と推薦情報の提供に係る時点との時間差に応じて、価格影響関数の特性を変化させる。すなわち、所定の時点から、推薦情報の作成に係る時点または推薦情報の提供に係る時点までの経過時間に応じて、価格影響関数の特性を設定する。

この所定の時点としては、ユーザのアイテム利用意欲に係る可能性のある種々の時点を用いることができる。例えば、アイテム提供サービスが月額課金などの周期的な課金制度を採用している場合には、課金と引き換えに、ユーザの新たなアイテム利用権（新たなポイント）が発生する時点とすることができる。例えば、毎月１日午前０時に月会費として１０００円の課金が発生し、１０００円に相当するアイテム利用権（アイテムを利用するためのポイント）が、ユーザに付与されるサービスにおいては、毎月１日午前０時を所定の時点とすればよい。また、アイテム提供サービスが月額課金などの周期的な課金制度を採用していない場合には、一般的に多くの企業で給料が支給される日（例えば、毎月２５日）や、ボーナスが支給される日（例えば、１２月１０日）など、ユーザが収入を得る確率の高い時点を用いればよい。また、株式市場の株価の指標値、企業の決算情報、景気動向指数、ＧＤＰ（Gross
Domestic Product）等の経済指標など、経済に係る指標値、またはそれらの成長率が所定の条件を満たす時点を用いてもよい。例えば、経済指標が所定値以上になった時点や、経済指標が極大になる時点は、一般的にユーザの購買力が高く、ユーザのアイテム利用意欲も高い傾向にあると推定できる。

本実施形態においては、アイテム提供サービスが月額課金制度を採用しており、毎月１日午前０時に新たなアイテム利用権（アイテムを利用するためのポイント）が、ユーザに付与される場合を例に説明するが、これに限定されるものではない。また本実施形態においては、図１４に示す推薦情報作成処理を実行する時点を所定の時点とする場合を例にして説明するが、これに限定されるものではない。例えば、作成した推薦情報をユーザに提供開始する予定日時や、提供開始から提供終了までの期間の中間時点など、推薦情報の提供に係る時点を所定の日時として用いてもよい。また、所定の時点と、推薦情報の作成に係る時点または推薦情報の提供に係る時点との時間差（経過時間）Ｔｐを表現する単位として、秒単位、分単位、時単位、日単位、週単位など種々の単位を用いることができるが、本実施形態では、日単位を用いることとする。なお、本実施形態では、ユーザのアイテム利用意欲が大きくなる（例えば、極大）と推定される時点を所定の時点としているが、これとは逆に、利用意欲が小さくなる（例えば、極小）と推定される時点を所定の時点とすることも可能である。

価格影響度算出部１０６は、時間差Ｔｐを算出し、その値に応じて、価格影響関数の特性を設定する。以下では、時間差Ｔｐの値が３つの条件のどれに該当するか判定し、それぞれの条件に対応する３種類の関数を使う例を説明する。

Ｔｐが小さい場合（Ｔｐ≦μ１である場合）、図１６（ａ）に示すような関数Ｆ１（Ｘ）を用いる。ここでμ１は、例えば「１０日」等の所定の定数である。関数Ｆ１（Ｘ）は、関数の定義域（０≦Ｘ≦Ｘγ）すべてにおいて、Ｘ１＜Ｘ２である入力に対して、Ｙ１＜Ｙ２が常に成立する関数である。すなわち、単調増加関数である。また、Ｘγは価格情報格納部１０３に格納されている価格情報の上限である。このように、価格情報格納部１０３に格納されている価格情報に応じて、関数の入力の上限を設定してもよいし、関数の入力の上限を特に設定しなくてもよい。このような全区間が単調増加の線形関数を用いると、アイテム（またはカテゴリ）の価格が高いほど、価格影響度が大きくなり、そのアイテム（またはカテゴリ）が推薦される確率が高まる。時間差Ｔｐが比較的小さい場合には、ユーザが持つポイントが比較的多い（またはユーザがアイテム利用に使えるお金が比較的多い）可能性が高いので、価格の高いアイテム（またはカテゴリ）を推薦情報の中に多く含めると、アイテム提供サービス全体の売上を増大させる上で効果的である。なお本図の例のように、Ｘ＝０のときにＹ＝０となる関数を用いると、後述するように、価格が「０」の無料のアイテムおよびカテゴリを推薦結果に含めないことが容易にできる。

図１６（ａ）に示した関数Ｆ１（Ｘ）は単調増加の線形関数であるが、それに限定される訳ではなく、非線形関数を用いることもできる。非線形関数を用いることにより、価格影響度をよりきめ細かく、高い精度で算出することができる。

時間差Ｔｐが中程度である場合（μ１＜Ｔｐ≦μ２である場合）には、図１６（ｂ）に示すような関数Ｆ２（Ｘ）またはＦ２ｂ（Ｘ）を用いる。ここで、μ２は、例えば「２０日」等のμ１＜μ２を満たす所定の定数である。時間差Ｔｐが中程度である場合には、ユーザが持つポイント（あるいはユーザがアイテム利用に使えるお金）が、時間差Ｔｐが小さい場合に比べて、減少している可能性が高い。従って、図１６（ｂ）に示すような、高い価格のアイテムの価格影響度があまり大きくならない特性を持つ関数を用いるのがよい。

関数Ｆ１（Ｘ）では、Ｘ２とＸγとの間の区間も単調増加であるため、価格が高いアイテムの価格影響度は非常に大きくなる。関数Ｆ１（Ｘ）では、入力ＸがＸ２より大きいＸγにおいて、出力ＹγはＹ２よりも大きな値となる。一方、関数Ｆ２（Ｘ）では、Ｘ２とＸγとの間の区間では、価格影響度が増加せず一定であり、Ｙ２＝Ｙγであるため、価格が高いアイテムの価格影響度も極端には大きくならない。また、関数Ｆ２ｂ（Ｘ）では、Ｘ２とＸγとの間の区間では、価格影響度が逆に減少する（Ｙγ＜Ｙ２）。このため、関数Ｆ２（Ｘ）またはＦ２ｂ（Ｘ）を用いると、関数Ｆ１（Ｘ）に比べて、推薦情報に価格が高いアイテムが含まれる確率が低下する。また、図１６（ｂ）において、０≦Ｘ＜ｘ１の区間が、単調増加ではなく、一定の出力となる特性の関数を用いてもよい。そのような特性の関数を用いることにより、図１６（ｂ）に示す関数Ｆ２（Ｘ）およびＦ２ｂ（Ｘ）に比べて、価格の安いアイテムも推薦情報に入り易くなる。

時間差Ｔｐが大きい場合（μ２＜Ｔｐ、またはμ２＜Ｔｐ≦μ３である場合）には、図１６（ｃ）に示す関数Ｆ３（Ｘ）を用いる。ここでμ３は、例えば「３０日」等のμ２＜μ３を満たす所定の定数である。アイテム提供サービスが月額課金であり、毎月１日から月末までが１つのまとまった期間として扱われる場合は、μ３が月ごとの月末の日に相当するように調整するとよい。なお本実施形態においては、翌月１日の午前０時の時点で、所定の時点がそれまでの時点よりも１ヶ月後に更新されるため、μ３を使わなくても処理可能である。本図に示すように、関数Ｆ３（Ｘ）は、Ｘ３とＸ４の２箇所（Ｘ３＜Ｘ４）においてピーク（極大点）を持つ関数である。このように、時間差Ｔｐに応じて、関数のピークの個数を変化させてもよい。Ｘ３における出力値Ｙ３と、Ｘ４における出力値Ｙ４は、同じであっても異なっていてもよい。

時間差Ｔｐが大きい場合（本実施形態では、毎月の下旬に相当）、ユーザが持つポイント（あるいはユーザがアイテム利用に使えるお金）の額は、ユーザによって大きく異なる傾向にある。一般的には、時間の経過に従って、ユーザが保有するポイント数は減少するが、アイテム提供サービスをあまり利用しないユーザのポイント数は、ほとんど減少しない。このため、月の下旬にユーザが保有するポイント数は、個人差が大きく、少ないポイントしか保有していないユーザ群と、多くのポイントを保有しているユーザ群の２つのグループに分かれる傾向がある。更に、当月分のポイントが月末で無効になる課金制度を採用するアイテム提供サービスにおいては、自分の保有するポイントを月末までに使い切ろうとする心理がユーザに働く、このため、図１６（ｃ）に示すような関数Ｆ３（Ｘ）を用いて、価格の安いアイテムと、価格の高いアイテムの両方とも推薦情報に入り易くすることにより、多くのユーザの購入意欲を高め、サービス全体の売上を増大させることにつながる。

図１６に示す関数Ｆ１（Ｘ）〜Ｆ３（Ｘ）は、直線で構成される関数であるが、図１７に示すような滑らかな非線形関数を用いてもよい。例えば、図１６（ａ）のＦ１（Ｘ）の代わりに図１７（ａ）に示す関数Ｆ４（Ｘ）を用いてもよい。この関数は、中央部分で最も勾配（微分係数）が大きく、両側に行くほど勾配が小さくなる特性を持つ。例えば、ロジスティック関数を用いればこのような特性が得られる。本図の例のように滑らかな関数を用いると、価格影響度が急激に変化するのを防ぐことができる。

同様に、図１６（ｂ）のＦ２（Ｘ）およびＦ２ｂ（Ｘ）の代わりに図１７（ｂ）に示す関数Ｆ５（Ｘ）を、図１６（ｃ）のＦ３（Ｘ）の代わりに図１７（ｃ）に示す関数Ｆ６（Ｘ）用いてもよい。更に、図１８（ａ）に示すような離散的な関数（階段状の関数）Ｆ７（Ｘ）を用いてもよい。本図の線分の端点の黒丸はその値を含み、白丸はその値を含まないことを示している。Ｙ方向の値は２種類以上であればよい。ただし、推薦情報に含めるアイテム（またはカテゴリ）を適切に順位付けるという観点からは、Ｙ方向の値の種類がある程度多い方が望ましく、３種類以上あることが望ましい。本図の例のように離散的な関数を用いると、処理が比較的単純になり、情報選択装置１０の処理負荷を低減することができる。

また、図１８（ｂ）に示すような関数Ｆ８（Ｘ）〜Ｆ１０（Ｘ）を用いてもよい。これら３つの関数は、Ｘ≦Ｘαで最小値Ｙα、Ｘ≧Ｘβで最大値Ｙβをとる点では共通であるが、その間のカーブの形状（勾配）が異なっている。このため、所定の出力値（例えば、Ｙ＝Ｙｃ）を得るための入力値が３つの関数で異なっている。時間差Ｔｐに応じて、Ｆ８（Ｘ）〜Ｆ１０（Ｘ）を使い分けてもよい。これら３つの関数は、単調減少区間を持たないため、価格の高いアイテムほど価格影響度が高くなるが、その度合いが関数によって異なっている。Ｆ８（Ｘ）では、価格が比較的安い領域（Ｘ＜Ｘｃ）の出力と、最大出力Ｙβとの差（倍率）が大きいため、価格が比較的安いアイテムの価格影響度に比べて、価格の高いアイテムの価格影響度が非常に大きくなる。すなわち、３つの関数の中で、価格の高いアイテムの優先度合いが最も高い。このため、時間差Ｔｐが小さいときに、ユーザの購買力が最も大きいと判断すれば、３つの関数の中では関数Ｆ８（Ｘ）を使うとよい。

関数Ｆ１０（Ｘ）は逆に、価格が比較的の出力と、最大出力Ｙβとの差（倍率）が小さいため、価格が比較的安いアイテムの価格影響度に比べて、価格の高いアイテムの価格影響度はそれほど大きくない。このため、Ｆ８（Ｘ）に比べると、推薦情報に価格の安いアイテムが入り易い。時間差Ｔｐが大きいときに、ユーザの購買力が最も低いと判断すれば、３つの関数の中では関数Ｆ１０（Ｘ）を使うとよい。関数Ｆ９（Ｘ）は、Ｆ８（Ｘ）とＦ１０（Ｘ）の中間的な性質である。時間差Ｔｐが中程度であるときに、ユーザの購買力も中程度であると判断すれば、３つの関数の中では関数Ｆ９（Ｘ）を使うとよい。

上述した関数Ｆ１（Ｘ）〜Ｆ１０（Ｘ）はあくまでも例示であり、この他に、対数関数や指数関数を用いてもよい。なお、関連識別子がアイテム識別子であるか、カテゴリ識別子であるかに応じて、特性の異なる関数を用いてもよい。

価格影響度算出部１０６は、価格影響関数Ｆ（Ｘ）を数式として内部の記憶領域に記憶しておき、入力が与えられるごとに、その数式に従って価格影響度を算出してもよい。この方式によれば、必要なメモリ量を少なくすることができ、価格影響度を精度よく（高い解像度で）算出することができる。

あるいは、関数Ｆ（Ｘ）に従って、入力Ｘに対する出力Ｙをあらかじめ算出しておき、算出結果の（Ｘ，Ｙ）の情報を記憶領域に格納しておいてもよい。例えば、記憶領域のＸに相当するアドレスにＹの値を格納するＬＵＴ（Look-Up
Table）方式を用いることができる。この方式によれば、入力が与えられてから出力するまでに、数式を計算する必要がないので、処理量を少なくすることができ、応答時間を短くすることができる。また価格影響度の値が所定の範囲（０以上１以下など）に収まるような正規化を行なってもよいし、行なわなくてもよい。
＜選択指標算出処理＞

ステップＳ４２０における選択指標算出処理を詳細に説明する。制御部１１０の指示を受けた情報選択部１０７は、ステップＳ４１０で価格影響度が算出された各関連識別子について、その関連度Ｗと価格影響度Ｙとを用いて選択指標Ｓを算出する。この選択指標Ｓは、関連度Ｗが大きいほど、かつ価格影響度が大きいほど大きな値となる数値であり、以下の方法で算出する。
選択指標算出の第１の方法は、［数５］を用いる方法である。

すなわち、利用主体識別子ｉと関連識別子ｊとの関連度Ｗ［ｉ］［ｊ］を基数としてγａを指数とする累乗値を算出し、価格影響度Ｙ［ｊ］を基数としてγｂを指数とする累乗値を算出し、それらの乗算値を用いて選択指標Ｓ［ｉ］［ｊ］を算出する方法である。ここで、βｃ、γｂは０より大きな定数である。また、γａも基本的に０より大きな定数であるが、後述するように、関連度を用いずに選択指標を算出することも可能であり、その場合は、γａ＝０、γｂ＝１とすることに相当する。

この第１の方法では、関連度と価格影響度が両方とも大きい関連識別子が推薦結果に入りやすい。また図１６（ａ）に示したような、価格情報が０のときに価格影響度も０になる特性の関数を用いた場合、価格が０の無料アイテムの選択指標は０になるので、無料アイテムを推薦結果から除外することも簡単にできる。さらにγａおよびγｂを調整することにより、推薦結果に入る関連識別子を変えることができる。

例えば、γａを大きくすることにより、関連度Ｗ［ｉ］［ｊ］が大きい関連識別子がより推薦結果に入りやすくなる。またγｂを大きくすることにより、価格影響度Ｙ［ｊ］が大きい関連識別子がより推薦結果に入りやすくなる。なお、βｃ＝γａ＝γｂ＝１として、関連度と価格影響度との積を選択指標にしてもよい。

選択指標算出の第２の方法は、［数６］を用いる方法である。

すなわち、関連度Ｗ［ｉ］［ｊ］とβａとの乗算値と、価格影響度Ｙ［ｊ］とβｂとの乗算値を算出し、それらの加算値を選択指標Ｓ［ｉ］［ｊ］とする方法である。ここで、βａおよびβｂは重み係数であり、βｂは０より大きな定数である。また、βａも基本的には０より大きな定数であるが、後述するように、関連度を用いずに選択指標を算出することも可能であり、その場合は、βａ＝０、βｂ＝１とすることに相当する。［数６］は、関連度と価格影響度とをそれぞれ重み付けして加算した値といえる。

第２の方法でも、関連度と価格影響度が両方とも大きな関連識別子が最も推薦結果に入りやすいが、第１の方法と比べると、関連度と価格影響度のいずれかが大きい関連識別子も推薦結果に比較的入りやすい。さらにβａおよびβｂを調整することにより、推薦結果に入る関連識別子を変えることができる。

例えば、βａを大きくすることにより、関連度Ｗ［ｉ］［ｊ］が比較的大きい関連識別子がより推薦結果に入りやすくなる。またβｂを大きくすることにより、価格影響度Ｙ［ｊ］が比較的大きい関連識別子がより推薦結果に入りやすくなる。なお、βａ＝βｂ＝１として、関連度と価格影響度との和を選択指標にしてもよい。
選択指標算出の第３の方法は、［数７］を用いる方法である。

すなわち、関連度Ｗ［ｉ］［ｊ］の対数値とβｄとの乗算値と、価格影響度Ｙ［ｊ］の対数値とβｅとの乗算値を算出し、それらの加算値を選択指標Ｓ［ｉ］［ｊ］とする方法である。ここで、βｄおよびβｅは０より大きな定数であり、重み係数である。［数７］は、関連度の対数値と価格影響度の対数値とをそれぞれ重み付けして加算した値といえる。また、βｄおよびβｅを調整することにより、推薦結果に入る関連識別子を変えることができる。なお、βｄ＝βｅ＝１として、関連度と価格影響度との和を選択指標にしてもよい。第３の方法は、関連度または価格影響度のダイナミックレンジが広い場合や、両者のダイナミックレンジが大きく異なる場合に適している。

なお、関連度の代わりに、関連度の順位を用いて、順位が高いほど、かつ価格影響度が大きいほど、大きな値となるように選択指標を算出してもよい。例えば、推薦情報格納部１０８と同様に、関連度が大きいほど高い順位を示す番号（順位番号）を関連集合格納部１０５に格納しておき、それを用いるようにすればよい。

また、関連度および価格影響度だけでなく、さらに他の情報を用いて選択指標を算出してもよい。例えば、情報選択部１０７がアイテム属性格納部１０１のアイテム情報テーブル１０１Ａを参照して、関連識別子ｊのアイテム時期情報Ｔ［ｊ］を読み出し、関連度Ｗ［ｉ］［ｊ］が大きいほど、かつ価格影響度Ｙ［ｊ］が大きいほど、かつアイテム時期情報Ｔ［ｊ］が新しいほど（処理時点とアイテム時期情報との差が小さいほど）、大きな値となるように選択指標を算出してもよい。
＜推薦情報選択処理＞

ステップＳ４３０における推薦情報選択処理を詳細に説明する。ステップＳ４３０において、情報選択部１０７は、ステップＳ４２０で算出された選択指標に基づいて、関連集合の中から関連識別子を選択する。

具体的には、選択指標Ｓ［ｉ］［ｊ］が所定値θ１以上の関連識別子を関連集合から選択する。または、選択指標Ｓ［ｉ］［ｊ］が大きい順に所定数η１を超えない数の関連識別子を選択してもよい。例えば、関連集合の要素数が所定数η１に満たない場合は、関連集合の要素をすべて選択し、そうでない場合は、選択指標が大きい順に所定数η１の関連識別子を選択すればよい。

さらに、選択指標が所定値θ２以上の関連識別子を対象にして、選択指標が大きい順に所定数η２を超えない範囲で選択してもよい。この場合、選択指標がθ２以上の関連識別子の数がη２に満たない場合は、θ２以上の関連識別子をすべて選択する。また、利用主体識別子ｉに対して、所定数η３個以上の関連識別子が選択できるように所定値θ３を利用主体識別子ごとに設定し、選択指標がθ３以上の関連識別子を選択してもよい。

なお、利用履歴格納部１０２を参照しながら、利用主体識別子ｉに対応するユーザが既に利用したアイテムおよびカテゴリを特定し、それらを除外して（利用済み除外処理を行なって）選択集合を作成してもよい。ユーザが１回しか同じアイテム（カテゴリ）を購入しない性質を持つようなアイテム提供サービスでは、このステップＳ４３０において利用済みのものを選択集合から除外しておくと、推薦情報格納部１０８の記憶容量を節約できる。ステップＳ４３０において利用済み除外処理を行なう場合、ステップＳ１７０での利用済み除外処理を省略してもよいし、再度行なってもよい。ステップＳ４３０を実行した後、ステップＳ１７０を実行するまでの間に、新たな利用履歴が格納される可能性がある場合は、両方のステップで利用済み除外処理を行なう方が、推薦精度の向上の面では確実である。

このような方法で選択された関連識別子の選択指標に従って、推薦順位を付与する。すなわち、選択指標が大きいほど、高い推薦順位を付与する。そして、利用主体識別子と、関連識別子と、推薦順位とを対応させて、図７（ａ）、図７（ｂ）に示す形式で、推薦情報テーブル１０８Ａ、１０８Ｂを推薦情報格納部１０８に格納させる。以上、推薦情報選択処理を説明した。

第１実施例の最後に、図１９を用いて、推薦情報の具体例を説明する。関連集合格納部１０５には図１９（ａ）に示すような「アイテム推薦形式」のデータが格納されているものとする。本図に示すように、「ＵｓｅｒＩＤ−１」の関連集合は、「ＩｔｅｍＩＤ−３」〜「ＩｔｅｍＩＤ−７」の５つのアイテムである。「ＵｓｅｒＩＤ−２」の関連集合もまったく同じ５つのアイテムであるが、各々の関連度は異なっているものとする。また、図１９（ｂ）に示すように価格情報格納部１０３には、「ＩｔｅｍＩＤ−１」〜「ＩｔｅｍＩＤ−７」の７つのアイテムの価格情報が格納されている。

説明を簡単にするため、時間差Ｔｐが小さく、価格影響関数として図１６（ａ）に示した関数Ｆ１（Ｘ）を用いることとし、この関数の傾きが「１」であるとする。情報選択部１０７では、［数６］を用いて選択指標を算出し、βｃ＝γａ＝γｂ＝１であるとする。また、情報選択部１０７は、選択指標の大きい順に３つのアイテムを選択して推薦情報を作成するものとする。

以上の条件において、仮に、価格情報を使わずに関連度だけでアイテムを選択したとすると、図１９（ａ）から明らかなように、「ＵｓｅｒＩＤ−１」に対応する推薦アイテムは、１位が「ＩｔｅｍＩＤ−３」、２位が「ＩｔｅｍＩＤ−４」、３位が「ＩｔｅｍＩＤ−５」になる。これらの価格は各々「１０００円」「２００円」「４００円」である。

一方、関数Ｆ１（Ｘ）を用いて選択指標を算出すると、「ＩｔｅｍＩＤ−３」については、「１０００×１．０＝１０００」となる。他のアイテムについても同様に算出した結果を図１９（ｃ）に示す。本図において選択指標の大きい順に「ＵｓｅｒＩＤ−１」に対するアイテムを３つ選択すると、１位が「ＩｔｅｍＩＤ−６」、２位が「ＩｔｅｍＩＤ−３」、３位が「ＩｔｅｍＩＤ−５」となる。各々の価格は「１５００円」「１０００円」「４００円」である。このように、関数Ｆ１（Ｘ）を用いると、関連度だけでアイテムを選択する場合に比べて、価格の高いアイテムを推薦結果に入れることができる。

また、価格情報を使わずに関連度だけでアイテムを選択したとすると、「ＵｓｅｒＩＤ−２」に対応する推薦アイテムは、１位が「ＩｔｅｍＩＤ−４」、２位が「ＩｔｅｍＩＤ−５」、３位が「ＩｔｅｍＩＤ−７」になる。これらの価格は各々「２００円」「４００円」「８００円」である。

一方、関数Ｆ１（Ｘ）を用いて選択指標を算出すると、１位が「ＩｔｅｍＩＤ−７」、２位が「ＩｔｅｍＩＤ−５」、３位が「ＩｔｅｍＩＤ−４」となり、各々の価格は「８００円」「４００円」「２００円」である。この場合は３つのアイテムの価格の合計は、関連度のみを用いた場合と同じになるが、価格の高いアイテムが上位の推薦順位となり、ユーザの目に留まりやすくなる。

また、「ＵｓｅｒＩＤ−１」に対する推薦結果には、価格の高い「ＩｔｅｍＩＤ−６」と「ＩｔｅｍＩＤ−３」が入るが、「ＵｓｅｒＩＤ−２」に対する推薦結果には、これらが入らない。このことからも分かるように、価格影響関数として、単調増加関数である関数Ｆ１（Ｘ）を用い、価格影響度と関連度とを用いて選択指標を算出すると、ユーザと推薦アイテム／カテゴリとの関連度が高い場合、すなわちそのユーザが推薦アイテム／カテゴリを気に入る可能性が高い場合にのみ価格の高いアイテムが推薦されるので、ユーザに不自然な印象を与えるリスクが少ない。このため、時間差Ｔｐが小さい時期（ユーザのアイテム利用意欲が一般的に旺盛な時期）に、そのような推薦情報を提供することにより、アイテム提供サービス全体の売上増大につながると期待できる。

なお、上述の説明では、関数Ｆ１（Ｘ）を価格影響関数に用いる一例を説明したが、時間差Ｔｐに応じて、これとは特性の異なる関数を用いることにより、図１９（ｃ）に示す選択指標と異なる値が算出され、推薦情報に入るアイテムが時間差Ｔｐに応じて変化することは明らかである。例えば、価格の安いアイテムを優先的に推薦情報に入れたり、価格が中程度のアイテムを優先的に推薦情報に入れることが柔軟にできる。

本実施形態は、インターネットサービスで広く採用されている月額課金制度、多くの企業で採用されている月給制度などを鑑み、ユーザがアイテム利用に使えるお金（ポイント等を含む）が時間的、周期的に変化することに着目したものであり、特許文献２に開示された技術のように、厳重な管理が必要となるユーザの金融資産の情報を一切用いていないため、幅広い事業、サービスに応用することが可能である。月額課金制度において新たなアイテム利用権がユーザに付与される時点や、給料日を所定の時点とし、この所定の時点と推薦情報の作成に係る時点との時間差、または所定の時点と推薦情報の提供に係る時点との時間差であるＴｐに応じて、価格影響関数を設定しているため、推薦情報に入れるアイテムの価格帯を適切なタイミングで調整することができる。このため、推薦情報の提供により、ユーザの購入意欲が増大する可能性を従来技術より大きくすることができ、アイテム提供サービスの売上増大につながる。

また、従来技術では、推薦アイテムの価格が所定の範囲（所定の価格帯）に制限されてしまうため、推薦結果のバリエーション（多様性）が少なかったり、推薦アイテム数が少ない場合があった。しかしながら、図１９に示す例で、「ＵｓｅｒＩＤ−１」の推薦アイテムの価格が、「１５００円」「１０００円」「４００円」となり、これらの間の「８００円」が抜けていることからも分かるように、本実施例の方法では、推薦アイテム／カテゴリの価格が所定の範囲に制限されていないため、従来よりも推薦結果のバリエーションが多くなり（多様性があり）、長期間にわたり同じユーザに推薦情報を提供する場合であっても、ユーザが推薦情報に飽きてしまうことが少なく、継続的に推薦情報を利用してもらうことができる。

また、従来技術では、所定の条件を満たすアイテム（所定の価格帯のアイテム等）が無い場合や、少ししか存在していない場合には、十分な数の推薦情報を提供することができなかった。一方、第１実施例の方法によれば、所定の価格帯のアイテムが無い場合や、少ししか存在していない場合であっても、十分な数の推薦情報を精度良く選択して提供することができる。

また逆に、所定の条件を満たすアイテム（所定の価格帯のアイテム等）が多数存在する場合、従来技術では、それらを精度良く絞り込むことができず、推薦情報が多くなり過ぎる場合があった。推薦情報は本来、多くの情報の中からユーザに有用な情報を絞り込んで提供するものであり、端末装置３０の表示装置において、推薦情報が表示できる領域にも限りがあることから、推薦情報を必要十分な数にすることは非常に重要である。第１実施例の方法によれば、算出した選択指標に応じて推薦順位を決定することができる。そして、推薦順位の上位のアイテムを優先的にユーザに提供するので、必要十分な数のアイテムを精度良く絞り込んでユーザに提供できる。

アイテム提供サービスを行なう事業者にとって、推薦情報を提供する目的は、推薦情報によってアイテム利用が促進され、アイテム提供サービスの売上を増大させることである。すなわち、売上増大につながる実効性のある推薦情報が要求される。この目的を達成するためには、ある程度の数の推薦情報が必要であり、多過ぎず、少な過ぎでもない適切な数（量）の推薦情報をユーザに提供する必要がある。第１実施例の方法によれば、適切な数（量）の推薦情報を精度良く選択してユーザに提供できるので、アイテム提供サービスの売上を増大させる実効性が期待できる。

なお、第１実施例では、情報選択装置１０が、価格影響度を算出し、選択指標を算出して推薦情報を作成するようにしていたが、これらの処理、あるいは、これらの処理の一部を端末装置３０側で行なうようにしてもよい。

この場合、端末装置３０のアプリケーション部３０４に、価格影響度算出部１０６および情報選択部１０７に相当する動作を行なわせるようにする。例えば、ステップＳ１６０に先立つ適当なタイミングで、アプリケーション部３０４が、アイテム提供サーバ２０を経由して、あるいは直接情報選択装置１０から、アイテム情報テーブル１０１Ａ、カテゴリ情報テーブル１０１Ｂ、関連度テーブル１０５Ａ、１０５Ｂ、およびアイテム価格情報テーブル１０３Ａ、カテゴリ価格情報テーブル１０３Ｂのデータを取得する。このとき、各々のテーブルの全部のデータを取得してもよいし、リクエスト利用主体識別子に関係するデータ等の必要なデータのみを取得するようにしてもよい。そして、ステップＳ１６０において、推薦リクエストを送信する代わりに、上述の手順に従って価格影響度を算出し、算出した価格影響度と取得した関連度とを用いて、選択指標を算出することで推薦情報を作成する。具体的には、ステップＳ４１０、Ｓ４２０、Ｓ４３０、Ｓ１７０に相当する処理をアプリケーション部３０４が実行すればよい。この場合、アプリケーション部３０４に、データ取得部、価格影響度算出部、情報選択部が形成されることになる。以下の実施例においても同様に、情報選択装置１０の一部の動作を端末装置３０で行なうようにしてもよい。

また、第１実施例では、価格影響度と関連度とを用いて選択指標を算出する例を説明したが、関連度を用いずに、選択指標を算出してもよい。例えば、関連度算出部１０４および関連集合格納部１０５を省略し、その代わりに、利用履歴格納部１０２のデータを用いて、多くのユーザの間で人気の高いアイテムの情報を作成する人気度算出部（図示せず）を設け、この人気度を関連度の代わりに用いて（人気度と価格影響度とを用いて）選択指標を算出してもよい。具体的には、複数のユーザの利用履歴を用いて、アイテムごとの利用数や利用人数を集計し、人気度とすることができる。そして、［数６］または［数７］において、関連度の代わりに人気度を用いて、選択指標を算出すればよい。人気度が高く、かつ価格影響度の高いアイテムの選択指標が大きな値となるため、そのようなアイテムが推薦情報に入り易くなる。人気度を用いる場合、全てのユーザに同じアイテムが推薦されるので、ユーザ個人ごとに異なる関連度を用いる場合に比べて、推薦情報がユーザ個人の嗜好に合致する可能性は低下するが、一般的に人気の高いアイテムなので、推薦効果が期待できる。また、時間差Ｔｐに応じて、価格影響関数の特性が変わるので、関連度を用いる場合と同様に、推薦情報に入れるアイテムの価格帯を適切なタイミングで調整することができる。

また、アイテム提供サービスの提供者（事業者）が、ユーザに対して薦めたいアイテムの集合と、それぞれのアイテムのお薦め度合いを示す推薦度（提供者推薦度）を用意した上で、提供者推薦度と価格影響度とを用いて、選択指標を算出してもよい。この場合も全てのユーザに対して同じ推薦情報が提供されることになるが、アイテムに関する知識の豊富な専門家（事業者）が選んだアイテムなので、推薦効果が期待できる。推薦度が高く、かつ価格影響度の高いアイテムの選択指標が大きな値となるため、そのようなアイテムが推薦情報に入り易くなる。また、人気度と推薦度と価格影響度とを組合せて、人気度が高く、かつ推薦度が高く、かつ価格影響度が高いほど、選択指標が大きな値となるように算出してもよい。また、関連度と人気度と推薦度と価格影響度とを組合せて、関連度が高く、かつ人気度が高く、かつ推薦度が高く、かつ価格影響度が高いほど、選択指標が大きな値となるように算出してもよい。

更に、価格影響度そのものを選択指標としてもよい。例えば、価格情報格納部１０３に格納されている全てのアイテム（またはカテゴリ）について価格影響度を算出し、価格影響度の大きさに基づいて推薦情報を作成してもよい。この場合、選択指標の算出処理を省略できるので、情報選択装置１０の処理量を低減することができる。時間差Ｔｐに応じて、
価格影響関数の特性が変わるので、この場合であっても、従来技術に比べて、入手が困難であり、厳重な管理が必要となる金融資産等の個人情報を用いることなく、推薦情報に入れるアイテムの価格帯を適切なタイミングで調整することができる。価格影響関数を用いているため、どの価格をどの程度優先させるかを非常に柔軟に設定／変更できる。また、図１６および図１７に示すような連続量を出力する関数を用いた場合、または図１８（ａ）に示す離散関数が３値以上の値を取るようにすれば、時間差Ｔｐがある値となる瞬間（ある瞬間）に限定したとしても、多値の価格影響度を算出しているため、推薦アイテムの順位付けや推薦アイテムの絞り込みを、従来技術よりも適切に行うことができる。
（実施例２）

本実施形態に係るネットワークシステムの第２実施例について説明する。第２実施例では、端末装置３０を利用するユーザが、好みに応じて、価格影響度を調整することができるようになっている。第２実施例において、アイテム提供サーバ２０および端末装置３０は、第１実施例と同様とすることができる。

図２０は、第２実施例における情報選択装置１０ｂの構成を示すブロック図である。本図に示すように、情報選択装置１０ｂは、アイテム属性格納部１０１と、利用履歴格納部１０２と、価格情報格納部１０３と、関連度算出部１０４と、関連集合格納部１０５と、価格影響度算出部１０６ｂと、情報選択部１０７ｂと、推薦情報格納部１０８と、送受信部１０９と、制御部１１０ｂとを備えて構成されている。また、情報選択装置１０には、情報選択装置１０の管理者向けに必要な情報を表示するための表示装置１２０と、管理者が操作を行なうためのキーボード、マウス等の入力装置１３０とが接続されている。

すなわち、第２実施例の情報選択装置１０ｂは、第１実施例の情報選択装置１０と比べて、価格影響度算出部１０６、情報選択部１０７、制御部１１０の動作が一部異なる構成となっている。

制御部１１０ｂは、第１実施例と同様に、所定のタイミングで推薦情報作成動作を開始する。ただし第２実施例では、図１４に示した推薦情報を作成する動作のフローチャートにおいてステップＳ４００が終了した段階で推薦情報作成動作を終了する。ステップＳ４１０以降に相当する処理は、後述するステップＳ１７０ｂにおいて、表示用推薦データを作成する際に行なう。

第２実施例におけるシステム全体の動作は、処理ステップ間の関係において図１１に示したフローチャートと同様であり、処理ステップの具体的内容において第１実施例と一部異なる。以下では、第１実施例と動作が異なる処理ステップにについて説明する。異なる処理ステップについては符号の末尾に「ｂ」を付加して表記する。

図１１のステップＳ１３０ｂにおいて、アイテム提供サーバ２０の制御部２０５は、応答データを端末装置３０に送信する。第２実施例における応答データ（画面表示情報）には、ユーザが価格影響度を調整するための操作画面を表示する情報が含まれている。なお、情報選択装置１の表示制御情報作成部（図示せず）が、このような応答データを作成し、端末装置３０に送信するようにしてもよい。

ステップＳ１４０ｂにおいて、端末装置３０は、アイテム提供サーバ２０または情報選択装置１から受信した応答データに基づき、表示装置３２０にその情報を表示する。表示画面の一例を図２１に示す。図１２に示した第１実施例の表示画面との違いは、画面右上に「価格影響度の調整操作」ボタンが表示される点である。

「価格影響度の調整操作」ボタンは、価格影響度を調整するために必要なデータ（価格影響度調整データ）をユーザに入力させるためのＧＵＩ（Graphical User
Interface）を表示させるためのボタンであり、例えば、図２２に例示するような画面を表示させることができる。画面移動ではなく、図２２に示す情報を、図２１の表示画面に含めるようにしてもよい。

図２２（ａ）に示す例は、推薦結果に入れるアイテムまたはカテゴリの中心的な価格帯を指定するための画面である。複数の期間ごとに、５つの選択肢に対応して、円形のラジオボタンが表示されている。ラジオボタンの横の「１」〜「５」の数字は、ラジオボタンを識別するための番号であり、ユーザに選択されたラジオボタンの番号を端末装置３０が読み取れるようになっている。

本図に示す例では、２つの期間が設定されており、それぞれの期間の条件として、月初（毎月１日）からの経過日Ｔｐが表示されている。ユーザは、「１０日」、「３１日」といった期間の定義（経過日の範囲）を自由に設定、変更できる他、「期間の追加」をボタンを使って、自由に期間を追加できる。例えば、１ヶ月を６つの期間に分ける設定することも可能である。また、期間を選択した状態で、「期間の削除」ボタンを押すと、その期間を削除することができる。ユーザは、期間の設定、およびそれぞれの期間における推薦情報に入れるアイテム（またはカテゴリ）の価格帯に関する希望を設定した後、「決定」ボタンを押すことで、設定完了を端末装置３０に伝えることができる。

またユーザは、「キャンセル」ボタンを押すことで、前の設定状態に戻すことができる。本図に示す例では、「非常に高いもの中心に推薦」、「やや高いもの中心に推薦」、「標準」、「やや安いもの中心に推薦」、「非常に安いもの中心に推薦」など、やや抽象的な表現の選択肢が用意されており、推薦情報に優先的に入れる価格帯をユーザが選択できる。選択肢の表現（文言）がやや抽象的であるため、多様なアイテム、カテゴリが提供されている場合でも、同じ操作画面が使えるというメリットがある。

図２２（ｂ）に示す例は、図２２（ａ）に示した例と同じく、推薦結果に入れるアイテムまたはカテゴリの価格を指定するための画面であるが、推薦結果に優先的に入れる中心価格を具体的に指定するものである。具体的な数字が表示されるので、ユーザにとって分かり易いメリットがある。また、中心価格を示す数字をユーザが自由に設定できるようにしてもよい。

図２２（ｃ）に示す例は、推薦結果に入れる価格パターンを指定するための画面である。「高いものを推薦」、「高いものと安いものを両方推薦」、「中程度の価格のものを推薦」、「特定の価格に偏らずに推薦」、「安いものを推薦」などの選択肢が表示される。
ユーザは、図２２に例示した画面で「決定」を選択した後、図２１に示す関連リンク（「関連アイテム表示」ボタンまたは「関連カテゴリ表示」ボタン）を選択することで、価格に関する自分の好みが反映された推薦情報を取得することができる。なお、図２２に示した価格影響度の調整操作用画面は、あくまでも一例であり、他の方法で、価格影響度の調整を行なってもよい。例えば、図１６に示すような価格影響関数のグラフを期間ごとに表示し、ユーザがマウス、タッチパネル等を用いて、グラフの形状を直接指定したり、修正できるようにしてもよい。

図１１のステップＳｌ６０ｂにおいて、端末装置３０は、関連リンクに対応するＵＲＬに推薦リクエストを送信する。この推薦リクエストには、利用主体識別子と、関連アイテムリンクであるか関連カテゴリリンクであるかを示すリンク種別情報とに加えて、図２２に示した画面で指定された価格影響度調整データが含まれている。例えば、設定された期間の数、それぞれの期間の定義情報、図２２に示すラジオボタンの中でユーザに指定されたラジオボタンを識別するための「１」〜「５」などの番号を価格影響度調整データとすることができる。

ステップＳ１７０ｂにおいて、情報選択装置１０ｂの制御部１１０ｂは、送受信部１０９を介して、推薦リクエストを受信し、それに含まれるリクエスト利用主体識別子に対応する表示用推薦データを作成して端末装置３０に送信する。以下では、このステップＳ１７０ｂの処理を詳細に説明する。

ステップＳｌ７０ｂでは、第１実施例の推薦情報作成動作の一部である、図１４に示したステップＳ４１０〜Ｓ４３０に相当する処理（ステップＳ４１０ｂ〜Ｓ４３０ｂ）を行なった後に、図示しないステップＳ４５０で表示用推薦データを作成する。なお、第２のタイミングで推薦情報を作成する場合は、関連集合を作成した後（ステップＳ４００の後）に、ステップＳ４１０ｂ〜４４０ｂを実行すればよい。

ステップＳ４１０ｂにおける価格影響度算出処理を詳細に説明する。制御部１１０ｂは、関連集合格納部１０５の中から、推薦リクエスト（リクエスト利用主体識別子）に一致する利用主体識別子を特定し、その利用主体識別子に対応する関連集合（関連識別子）を読み出す。以下では、ここで読み出された関連集合を集合Ψとする。

そして価格情報格納部１０３を参照しながら、集合Ψの各関連識別子に対応する価格情報を取得し、その価格情報と、受信した価格影響度調整データとを価格影響度算出部１０６ｂに入力する。

第２実施例において、価格影響度算出部１０６ｂは、ユーザによって入力された価格影響度調整データに応じて、価格情報を入力Ｘとし価格影響度を出力Ｙとする価格影響関数Ｆ（Ｘ）の特性を変化させる。本実施形態においては、所定の時点を毎月１日午前０時とし、時間差Ｔｐは、ステップＳ４１０ｂを実行する時点の毎月１日からの経過日数（経過時間）とする。価格影響度算出部１０６ｂは、時間差Ｔｐを算出し、ユーザによって入力された価格影響度調整データの中のどの期間に該当するか判定する。そして、その期間に対応する関数を用いて、価格影響度を算出する。例えば、Ｔｐが１５日であり、期間１が１０日以下、期間２が１０日より大きく３１日以下である場合、期間２の関数を用いる。この関数（対応規則）は、第１実施例と同様に、図１６〜図１８に示したような種々の特性の関数を用いることができる。図２３は、価格影響関数Ｆ（Ｘ）の特性の変化の例を示す図である。

図２３（ａ）は、図２２（ａ）の５つの選択肢に対応する５つの関数の一例を示す図である。本図の関数Ｆａ１〜Ｆａ５の番号は、それぞれ図２２（ａ）の選択肢１）〜５）に対応している。例えば、Ｆａ１（Ｘ）は、選択肢１）に対応する関数である。Ｆａ１（Ｘ）は、Ｘ≦Ｘａ１においてＹ＝Ｙａ、Ｘ＝Ｘｃ１で最大値Ｙｃ、Ｘ≧Ｘｂ１において、Ｙ＝Ｙａとなる関数である。他のＦａ２〜Ｆａ５も同様な特性を持つ関数である。それぞれの関数が最大値（この関数の場合は極大値でもある）となるＸはＸｃ１＜Ｘｃ２＜Ｘｃ３＜Ｘｃ４＜Ｘｃ５であることから明らかなように、関数番号の大きな関数ほど、価格の高いアイテム（カテゴリ）の価格影響度が大きくなるため、価格の高いアイテム（カテゴリ）が推薦情報に入り易くなる。

なお、本図の例では、各関数の出力の最小値はすべてＹａ、最大値はすべてＹｃとしているが、関数ごとに最小値が異なっていてもよいし、関数ごとに最大値が異なっていてもよい。最小値がある程度大きい（０より大きな値の）関数を用いることで、どのような価格のアイテム（カテゴリ）も推薦情報に入る確率を０より大きな値にできるので、推薦情報に入れるアイテム（カテゴリ）の数を十分確保し易いというメリットが得られる。また本図の例のように、関数同士が一部重なっていてもよいし、重なっていなくてもよい。また、同じ形状の関数ではなく、関数番号ごとに関数の形状が異なっていてもよい。

また、図２２（ｂ）に示した価格影響度の調整操作部で指定された価格影響度調整データと、関数Ｆａ１〜Ｆａ５とを対応させることもできる。この場合は、それぞれの関数の最大値をとるＸの値Ｘｃ１〜Ｘｃ５を、図２２（ｂ）の中心価格（５００円、７００円、１０００円、１５００円、２０００円）に対応させればよい。

次に、図２２（ｃ）に示す価格影響度の調整操作部の選択肢と、関数との対応付けの一例を説明する。図２２（ｃ）に示す選択肢のうち、「１）安いものを推薦」、「３）中程度の価格のものを推薦」、「５）高いものを推薦」は、それぞれ図２３（ａ）のＦａ１、Ｆａ３、Ｆａ５を用いればよい。また「４）高いものと安いものを両方推薦」は、図２３（ｂ）のＦａ６に対応させればよい。この関数は、Ｘ≦Ｘａ６、Ｘｂ６≦Ｘ≦Ｘａ７、Ｘｂ７≦ＸでＹ＝Ｙａ、Ｘ＝Ｘｃ６およびＸ＝Ｘｃ７で最大値（極大値）としてＹ＝Ｙｃを取る関数である。Ｘｃ６（安い）とＸｃ７（高い）の２つの価格帯を中心に価格影響度が大きくなる。また、「２）特定の価格に偏らずに推薦」は、図２３（ｂ）のＦａ７に対応させればよい。この関数は、Ｘの値によらずＹが一定値（Ｙｄ）となるため、全ての価格に対して価格影響度が一定となる。このように、出力が一定値となる関数を用いてもよい。

また、対応する調整操作部の選択肢は図示していないが、「１）高いものを極わずかに優先」、「２）高いものを少し優先」、「３）高いものを中程度に優先」、「４）高いものをかなり優先」、「５）高いものを大幅に優先」などの選択肢を用意し、図２３（ｃ）に示す関数Ｆｂ１〜Ｆｂ５に対応させてもよい。これらの関数は、全て単調減少区間を持たないため、価格が高いほど価格影響度が高くなり、価格の高いアイテムほど優先されるが、その優先度合いが関数によって異なる。各関数のカットオフ点（出力が最低値から増加に転じる点）に対応する入力値Ｘαは５つとも同じであるが、そのときの出力値Ｙα（Ｙα１〜Ｙα５）が異なっている。また、飽和点の入力値Ｘβは５つとも同じであるが、出力Ｙβ（Ｙβ１〜Ｙβ５）が異なっている。このため、各関数の単調増加区間の傾きが異なっており、Ｆｂ１の傾きが最も小さく、Ｆｂ５の傾きが最も大きい。これらの関数は、添字が大きい関数ほど、所定の区間における出力最大値と出力最小値との差（出力最小値に対する出力最大値の倍率）が大きくなる傾向を有している。このため、添字の小さい関数を用いると、添字の大きな関数に比べて、推薦情報に価格の安いアイテム（カテゴリ）が入りやすくなる。

図２３に示した関数はあくまでも例示であり、図１８（ａ）に示したような階段状の離散的特性を持つ関数や、図１７に示したような滑らかな関数を用いてもよい。また、ユーザが選択できる価格影響度調整データの種類と、これに対応する関数の種類は、上記の例で示した５種類に限られない。また、期間ごとに選択できる関数は、共通であっても異なっていてもよい。例えば、期間１ではＦｂ１〜Ｆｂ５を選択できるようにし、期間２ではＦａ１〜Ｆａ５を選択できるようにしてもよい。

価格影響度算出部１０６ｂは、Ｆａ１〜Ｆａ７、Ｆｂ１〜Ｆｂ５などの各関数の数式をあらかじめ記憶領域に記憶しておき、入力された価格影響度調整データに応じて該当する数式を選択して、入力Ｘが与えられるごとに、その数式に従って価格影響度を算出することができる。標準的な関数の数式だけを記憶しておき、入力Ｘと価格影響度調整データが与えられるごとに、標準関数の数式を基に他の関数の数式を作成した上で、その数式に従って価格影響度を算出してもよい。関数ごとに入力Ｘに対する出力Ｙをあらかじめ算出しておき、算出結果の（Ｘ，Ｙ）の情報を記憶領域に格納しておいてもよい。以上、第２実施例のステップＳ４１０ｂを説明した。

選択指標算出を行なうステップＳ４２０ｂは、第１実施例のステップＳ４２０とほぼ同じである。ただし、制御部１１０ｂは、ステップＳ４１０ｂで読み出された集合Ψを対象に選択指標の算出を行なうように情報選択部１０７ｂを制御する。

推薦情報を作成するステップＳ４３０ｂにおいて、情報選択部１０７ｂは、ステップＳ４２０ｂで算出された選択指標に基づいて、集合Ψの中から関連識別子を選択する。具体的には、第１実施例で説明した方法を用いればよい。また、選択された関連識別子の選択指標に従って、推薦順位を付与する。そして、利用主体識別子と、関連識別子と、推薦順位とを対応させて、推薦情報テーブル１０８Ａ、１０８Ｂを推薦情報格納部１０８に格納させる。

第２実施例では、ステップＳ４３０ｂに続いて、図１４では図示していないステップＳ４５０を行なう。第２実施例のステップＳ４５０では、第１実施例のステップＳ１７０と同様な処理を行なえばよい。すなわち、制御部１１０ｂは、アイテム属性格納部１０１と推薦情報格納部１０８とを参照しながら、ステップＳ４３０ｂで格納された関連識別子に対応するアイテム属性情報およびカテゴリ属性情報を読み出し、関連アイテム識別子（関連カテゴリ識別子）と、推薦順位と、アイテム属性情報（カテゴリ属性情報）とを対応させた表示用推薦データを作成し、送受信部１０９を介して端末装置３０に送信する。なお、第１実施例で説明したように、推薦順位の高い順に所定個数選択したアイテムのみを表示用推薦データに入れたり、過去の利用回数が所定数以上のアイテムを表示用推薦データに含めない等の処理を行なってもよい。

この表示用推薦データには、ステップＳ１８０において端末装置３０が推薦リストを表示する際に、図２４に示すように、「価格影響度の調整操作」ボタン、「関連アイテム表示」ボタン、「関連カテゴリ表示」ボタンをそれぞれ表示するためのデータを含めてもよい。図２４（ａ）は、「アイテム推薦形式」に対応する処理が行われた場合の画面例であり、図２４（ｂ）は、「カテゴリ推薦形式」に対応する処理が行われた場合の画面例である。

この場合、ユーザは、本図の右上部に示す「価格影響度の調整操作」ボタンを指定して、価格影響度の調整操作を再度行なった後に、本図の下部に示す「関連アイテム表示」または「関連カテゴリ」ボタンを指定することにより、再度設定した価格影響度に応じた新たな推薦情報を表示させることができる。このような方法を用いることで、ユーザは簡単な操作で、納得がいくまで価格影響度を繰り返し調整することができるので、推薦情報に対するユーザの満足度や信頼感を高めることができる。

また、本図の「指定された価格影響度…」で示すように、ステップＳ１４０ｂにおける価格影響度の調整操作でユーザによって指定された内容（選択肢など）を画面に表示するためのデータを、表示用推薦データに含めてもよい。このようにすれば、ユーザが価格影響度の調整操作を繰り返し行なって、少しずつ推薦情報を変更したいような場合に、ユーザは前回指定した条件を容易に知ることができるので、同じ条件を再度指定するような間違いが減り、操作性が向上する。

以上が第２実施例におけるシステム動作の説明である。第２実施例によれば、価格の高いアイテムおよびカテゴリを推薦情報に多く入れることが可能である等、第１実施例と同様な効果を得ることができる。さらに第２実施例では、それらの効果に加えて、端末装置３０を利用するユーザが自分の好みに応じて、期間別に推薦結果に多く含まれるアイテム（またはカテゴリ）の価格帯を調整することができるので、ユーザが推薦情報を納得して受け入れやすくなる。

例えば、毎月１日に新しいポイント（新たなアイテム利用権）が付与された直後に、予定以上に高額の商品を購入してしまう傾向があると自覚しているユーザ（ユーザＡ）は、毎月上旬に安いもの中心に推薦されるようにあらかじめ設定しておけば、安心してサービスを利用することができる。また、毎月月末までにポイントを使い切れずに、ポイントを失効させてしまうこケースが多いと自覚しているユーザ（ユーザＢ）は、毎月下旬に高いもの中心に推薦されるように設定しておけば、安心してサービスを利用することができる。このように、ユーザの利便性や納得感が向上するため、推薦情報に基づくアイテム利用が活発になり、アイテム提供サービスの売上をさらに増大させることが期待できる。
（実施例３）

本実施形態に係るネットワークシステムの第３実施例について説明する。第３実施例では、端末装置３０を利用するユーザが過去に利用したアイテムの価格に基づいて、価格影響度を算出する関数の特性をユーザごとに変えることができるようになっている。第３実施例において、アイテム提供サーバ２０および端末装置３０は、第１実施例と同様とすることができる。

図２５は、第３実施例における情報選択装置１０ｃの構成を示すブロック図である。本図に示すように、情報選択装置１０ｃは、アイテム属性格納部１０１と、利用履歴格納部１０２と、価格情報格納部１０３と、関連度算出部１０４と、関連集合格納部１０５と、価格影響度算出部１０６ｃと、情報選択部１０７ｃと、推薦情報格納部１０８と、送受信部１０９と、制御部１１０ｃと、利用価格情報算出部１１１と、利用価格情報格納部１１２とを備えて構成されている。また、情報選択装置１０ｃには、情報選択装置１０の管理者向けに必要な情報を表示するための表示装置１２０と、管理者が操作を行なうためのキーボード、マウス等の入力装置１３０とが接続されている。

すなわち、第３実施例の情報選択装置１０ｃは、第１実施例の情報選択装置１０に利用価格情報算出部１１１および利用価格情報格納部１１２を追加し、価格影響度算出部１０６、情報選択部１０７、制御部１１０の動作が一部異なる構成となっている。

制御部１１０ｃは、第１実施例と同様に、所定のタイミングで推薦情報作成動作を開始する。ただし本実施形態では、図１４のフローチャートにおいてステップＳ４００の後に、図示しないステップＳ４１５を実行し、ステップＳ４１５が終了した段階で推薦情報作成動作を終了する。価格影響度算出を行なうステップＳ４１０以降に相当する処理は、後述するステップＳ１７０ｃにおいて、表示用推薦データを作成する際に行なう。

ステップＳ４１５において、制御部１１０ｃの指示を受けた利用価格情報算出部１１１は、利用履歴格納部１０２を参照しながら、ユーザが利用したアイテムの価格に関する情報である利用価格情報を、所定の時点と推薦情報の作成に係る時点との時間差、または所定の時点と推薦情報の提供に係る時点との時間差Ｔｐに応じた期間ごと、およびユーザごとに算出する。利用価格情報は、ユーザが利用したアイテムの価格に関する統計量である。

本実施形態では、月額課金制度を採用するアイテム利用サービスにおいて、新規のアイテム利用権（新規ポイント）が毎月１日午前０時にユーザに付与されるものとし、毎月１日午前０時を所定の時点とする。そして、推薦情報の作成に係る時点との時間差Ｔｐを、月の上旬（例えば、１日から１０日まで）、中旬（例えば、１１日から２０日まで）、下旬（例えば、２１日以降）に対応する３つの期間に分ける例を用いて説明する。また、本実施形態では、利用履歴格納部１０２には、図５（ｂ）に示すアイテム利用履歴テーブル１０２Ａ−２が格納されているものとする。すなわち、アイテム利用時期情報(アイテムがユーザに提供された日時などの時点を示す情報）がアイテム利用履歴に含まれている。なお、利用価格情報における利用は、情報閲覧、視聴等を含めずに、実際に購入した場合とすることが望ましい。

利用価格情報算出部１１１は、期間１（毎月１日から１０日まで）、期間２（毎月１１日から２０日まで）、期間３（毎月２１日以降）ごとに、ユーザの利用価格情報を算出する。利用価格情報として、例えば、ユーザが過去に利用したアイテムの価格の高さを指標化した価格水準値と、ユーザの利用したアイテムの価格のばらつき度合いを指標化した価格分散値とを用いることができる。ここでは、利用価格情報算出部１１１は、以下に示す第１〜第６の利用価格情報のうち、１つ以上の値を算出するものとする。以下では１つの期間（例えば、上旬に該当する期間１）の処理を説明するが、他の期間についても同様である。また、もちろん３つ以外の期間を用いてもよいし、１ヶ月とは異なる周期を用いてもよい。

利用価格情報算出部１１１は、利用履歴格納部１０２に格納された利用履歴から、利用時期情報が特定の条件を満たす利用履歴を読み出す。例えば、利用時期情報の日付が１日から１０日に該当するデータを上旬用の利用価格情報を算出するためのデータとして読み出す。そして、読み出した利用履歴に含まれる利用主体識別子ごとに、その期間の利用価格情報を算出する。なお、利用価格情報を算出する際に、推薦情報を作成する当月の利用履歴を用いてもよいし、用いなくてもよい。例えば、２０１２年１２月１０日に推薦情報を作成する場合、期間１（毎月１日から１０日まで）の利用価格情報を算出するために、前月までの期間１に相当する２ヶ月分のデータ、すなわち、アイテム利用時期情報が、「２０１２年１０月１日〜１０月１０日」および「２０１２年１１月１日〜１１月１０日」の範囲にある利用履歴を用いてもよい。あるいは、これらに加えて、当月の「２０１２年１２月１日〜１２月９日」の利用履歴を用いてもよい。あるいは、前月までのデータを使わずに、当月の「２０１２年１２月１日〜１２月９日」である利用履歴のみ用いてもよい。

なお、アイテム利用時期が「２０１２年１０月１日〜１０月１０日」の範囲にある利用履歴を期間１に対応させる処理は、所定の時点（２０１２年１２月１日）から所定の時間（２ヶ月）遡った時点（２０１２年１０月１日）を起点とし、その起点からアイテム利用時期との時間が所定値（１０日）以下である利用履歴を期間１に対応させる処理ともいえる。アイテム利用時期が「２０１２年１１月１日〜１１月１０日」の範囲にある利用履歴を期間１に対応させる処理は、起点を２０１２年１１月１日にした同様の処理であり、「２０１２年１２月１日〜１２月９日」の範囲にある利用履歴を期間１に対応させる処理は、起点を所定の時点（２０１２年１２月１日）にした同様の処理といえる。

第１の利用価格情報である第１の価格水準値は、ユーザの利用したアイテムの価格の合計値（合計額）を価格水準値とするものである。第１の価格水準値を算出する場合、利用価格情報算出部１１１は、読み出した利用履歴を参照しながら、ある利用主体識別子（あるユーザ）が利用したアイテムを特定する。そして、価格情報格納部１０３を参照しながら、特定したアイテムの価格の合計値を算出し、その利用主体識別子に対応する第１の価格水準値とする。第１の価格水準値が大きいユーザは、購買能力の高いユーザと推測できる。なお、合計値そのものではなく、合計値に所定の値を乗じた値や、合計値を所定の値で割った値を第１の価格水準値としてもよい。例えば、合計値の桁数が大きくなるような場合に、所定の値で割って扱いやすい桁数の値にしたり、各々の利用価格情報の最大値が「１」になるような正規化を行なってもよい。また、会員期間が異なるユーザの合計値は大きく異なる場合があるので（例えば、会員期間が１ヶ月のユーザと５年間のユーザ）、価格の合計値をそれぞれのユーザの会員期間に応じた長さで割って正規化を行ってもよい。

第２の利用価格情報である第２の価格水準値は、ユーザの利用したアイテム１つあたりの価格の高さを示す値（代表値）を用いたものである。第２の価格水準値を算出する場合、利用価格情報算出部１１１は、読み出した利用履歴を参照しながら、ある利用主体識別子（あるユーザ）が利用したアイテムを特定する。そして、価格情報格納部１０３を参照しながら、特定したアイテムの価格の分布を求め、その代表値を算出し、その利用主体識別子に対応する第２の価格水準値とする。代表値としては、平均値、中央値、最頻度、四分位値、最大値、最小値などを用いることができる。また、利用回数の多いアイテムに大きな重みを付ける等、利用回数に応じた重みづけ行なって代表値を算出してもよい。

第２の価格水準値が大きいユーザは、高額アイテムや高級アイテムを好むユーザと推測できる。また、第２の価格水準値は、アイテムの価格が広い範囲に分布している場合に適している。

第３の利用価格情報である第１の価格分散値は、ユーザの利用したアイテム１つあたりの価格のばらつきの大きさ（ばらつき度）を示す値を価格分散値とするものである。第１の価格分散値を算出する場合、利用価格情報算出部１１１は、読み出した利用履歴を参照しながら、ある利用主体識別子（あるユーザ）が利用したアイテムを特定する。そして、価格情報格納部１０３を参照しながら、特定したアイテムの価格の分布を求め、そのばらつき度を示す値を算出し、その利用主体識別子に対応する第１の価格分散値とする。具体的には、ばらつき度を示す値として、分散、標準偏差、範囲（最大値−最小値）、四分位範囲（第３四分位値−第１四分位値）などを用いることができる。

第１の価格分散値が大きいユーザは、様々な価格のアイテムを利用するユーザと推測できる。また、第１の価格分散値は、アイテムの価格が広い範囲に分布している場合に適している。

上述した方法では、ある利用主体識別子（あるユーザ）が利用したアイテム（あるユーザの利用履歴）のみを用いて、第１〜第３の利用価格情報を算出するが、あるユーザおよび他のユーザの利用履歴を用いて算出してもよい。すなわち、あるユーザ（ユーザＡ）以外のユーザが利用したアイテムの価格に基づいて、ユーザＡの利用価格情報を算出してもよい。

例えば、利用価格情報算出部１１１が利用履歴格納部１０２から読み出した利用履歴に、Ｎｕ人の利用主体識別子が含まれているとして、利用主体識別子ごとにアイテム価格の合計値Ｐｓ［ｕ］（ｕ＝１〜Ｎｕ）を算出し、Ｐｓ［ｕ］の平均値Ｐａと標準偏差Ｐｂとを算出する。そして［数８］に従ってユーザｕの標準得点Ｓ［ｕ］、または偏差値等を算出し、第４の利用価格情報として用いることができる。

この第４の利用価格情報は、あるユーザ（ユーザｕ）が利用したアイテム価格の合計値が、ユーザ集団の中でどの位置にあるかを相対的に示す情報である。第２〜第３の利用価格情報についても、同様にユーザ集団の中での相対値を算出することができる。また、上述の利用価格情報それぞれについて、最大値を１、最小値を０にする等の正規化処理を行ってもよい。

また利用価格情報算出部１１１は、ある利用主体識別子に対して、アイテム区分ごとに利用価格情報を算出してもよい。ここで、アイテム区分とは、アイテムを所定の基準で分類した情報であり、通常はカテゴリよりも上位の概念の分類である。例えば、アイテム提供サービスにおいて、種々のコンテンツを提供する場合、「音楽」「映画」「書籍」といった上位の階層の分類をアイテム区分とし、アイテム区分が「音楽」のアイテムに対しては、「ロック」「ジャズ」「クラシック」「フォーク」等のジャンル情報をカテゴリとすることができる。アイテム区分が「映画」のアイテムに対しては、「ＳＦ」「アクション」「コメディ」「アニメ」「サスペンス」等のジャンル情報をカテゴリとすればよい。

この場合は、アイテム属性格納部１０１に、各アイテムまたは各カテゴリと、各アイテム区分とを対応させたアイテム区分情報を格納しておく。そして、利用価格情報算出部１１１はアイテム区分情報を参照しながら、ユーザが利用したアイテムのアイテム区分を特定し、アイテム区分ごとに利用価格情報を算出する。上記の例では、「音楽」に対応する利用価格情報と、「映画」に対応する利用価格情報と、「書籍」に対応する利用価格情報とを算出する。ただし、カテゴリをそのままアイテム区分とするようにしてもよい。

利用価格情報算出部１１１は、算出した利用価格情報を利用価格情報格納部１１２に格納させる。利用価格情報格納部１１２は、図２６に示すような形式で、利用主体識別子と、利用価格情報とを対応させて、期間（期間１、期間２、期間３）ごとに格納する。図２６（ａ）は、アイテム区分を用いない場合の格納形式である利用価格情報テーブル１１２Ａを示している。複数種類（Ｎｐ個）の利用価格情報が格納されているが、１種類の利用価格情報を格納するようにしてもよい。本図における「ＮＵＬＬ」は、該当するデータが存在しないことを示すものである。例えば、期間３において、「ＵｓｅｒＩＤ−２」の行は、利用履歴が全く、あるいは十分な量が存在しないため、利用価格情報が存在しない。このように、一部の期間の利用価格情報が欠落している利用主体識別子が存在していてもよい。

利用価格情報が存在しない場合は、その期間のユーザ全体の平均的な利用価格情報を用いてもよいし、その利用主体識別子に関する他の期間の利用価格情報で代用してもよい。また、他のユーザの利用価格情報を用いて、欠落している情報を埋めてもよい。具体的には、「ＵｓｅｒＩＤ−２」の利用価格情報が存在する期間１と期間２において、「ＵｓｅｒＩＤ−２」の利用価格情報と類似する利用価格情報を持つ他のユーザを特定し、そのユーザの期間３における利用価格情報を用いて、期間３における「ＵｓｅｒＩＤ−２」の利用価格情報を算出してもよい。例えば、期間１と期間２において、「ＵｓｅｒＩＤ−２」と利用価格情報がほぼ同じであるユーザとして、「ＵｓｅｒＩＤ−５」と「ＵｓｅｒＩＤ−６」（図示せず）を特定した場合、期間３において、これら２人のユーザの利用価格情報の平均値を「ＵｓｅｒＩＤ−２」の利用価格情報として算出してもよい。

図２６（ｂ）は、アイテム区分を用いる場合の格納形式である利用価格情報テーブル１１２Ｂを示している。アイテム区分１に対応するＮｐ１個の利用価格情報と、アイテム区分２に対応するＮｐ２個の利用価格情報を、期間（期間１、期間２、期間３）ごとに格納している。ここで、Ｎｐ１≠Ｎｐ２として、アイテム区分ごとに異なる数の利用価格情報を算出して格納するようにしてもよい。以上がステップＳ４１５の説明である。

第３実施例におけるシステム全体の動作は、処理ステップ間の関係において図１１に示したフローチャートと同様であり、ステップＳ１６０とＳ１７０の具体的内容において第１実施例と一部異なる。第３実施例におけるこれらの処理ステップは、末尾に「ｃ」を付加して表記する。

ステップＳｌ６０ｃにおいて、端末装置３０は、関連リンクに対応するＵＲＬに推薦リクエストを送信する。ステップＳ１７０ｃにおいて、情報選択装置１０ｃの制御部１１０ｃは、送受信部１０９を介して、推薦リクエストを受信し、それに含まれるリクエスト利用主体識別子に対応する表示用推薦データを作成して端末装置３０に送信する。以下では、このステップＳ１７０ｃの処理を詳細に説明する。

ステップＳｌ７０ｃでは、第１実施例の推薦情報作成動作の一部である、図１４に示したステップＳ４１０〜Ｓ４３０に相当する処理（ステップＳ４１０ｃ、Ｓ４２０ｃ、Ｓ４３０ｃ）を行なった後に、図示しないステップＳ４５０で表示用推薦データを作成する。なお、第２のタイミングで推薦情報を作成する場合は、利用価格情報を算出した後（ステップＳ４１５の後）にステップＳ４１０ｃ〜４４０ｃを実行すればよい。このうち、ステップＳ４２０ｃ、Ｓ４３０ｃ、Ｓ４５０は、それぞれ第２実施例のステップＳ４２０ｂ、Ｓ４３０ｂ、Ｓ４５０と同じであるため説明を省略し、ステップＳ４１０ｃにおける価格影響度算出処理について詳細に説明する。

制御部１１０ｃは、関連集合格納部１０５の中から、推薦リクエスト（リクエスト利用主体識別子）に一致する利用主体識別子を特定し、その利用主体識別子に対応する関連集合（関連識別子）を読み出す。以下では、ここで読み出され関連集合を集合Ψとする。

そして、制御部１１０ｃは、価格情報格納部１０３を参照しながら、集合Ψの各関連識別子に対応する価格情報を取得し、その価格情報と、受信した利用リクエストの利用主体識別子とを価格影響度算出部１０６ｃに入力する。利用価格情報格納部１１２に、図２５（ｂ）に示したアイテム区分ごとに利用価格情報が格納されている利用価格情報テーブル１１２Ｂを格納している場合には、制御部１１０ｃは、アイテム属性格納部１０１のアイテム情報テーブル１０１Ａを参照しながら、関連識別子に対応するアイテム区分を特定し、そのアイテム区分も加えて価格影響度算出部１０６ｃに入力する。

価格影響度算出部１０６ｃは、利用価格情報格納部１１２を参照しながら、入力された利用主体識別子に応じて、価格情報を入力Ｘとし価格影響度を出力Ｙとする価格影響関数Ｆ（Ｘ）の特性を変える。この関数（対応規則）は、第１実施例と同様に、図１６〜図１８、および図２３に示したような種々の特性の関数を用いることができる。

価格影響度算出部１０６ｃは、実施例１と同様に、所定の時点と推薦情報の作成に係る時点との時間差、または所定の時点と推薦情報の提供に係る時点との時間差Ｔｐを算出する。本実施形態においては、所定の時点は毎月１日の午前０時であり、そこからの経過日数（経過時間）が時間差Ｔｐとなる。また、月を３つの期間に分けて処理を行うので、算出したＴｐが３つのうちのどの期間に該当するか判定する。そして価格影響度算出部１０６ｃは、入力された利用主体識別子に対応し、かつ時間差Ｔｐに該当する期間に対応する利用価格情報を利用価格情報格納部１１２から読み出す。利用価格情報格納部１１２に、図２６（ｂ）に示した利用価格情報テーブル１１２Ｂを格納している場合には、入力された利用主体識別子に対応し、かつ時間差Ｔｐに該当する期間に対応し、かつ入力されたアイテム区分に対応する利用価格情報を読み出す。

ここでは、利用価格情報格納部１１２に、ユーザｕの価格水準値Ｌ［ｕ］が１つ、ユーザｕの価格分散値Ｖ［ｕ］が１つ格納されており、これらを読み出して利用することとする。ただし、価格水準値と価格分散値のどちらか一方を利用してもよいし、３つ以上の利用価格情報を利用して関数Ｆ（Ｘ）の特性を決定してもよい。

上述のように、図２３（ａ）は、Ｆａ１（Ｘ）〜Ｆａ５（Ｘ）（Ｆａ１〜Ｆａ５）の５つの関数を示している。添字番号の大きい関数ほど、出力値が極大となるときの入力値（Ｘｃ１、Ｘｃ５等）が大きい。また、添字番号の大きい関数ほど、所定の出力値（例えば、最大値Ｙｃ、あるいはその半分の値Ｙｃ／２）を得るための入力値が大きいともいえる。価格影響度算出部１０６ｃは、ユーザｕの価格水準値Ｌ［ｕ］に応じて、いずれかの関数を選択する。

具体的には、時間差Ｔｐに該当する期間（当該期間）の価格水準値Ｌ［ｕ］に関する閾値δ１〜δ４（δ１＜δ２＜δ３＜δ４）を用意しておき、Ｌ［ｕ］＜δ１であればＦａ１、δ１≦Ｌ［ｕ］＜δ２であればＦａ２、δ２≦Ｌ［ｕ］＜δ３であればＦａ３、δ３≦Ｌ［ｕ］＜δ４であればＦａ４、δ４≦Ｌ［ｕ］であればＦａ５を選択する。すなわち、価格水準値Ｌ［ｕ］に応じて、関数がピーク（極大値）をとる位置（Ｘ座標）を変化させているといえる。また、価格水準値Ｌ［ｕ］が大きいほど、所定の出力値を得るための入力値が大きくなる傾向で価格影響関数を変化させているともいえる。

この結果、価格水準値の大きいユーザ、すなわち購買能力の高いユーザに対しては、主に価格の高いアイテム（カテゴリ）が推薦され、、価格水準値の小さいユーザに対しては、主に価格の安いアイテム（カテゴリ）が推薦される。なお、価格水準値として、第２の価格水準値（ユーザの利用したアイテム１つあたりの価格の代表値）を用い、閾値δ１〜δ４と、関数Ｆａ１〜Ｆａ５の各ピークのＸ座標であるＸｃ１〜Ｘｃ５とが、所定の関係になるように設定してもよい。例えば、Ｆａ２に対応する閾値δ１およびδ２の平均値δｍ２｛δｍ２＝（δ１＋δ２）／２｝と、Ｆａ２のピークのＸ座標であるＸｃ２が、ほぼ同じ値（δｍ２≒Ｘｃ２）となるようにしてもよい。このようにすると、ユーザが日頃よく利用する価格帯のアイテムが推薦され、ユーザに違和感を与えるリスクが少ない。また、δｍ２よりＸｃ２を大きくしてもよい（δｍ２＜Ｘｃ２）。このようにすると、ユーザが日頃よく利用する価格帯よりも高い価格帯のアイテムが推薦されるので、ユーザの平均利用単価の増大が期待できる。また逆に、δｍ２よりＸｃ２を小さくしてもよい（δｍ２＞Ｘｃ２）。このようにすると、ユーザのアイテム利用意欲の増大が期待できる。

別の選択方法を、図２３（ｃ）を参照して説明する。本図は、Ｆｂ１（Ｘ）〜Ｆｂ５（Ｘ）（Ｆｂ１〜Ｆｂ５）の５つの関数を示しており、添字番号の大きい関数ほど、最大値Ｙβと最小値Ｙαとの差（最小値Ｙαに対する最大値Ｙβの倍率）が大きく、添字の小さい関数ほど、その差および倍率が小さくなっている。また、これらの関数は単調減少区間を持たない。

価格水準値Ｌ［ｕ］に関する閾値δ１〜δ４（δ１＜δ２＜δ３＜δ４）を用意しておき、Ｌ［ｕ］＜δ１であればＦｂ１、δ１≦Ｌ［ｕ］＜δ２であればＦｂ２、δ２≦Ｌ［ｕ］＜δ３であればＦｂ３、δ３≦Ｌ［ｕ］＜δ４であればＦｂ４、δ４≦Ｌ［ｕ］であればＦｂ５を選択する。すなわち、価格水準値Ｌ［ｕ］が大きいほど添字番号の大きい関数を選択することにより、価格水準値が大きいほど、出力最大値と出力最小値との差（出力最小値に対する出力最大値の倍率）が大きくなる傾向で価格影響関数を変化させているといえる。また、価格水準値が大きいほど、入力が最小値であるときの出力値（Ｘ＝０のときの出力値）が小さくなる傾向で価格影響関数を変化させているともいえる。この結果、価格水準値が大きいユーザでは、価格の高いアイテム（カテゴリ）が非常に推薦情報に入り易くなるのに対し、価格水準値が小さいユーザでは、価格の高いアイテム（カテゴリ）がやや優先的ではあるものの、価格の安いアイテム（カテゴリ）も比較的推薦結果に入りやすいという効果が得られる。

このように、単調減少区間を持たない関数を用いると、全てのユーザに対して、価格の高いアイテムを優先的に推薦情報に入れることができると同時に、ユーザの利用価格情報（すなわちユーザの利用状況）に応じて、その優先度合いを適応的に設定することができる。なお、複数の関数（例えば、Ｆｂ１〜Ｆｂ５）を用意するのではなく、１つの関数のみを用意し、価格水準値に応じて、その関数を変形して用いるようにしてもよい。例えば、Ｆｂ３（Ｘ）を用意し、価格水準値Ｌ［ｕ］と乗算した関数（値）（Ｆｂ３（Ｘ）×Ｌ［ｕ］）を価格影響度としてもよい。また、価格水準値に応じて、用意した関数の最大値および最小値のうちの少なくとも一方を変更してもよい。また、価格水準値Ｌ［ｕ］とは別に、価格水準値Ｌ［ｕ］が大きいほど大きな値となる係数Ｋ［ｕ］を算出し、用意した関数との乗算を行って、価格影響度を算出してもよい。価格水準値Ｌ［ｕ］と係数Ｋ［ｕ］との関係は、線形でも非線形でもよい。

また、価格水準値Ｌ［ｕ］ではなく、ユーザｕの価格分散値Ｖ［ｕ］を用いて、Ｆｂ１〜Ｆｂ５を選択してもよい。価格水準値Ｌ［ｕ］の場合と同様に、価格分散値Ｖ［ｕ］に関する閾値ε１〜ε４（ε１＜ε２＜ε３＜ε４）を用意しておき、価格分散値Ｖ［ｕ］が大きいほど添字番号の大きい関数を選択する。すなわち、価格分散値が大きいほど、出力最大値と出力最小値との差（出力最小値に対する出力最大値の倍率）が大きくなる傾向で価格影響関数を変化させてもよい。

一般に、価格分散値が小さなユーザは、限られた価格帯のアイテムを利用する傾向がある。すなわち、自分なりの利用パターンが確立しているユーザであるといえる。このようなユーザでは、価格の高いアイテムだけを推薦した場合に受容されないリスクがより高いため、価格水準値を用いず、価格分散値のみで、単調減少区間を持たない価格影響関数を設定する場合は、関数Ｆｂ１などを用いて、価格の高いアイテムと安いアイテムとの価格影響度の差があまり大きくないようにし、価格の安いアイテム（カテゴリ）も比較的推薦結果に入りやすいようにする。

次に、ユーザｕの価格水準値Ｌ［ｕ］と価格分散値Ｖ［ｕ］を両方用いて、関数Ｆ（Ｘ）の特性を動的に設定する方法を説明する。以下では、時間差Ｔｐに応じて、複数種類のひな型関数を使い分ける例を説明するが、もちろん１種類のひな型関数を用いてもよい。価格影響度算出部１０６ｃは、時間差Ｔｐが期間１（月の上旬）に該当する場合に、図２７（ａ）に示す特性のひな型関数Ｆｕ（Ｘ）を用いる。本実施形態では、毎月１日にユーザに新規のアイテム利用権が付与されるサービスを例に説明しているが、新規のアイテム利用権が付与されてから間もない月の上旬は、一般的にユーザのアイテム利用意欲が高いため、高いアイテムを推薦しても、ユーザのアイテム利用意欲が低下するリスクが小さい考えられる。そこで、図２７（ａ）に示すような単調減少区間を持たないひな型関数を用いて、価格が高いほど価格影響度が大きくなるようにすると、サービス全体の売上増大に効果的である。価格影響度算出部１０６ｃは、このようなひな型関数の数式を内部の記憶領域に記憶しており、価格水準値Ｌ［ｕ］および価格分散値Ｖ［ｕ］に応じて、Ｆｕ（Ｘ）のパラメータＸｃ、Ｘω、Ｙα、Ｙωを設定し、価格影響度を算出する。ここで、Ｘｃは単調増加区間のＸ方向（Ｘα〜Ｘβ）の中点であり、Ｘωは単調増加区間のＸ方向の幅である。また、Ｙαは単調増加区間の最小出力値であり、Ｙωは単調増加区間のＹ方向の幅である。

まず、Ｘｃを価格水準値Ｌ［ｕ］が大きいほど大きな値となるように設定する。そして、Ｘωを価格分散値Ｖ［ｕ］が大きいほど大きな値となるように設定する。この結果、単調増加区間の最小入力値Ｘαと最大入力値Ｘβとが設定される。

次に、Ｙαを価格水準値Ｌ［ｕ］が小さいほど大きな値となるように設定する。そして、Ｙωを価格水準値Ｌ［ｕ］が大きいほど大きな値となるように設定する。この結果、単調増加区間の最大出力値Ｙβが設定される。

このようにパラメータが設定された関数Ｆｕ（Ｘ）の特性について、図２７（ｂ）および図２７（ｃ）を参照し、ユーザｕ１〜ユーザｕ５の５人のユーザを例にして説明する。

ユーザｕ１は、価格の安いアイテムのみを利用するため、ユーザｕ１の価格水準値Ｌ［ｕ１］が５人のユーザの中で最も小さく、価格分散値Ｖ［ｕ１］も小さいものとする。図２７（ｂ）に示すように、ユーザｕ１に対応した関数Ｆｕ１（Ｘ）は、Ｘｃ１、Ｘα１、Ｘβ１、Ｘω１、Ｙω１が小さく、Ｙα１が大きい。このため、価格の安いアイテムと価格の高いアイテムとの価格影響度の差（倍率）が小さい等により、５人のユーザの中で価格の安いアイテムが最も推薦結果に入りやすくなる。

ユーザｕ２は、価格の安いアイテムと高いアイテムの両方を利用するが、安いアイテムをより多く利用するため、価格水準値Ｌ［ｕ２］が５人の中で２番目に小さく、価格分散値Ｖ［ｕ２］は大きいものとする。図２７（ｂ）に示すように、ユーザｕ２に対応する関数Ｆｕ２（Ｘ）のパラメータであるＸｃ２、Ｘω２、Ｙα２、Ｙω２は、それぞれＸｃ１＜Ｘｃ２、Ｘω１＜Ｘω２、Ｙα２＜Ｙα１、Ｙω１＜Ｙω２となる。このため、価格の安いアイテムと価格の高いアイテムとの価格影響度の差（倍率）がＦｕ１より大きくなり、ユーザｕ１に比べると、価格の安いアイテムが推薦結果に入りにくくなる。また、単調増加区間の幅Ｘω２が大きく、単調増加区間の勾配が比較的緩やかであるため、幅広い価格帯のアイテムが推薦結果に入り易くなる。ユーザｕ２は、価格の安いアイテムと高いアイテムの両方を利用するユーザであるため、アイテム価格に関するユーザの日頃の利用傾向を反映した推薦情報が得られるといえる。

ユーザｕ３は、価格が中程度のアイテムのみ利用するため、価格水準値Ｌ［ｕ３］は、ユーザｕ２の価格水準値Ｌ［ｕ２］と同じであり、価格分散値Ｖ［ｕ３］は、ユーザｕ２よりも小さいものとする。図２７（ｂ）に示すように、ユーザｕ３に対応する関数Ｆｕ３（Ｘ）のパラメータであるＸｃ３、Ｘω３、Ｙα３、Ｙω３は、それぞれＸｃ２＝Ｘｃ３、Ｘω３＜Ｘω２、Ｙα２＝Ｙα３、Ｙω２＝Ｙω３となる。このため、関数Ｆｕ２よりも出力値が大きくなる価格帯（線分Ｐ１で示す価格帯）のアイテムが、ユーザｕ２と比べて推薦結果に入りやすくなる。

また、ユーザｕ２では、関数Ｆｕ３が最大値となり、かつ関数Ｆｕ２が単調増加である価格帯（線分Ｐ２で示す価格帯）のアイテムは、それより高い価格帯（線分Ｐ３で示す価格帯）のアイテムより、推薦結果に入りにくいのに対し、ユーザｕ３では同程度に入るようになる。

元々利用している価格帯が狭いユーザｕ３には、高い価格帯Ｐ３に偏って推薦するよりも、それより若干安い価格帯Ｐ２を含めて推薦した方が、推薦結果が受容される可能性が高いと考えられる。一方で、元々幅広い価格帯のアイテムを利用しているユーザｕ２は、ユーザｕ３に比べて、特定の価格帯へのこだわりが少なく、高い価格帯Ｐ３を受容する可能性が高いので、価格帯Ｐ２よりも価格帯Ｐ３をより多く推薦結果に入れた方が、アイテム提供サービスの売上増大という点で効果的である。このように第３実施例では、価格分散値に応じて単調増加区間の幅を設定することにより、価格水準値が同程度のユーザに対しても、推薦情報の内容を適切に変えることができる。

ユーザｕ４は、価格の安いアイテムと高いアイテムの両方を利用するが、高いアイテムをより多く利用するため、価格水準値Ｌ［ｕ４］が５人のユーザの中で２番目に大きく、価格分散値Ｖ［ｕ４］は、ユーザｕ２と同程度に大きいものとする。図２７（ｃ）に示すように、ユーザｕ４に対応する関数Ｆｕ４（Ｘ）のパラメータであるＸｃ４、Ｙα４、Ｘω４、Ｙω４は、それぞれＸｃ２＜Ｘｃ４、Ｘω１＜Ｘω２≒Ｘω４、Ｙα４＜Ｙα２、Ｙω２＜Ｙω４となる。このため、価格の安いアイテムと価格の高いアイテムとの価格影響度の差（倍率）が関数Ｆｕ２より大きくなり、ユーザｕ２に比べると、価格の安いアイテムが推薦結果に入りにくくなる。

ユーザｕ５は、価格の高いアイテムのみを利用するため、価格水準値Ｌ［ｕ５］が５人のユーザの中で最も大きく、価格分散値Ｖ［ｕ５］は、ユーザｕ１と同程度に小さいものとする。図２７（ｃ）に示すように、ユーザｕ５に対応する関数Ｆｕ５（Ｘ）のパラメータであるＸｃ５、Ｙα５、Ｘω５、Ｙω５は、それぞれＸｃ５＜Ｘｃ４、Ｘω１≒Ｘω５＜Ｘω４、Ｙα５＜Ｙα４、Ｙω４＜Ｙω５となる。このため、価格の安いアイテムと価格の高いアイテムとの価格影響度の差（倍率）が非常に大きくなり、価格の安いアイテムが５人のユーザの中で最も推薦結果に入りにくくなる。また、価格水準値の最も小さいユーザｕ１に対応する関数Ｆｕ１（Ｘ）と比べると、Ｘα１＜＜Ｘα５、Ｘβ１＜＜Ｘβ５、Ｙα１＞＞Ｙα５、Ｙβ１＜＜Ｙβ５であり、価格水準値の小さいユーザに比べて、価格の高いアイテムが推薦結果に入りやすいことは明らかである。

なお、図２７で説明に用いた関数Ｆｕ（Ｘ）は、あくまでも一例であり、他の特性の関数を用いてもよい。例えば、図２８に示す特性の関数Ｆｇ（Ｘ）を用いて価格影響度を算出してもよい。この場合は、Ｆｕ（Ｘ）と同様な方法で、関数Ｆｇ（Ｘ）のパラメータＸｃ、Ｘω、Ｙα、Ｙωを設定する他、価格水準値が小さければ、本図の関数Ｆｇ１のように上に凸の度合いが強い特性とし、価格水準値が中程度であれば、本図の関数Ｆｇ２のように線形に近い特性とし、価格水準値が大きければ、本図の関数Ｆｇ３のように下に凸の度合いが強い特性とする。下にと凸の度合いが強いほど、所定の出力値を得るために大きな入力値が必要といえる。また、価格分散値が大きいほど、下に凸の度合いを強くしてもよい。

次に、時間差Ｔｐが期間２（月の中旬）に該当する場合に、価格影響度算出部１０６ｃは、図２９に示す特性のひな型関数Ｆｖ（Ｘ）を用いる。新規のアイテム利用権が付与されてからある程度時間が経過している中旬は、一般的にユーザのアイテム利用意欲が上旬よりも低下している。このため、図２９に示すように、ピーク（極大値）を持つ関数を用いて、価格の高いアイテム（カテゴリ）が必ずしも優先的に推薦されないようにする。

まず、価格水準値Ｌ［ｕ］が大きいほど、ピーク中心のＸ座標であるＸｃが大きな値となるように設定する。そして、価格分散値Ｖ［ｕ］が大きいほど、ピークのＸ方向の幅であるＸωが大きくなるように設定する。このように価格影響関数を設定すると、価格水準値が大きいユーザには、主に高いアイテム（カテゴリ）が推薦される一方、価格水準値が小さいユーザには、主に安いアイテム（カテゴリ）が推薦される。また、価格分散値が大きいユーザには、幅広い価格帯のアイテム（カテゴリ）が推薦され易くなるが、価格分散値が小さいユーザには、特定の狭い価格帯のアイテム（カテゴリ）が推薦される。すなわち、それぞれのユーザのアイテム利用パターンとほぼ同じ価格条件のアイテムが推薦される。ユーザが日頃利用しない価格帯のアイテムが推薦され難いため、ユーザのアイテム利用意欲の低下リスクを非常に小さくすることができる。

例えば、上述の５人のユーザのうち、価格水準値が小さく、価格分散値Ｖも小さいユーザｕ１では、Ｘｃ、Ｘωが両方とも小さくなるので、価格の安いアイテムのみ推薦される。また、価格水準値が中程度で、価格分散値Ｖが大きいユーザｕ２では、Ｘｃが中程度で、Ｘωが大きくなるので、中程度の価格のアイテムを中心に、幅広い価格帯のアイテムが推薦されることになる。また、価格水準値が中程度で、価格分散値が小さいユーザｕ３では、Ｘｃが中程度で、Ｘωが小さくなるので、中程度の価格という条件に限定されたアイテムが推薦される。また、価格水準値が大きく、価格分散値も大きいユーザｕ４では、Ｘｃ、Ｘωが両方とも大きくなるので、価格の高いアイテムを中心に、幅広い価格帯のアイテムが推薦される。また、価格水準値が大きく、価格分散値が小さいユーザｕ５では、Ｘｃが大きく、Ｘωが小さいので、価格の高いアイテムのみ推薦される。

価格水準値Ｌ［ｕ］および価格分散値Ｖ［ｕ］に基づいて、ひな型関数Ｆｖ（Ｘ）の特性を変形させる方法は、上述の方法に限らない。例えば、価格分散値Ｖ［ｕ］が大きいほど、ピークと底部とのＹ方向の高さの差Ｙω（極大値とピーク底部の出力値との差）が小さくなるように設定してもよい。Ｙωを小さくすると、価格影響度の最大値Ｙβと、価格影響度の最小値Ｙαとの差（または倍率）が小さくなるので、推薦情報に入るアイテムの価格帯が広くなる。価格分散値が大きいユーザは、幅広い価格帯のアイテムを利用する傾向にあるので、そのようなユーザに対して、推薦アイテムの価格帯の幅を広く設定することは、購入意欲低下の防止に効果的である。また、価格分散値Ｖ［ｕ］が大きいほど、Ｘωを大きく、Ｙωを小さくする等、価格分散値Ｖ［ｕ］に応じて、ＸωとＹωを両方変化させてもよい。また、上述のＦｖ（Ｘ）は、ピークを中心に左右対称の関数であるが、ピークの左右で異なる形状の関数を用いてもよい。

次に、時間差Ｔｐが期間３（月の下旬）に該当する場合に、価格影響度算出部１０６ｃは、図３０に示す特性のひな型関数Ｆｗ（Ｘ）を用いる。この関数は、２つのピークを持っており、２つのピークの座標は、それぞれ（Ｘｃｓ，Ｙｃｓ）と（Ｘｃｈ，Ｙｃｈ）である。新規のアイテム利用権が付与されてからかなり時間が経過している下旬は、基本的には、安いアイテムの方がユーザに受容され易い。このため、第１のピークである（Ｘｃｓ，Ｙｃｓ）を用いて、価格の安いアイテムを推薦情報に入れるようにしている。一方で、翌月までに保有しているアイテム利用権（ポイント）を使い切りたいと考えるユーザも少なからず存在する。そのようなユーザに対しては、比較的高いアイテムを推薦すると、アイテム利用が促進され易い。このため、第２のピークである（Ｘｃｈ，Ｙｃｈ）を用いて、比較的価格の高いアイテムを推薦情報に入れるようにしている。本実施形態では、第１のピークの座標は固定とし、利用価格情報に応じて、この第２のピークの座標を設定する例を説明するが、これに限定する訳ではなく、第１のピークと第２のピークの両方を変化させてもよい。

ケース１）価格水準値Ｌ［ｕ］が小さい場合、具体的には所定の閾値δ５未満（Ｌ［ｕ］＜δ５）の場合、２つのピーク間のＸ方向の幅Ｘｄを比較的小さな値Ｘｄ１に設定し、底部と第２のピークとのＹ方向の差であるＹωも比較的小さな値Ｙω１に設定する。第２のピークのＸ方向の幅であるＸωは、標準的な値Ｘω１に設定する。このような関数特性に設定すると、価格の高いアイテムは、ほとんど推薦情報に入らなくなる。
ケース２）価格水準値Ｌ［ｕ］が、閾値δ５以上かつδ６未満であり、かつ価格分散値Ｖ［ｕ］が閾値ε５未満（δ５≦Ｌ［ｕ］＜δ６ ∩ Ｖ［ｕ］＜ε５）の場合、すなわち、価格水準値が中程度であり、かつ価格分散値が比較的小さい場合、Ｘｄを中程度の値Ｘｄ２に設定し、Ｙωを中程度の値Ｙω２に設定し、Ｘωを標準よりも小さな値Ｘω２（Ｘω２＜Ｘω１）に設定する。このような関数特性に設定すると、価格の安いアイテムの他に、中程度の価格を中心とした比較的狭い価格帯のアイテムが推薦情報に入り易くなる。

ケース３）価格水準値Ｌ［ｕ］が、閾値δ５以上かつδ６未満であり、かつ価格分散値Ｖ［ｕ］が閾値ε５以上（δ５≦Ｌ［ｕ］＜δ６ ∩ Ｖ［ｕ］≧ε５）の場合、すなわち、価格水準値が中程度であり、かつ価格分散値が比較的大きい場合、Ｘｄを中程度の値Ｘｄ２に設定し、Ｙωを中程度の値Ｙω２に設定し、Ｘωを標準よりも大きな値Ｘω３（Ｘω３＞Ｘω１）に設定する。このような関数特性に設定すると、価格の安いアイテムの他に、中程度の価格を中心とした比較的広い価格帯のアイテムが推薦情報に入り易くなる。

ケース４）価格水準値Ｌ［ｕ］が、δ６以上であり、かつ価格分散値Ｖ［ｕ］が閾値ε５以上（Ｌ［ｕ］≧δ６ ∩ Ｖ［ｕ］≧ε５）の場合、すなわち、価格水準値が比較的大きく、かつ価格分散値が比較的大きい場合、Ｘｄを大きな値Ｘｄ３に設定し、Ｙωを大きな値Ｙω３（Ｙω３＞Ｙω２）に設定し、Ｘωを標準よりも大きな値Ｘω３（Ｘω３＞Ｘω１）に設定する。このような関数特性に設定すると、価格の安いアイテムの他に、高い価格を中心とした比較的広い価格帯のアイテムが推薦情報に入り易くなる。なお、第２のピークの高さＹｃｈを第１のピークの高さＹｃｓよりも高くしてもよい。

ケース５）価格水準値Ｌ［ｕ］が、δ６以上であり、かつ価格分散値Ｖ［ｕ］が閾値ε５未満（Ｌ［ｕ］≧δ６ ∩ Ｖ［ｕ］＜ε５）の場合、すなわち、価格水準値が比較的大きく、かつ価格分散値が比較的小さい場合、Ｘｄを大きな値Ｘｄ３に設定し、Ｙωを大きな値Ｙω３（Ｙω３＞Ｙω２）に設定し、Ｘωを標準よりも小さな値Ｘω２（Ｘω２＜Ｘω１）に設定する。このような関数特性に設定すると、価格の安いアイテムの他に、高い価格を中心とした比較的狭い価格帯のアイテムが推薦情報に入り易くなる。なお、第２のピークの高さＹｃｈを第１のピークの高さＹｃｓよりも高くしてもよい。

このように第３実施例では、利用価格情報に応じて、ユーザごとに関数Ｆ（Ｘ）の特性を設定することにより、ユーザのアイテム利用状況に応じて、適応的に価格影響関数を設定することができるので、ユーザに受容される可能性の高いアイテムを、より正確に推薦情報に入れることができる。以上がステップＳ４１０ｃの説明である。

なお、上述の説明では、１つの価格水準値と、１つの価格分散値とを使って関数の特性を設定したが、より多くの利用価格情報を用いて関数の特性を設定してもよい。複数の利用価格情報をそれぞれ別々の関数パラメータに対応させてもよい。また、複数の利用価格情報を１つの関数パラメータに対応させてもよい。例えば、第２の利用価格情報である、ユーザの利用したアイテム１つあたりの価格の高さを示す値（代表値）と、第３の利用価格情報である、ユーザの利用したアイテム１つあたりの価格のばらつきの大きさ（ばらつき度）を示す値とを用いて、１つの関数パラメータを決定してもよい。

また、各々の関数パラメータを複数の利用価格情報を用いて決定する場合に、各利用価格情報を各次元に対応させた多次元情報空間を用いてもよい。例えば、多次元情報空間を適当な小領域に分割し、各々の小領域に対して関数パラメータの値を対応させる方法により、関数の特性を設定してもよい。また、各利用価格情報の重み付き平均などを用いて１次元の値を算出し、それに基づいて関数パラメータを決定してもよい。

なお、上述の第３実施例では、ユーザの利用価格情報に基づいて、価格影響関数の特性をユーザごとに変えているが、これとは異なる方法で、価格影響関数の特性をユーザごとに変えてもよい。例えば、ユーザが過去に提供された推薦情報をどの程度受け入れたかに応じて価格影響関数の特性を変更することができる。

この場合、過去のある時点においてユーザに提供された推薦情報に含まれるアイテムのうち、推薦情報提供後にそのユーザによって実際に利用されたアイテムの数を算出し、その数に基づいてユーザの利用度を算出する。利用度を算出する処理を行なうために、利用度算出部を情報選択装置１０に設けるようにしてもよい。そして、価格影響度算出部１０６ｃは、算出された利用度に応じて価格影響関数Ｆ（Ｘ）の特性を変えればよい。

具体的には、利用度の高いユーザほど、価格の高いアイテム（カテゴリ）が推薦されやすくなるように処理すればよい。これは、価格水準値が大きいユーザほど、価格の高いアイテム（カテゴリ）が推薦されやすくなるように処理したのと同様である。

利用度の高いユーザは、過去の推薦情報を多く受容しているので、推薦システムに対する信頼感をある程度持っていると考えられる。また、推薦情報が表示された画面から直接利用していない場合であっても、そのユーザの嗜好に合致した推薦アイテムを選択できたと考えられる。このため、このようなユーザに価格の高いアイテム（カテゴリ）をより多く推薦しても、ユーザの購買意欲の低下につながるリスクが小さいと考えられるからである。

一方、利用度の低いユーザに、価格の高いアイテム（カテゴリ）をより多く推薦すると、ユーザの購買意欲の低下につながるリスクが大きいと考えられる。このため、利用度の低いユーザには、価格の安いアイテムもある程度推薦されやすくなる処理を行なうようにする。

このようにユーザの推薦情報に対する利用度に応じて、価格影響関数の特性を変化させることにより、さらにユーザの購買意欲が減少するリスクを減らしつつ、価格の高いアイテム（カテゴリ）を推薦することができる。また、ユーザの推薦情報に対する利用度と、ユーザの利用価格情報を両方用いて、価格影響関数の特性を変えてもよい。

利用度の具体的な算出方法としては、例えば、１日に１回の頻度で推薦情報を作成しており、前回（前日）にユーザＡに対して１０個の推薦アイテムを提供している場合、次に新たな推薦情報を作成（提供）するまでの期間（約１日間）で、ユーザＡが１０個の推薦アイテムのうち何個を利用したかを、利用履歴格納部１０２とを推薦情報格納部１０８とを参照しながらカウントし、これを利用度とすればよい。

また、ユーザＡが１つの推薦アイテムを２回以上利用した場合、その回数を考慮して利用度を算出してもよいし、２回以上利用しても１回だけ利用しても同等に扱って利用度を算出してもよい。あるいは、ユーザＡが１０個の推薦アイテムのうちの１つ以上利用した場合に、利用度を「１」、１つも利用しない場合に利用度を「０」などとして、ユーザＡが推薦情報を１回以上利用したか否かの情報を利用度としてもよい。

ユーザＡが推薦アイテムを利用した場合に、図１３に示すような推薦画面（推薦ページ）から直接利用したのか、他のページで推薦アイテムを偶然見つけて利用したのかを区別するために、利用リクエストが発行された際にユーザが閲覧していたページ情報（閲覧ページ情報）を利用履歴格納部１０２に格納した上で、推薦ページから直接利用された分だけを利用度に反映させるようにしてもよいし、推薦アイテムが利用されたページの種類を区別せずに利用度を算出してもよい。

なお、上述の説明では、推薦情報を作成する期間と同じ期間の利用価格情報を用いているが、それに限定される訳ではない。例えば、期間３の推薦情報を作成する際に、期間３の利用価格情報に加えて、期間１および期間２の少なくとも一方の利用価格情報を用いてもよい。あるいは、期間１および期間２の少なくとも一方の利用価格情報を用い、期間３の利用価格情報を用いなくてもよい。例えば、期間１の価格水準値と、期間２の価格水準値の合計値または代表値を算出し、その値を期間３の価格水準値の代わりに用いて、期間３の推薦情報を作成してもよい。また、所定の時点以降の利用履歴から算出される利用価格情報を用いて、推薦情報を作成してもよい。

例えば、所定の時点を２０１３年１月１日午前０時とし、推薦情報を作成する時点あるいは推薦情報を提供開始する時点を２０１３年１月２５日午前０時とした場合、２０１３年１月１日から２０１３年１月２４日までの利用履歴を用いて、利用価格情報を算出し、それに基づいて価格影響関数の特性を設定してもよい。このようにすると、当月（２０１３年１月）にユーザが使った金額（ポイント数）に応じて価格影響関数の特性を設定することができるので、推薦情報に入れるアイテムの価格帯をより適切に設定できる場合がある。例えば、普段は毎月の前半に高額アイテムを多く利用するユーザが、当月（２０１３年１月１日から２０１３年１月２４日までの期間）に、高額アイテムをあまり利用していない場合、これから当月の月末にかけて価格の高いアイテムを利用する確率が高いと推定し、普段の月よりも価格の高いアイテムが多く推薦情報に入るようにしてもよい。あるいは、ユーザの購買力が何らかの理由で低下したと推定し、普段の月よりも価格の安いアイテムが多く推薦情報に入るようにしてもよい。

また上述の説明では、図２６に示すように、利用主体識別子ごとに利用価格情報を算出、格納しているが、利用主体識別子ごとではなく、ユーザ集団の全体的な利用価格情報を算出し、それに応じて価格影響関数を設定してもよい。例えば、ある期間の利用履歴を用いて、複数のユーザ（ユーザ集団）が、その期間に利用したアイテムの価格の合計値を算出し、それに応じて、そのユーザ集団に対して用いる価格影響関数を設定してもよい。また、全ユーザを１つのユーザ集団とみなして、全ユーザに対して共通の利用価格情報を算出してもよい。このようにすると、どのユーザに対しても同じ価格影響関数が適用されるが、利用主体識別子ごとに利用価格情報を算出および格納する必要がないので、情報選択装置１の処理負荷を軽減することができる。また、利用履歴の少ないユーザなどの場合、そのユーザ１人の利用履歴を用いて価格影響関数を設定するよりも、多くのユーザの利用履歴を用いて価格影響関数を設定した方が、適切な特性を設定できる場合がある。

また、上述の第３実施例の変形例として、以下の方法を用いることもできる。まず、利用価格情報算出部１１１は、利用履歴を用いて、ユーザｕが時間差Ｔｐの時点で価格情報Ｘのアイテムを利用する確率（条件付き確率）の分布（確率関数、確率密度関数）Ｐ（Ｘ｜ｕ，Ｔｐ）を、利用価格情報として算出する。例えば、確率関数の関数形として、正規分布や混合正規分布を仮定し、利用履歴を用いて、確率関数のパラメータ（平均値、分散、混合比など）を算出（推定）すればよい。時間差Ｔｐは、期間１、期間２、期間３などのように離散値として扱ってもよいし、連続量として扱ってもよい。このような確率関数の一例を図３１（ａ）に示す。本図は、時間差Ｔｐを５つの離散値として扱い、それぞれのＴｐに対応する５つの確率関数を示した例である。本図の奥から手前にかけて、時間差ＴｐがＴｐ１であるときの確率関数Ｐ（Ｘ｜ｕ，Ｔｐ１）から、時間差ＴｐがＴｐ５であるときのＰ（Ｘ｜ｕ，Ｔｐ５）が順に並んでいる（Ｔｐ１＜Ｔｐ２＜Ｔｐ３＜Ｔｐ４＜Ｔｐ５）。所定の時点と図１４に示す推薦情報作成処理を実行する時点との時間差Ｔｐを算出した後、Ｔｐ１〜Ｔｐ５の中でＴｐに最も近いものを特定し、それに対応する確率関数を用いて価格影響関数を設定すればよい。なお、それぞれの確率関数の間を滑らかに補間する等の処理を行ってもよい。

次に、価格影響度算出部１０６ｃは、算出された確率関数Ｐ（Ｘ｜ｕ，Ｔｐ）を用いて、時間差Ｔｐの時点でユーザｕに対して用いる価格影響関数Ｆ（Ｘ｜ｕ，Ｔｐ）を算出する。具体的には、確率関数Ｐ（Ｘ｜ｕ，Ｔｐ）をそのまま価格影響関数Ｆ（Ｘ｜ｕ，Ｔｐ）として用いることができる。あるいは、確率関数Ｐ（Ｘ｜ｕ，Ｔｐ）を変形して価格影響関数Ｆ（Ｘ｜ｕ，Ｔｐ）としてもよい。確率関数を変形して価格影響関数を作成する一例を図３１（ｂ）に示す。本図では、確率関数（確率密度関数）を破線で、価格影響関数を実線で示している。本図に示すように、例えば、確率関数（確率密度関数）をＸ軸方向に所定値λ１倍し、所定値λ２だけ平行移動させて得られる関数を価格影響関数としてもよい。

この場合、Ｆ（（Ｘ−λ２）／λ１｜ｕ，Ｔｐ）＝Ｐ（Ｘ｜ｕ，Ｔｐ）となる。ただし、λ１＞０である。ここで、λ１≒１、λ２＞０にすると、ユーザｕが過去に利用したアイテムよりも価格の高いアイテムが推薦情報に入る確率を高めることができる。λ２を適切な値に設定することにより、ユーザ１人あたりの利用金額が増える可能性が高くなるため、アイテムの提供サービス全体の売上が増える可能性も高くなる。また、λ１＞１にすると、ユーザｕが過去に利用したアイテムの価格帯よりも幅広い価格帯のアイテムが推薦情報に入る確率を高めることができる。

このように、確率関数を変形させた価格影響関数を用いることにより、ユーザが過去に利用したアイテムの価格情報の分布を基準にできるため、ユーザが受容し易く、かつ価格に関する販売者の方針を反映させた推薦情報を容易に作成することができる。なお、確率関数を変形させた結果、価格影響関数に未定義の区間が生じる場合（Ｘが０に近い場合など）は、その区間が一定の出力値となるようにしてもよいし、確率関数を使って適当に外挿してもよい。なお、確率関数および価格影響関数において、時間差Ｔｐを複数の期間のいずれかに対応させる等、離散値として扱う場合は、時間差Ｔｐが対応する期間を特定し、その期間に対応する確率関数および価格影響関数を用いればよい。また、確率関数および価格影響関数の条件部にユーザｕを含めずに、Ｐ（Ｘ｜Ｔｐ）およびＦ（Ｘ｜Ｔｐ）を算出するようにしてもよい。

この場合は、ユーザ個別に確率関数および価格影響関数を算出するのではなく、全てのユーザに対して共通する確率関数および価格影響関数を算出することになる。アイテム利用数が少ないユーザなどでは、個々のユーザごとに確率関数を算出（推定）するよりも、ユーザ全体の平均的な確率関数を用いた方がよい場合がある。利用価格情報算出部１１１が、利用価格情報として確率関数を算出し、価格影響度算出部１０６ｃが、それに基づいて価格影響関数の特性を設定し、価格影響度を算出した後、情報選択部１０７は、実施例１で説明した方法を用いて、選択指標を算出すればよい。

また更に別の変形例として、利用価格情報算出部１１１が、条件付き確率の条件部に、ユーザとアイテムとの関連度Ｗを加えた確率関数（確率密度関数）Ｐ（Ｘ｜ｕ，Ｔｐ，Ｗ）を算出してもよい。そして、価格影響度算出部１０６ｃは、確率関数Ｐ（Ｘ｜ｕ，Ｔｐ，Ｗ）に基づいて、価格影響関数Ｆ（Ｘ｜ｕ，Ｔｐ，Ｗ）を算出する。上述の説明と同様に、確率関数をそのまま用いてもよいし、変形して用いてもよい。なお、関連度Ｗを連続量として扱ってもよいし、例えば、適当な閾値を用い、大、中、小の３段階等のように離散値として扱ってもよい。

具体的には、制御部１１０または価格影響度算出部１０６ｃは、ステップＳ４００により関連集合格納部１０５に格納された関連集合（関連識別子）を読み出す際に、各関連度も合わせて読み出し、それぞれの関連度が大、中、小のいずれの段階に該当するか特定し、特定した段階に対応する確率関数を用いて、価格影響関数を設定する。すなわち、時間差Ｔｐがある一定の値である場合でも、各関連識別子の関連度に応じて、異なる価格影響関数を用いて、価格影響度が算出されることになる。確率関数の条件部に関連度を含めた場合は、関連度にも応じた価格影響度が算出されるので、価格影響度そのものを選択指標にしてもよい。また、確率関数および価格影響関数の条件部にユーザｕを含めずに、Ｐ（Ｘ｜Ｔｐ，Ｗ）およびＦ（Ｘ｜Ｔｐ，Ｗ）を算出するようにしてもよい。この場合は、ユーザ個別に確率関数および価格影響関数を算出するのではなく、全てのユーザに対して共通する確率関数および価格影響関数を算出することになる。

第３実施例によれば、ユーザごとに利用価格情報に応じて適切な価格影響度を算出するため、ユーザに特別な操作をさせることなく、ユーザごとに適切なタイミングで、適切な価格のアイテム（カテゴリ）の情報を提供できる。すなわち、ユーザが受容しやすい推薦情報を提供できる。例えば、ある時期に価格の安いアイテムだけを利用する傾向の強いユーザには、その時期に提供する推薦情報の中に、価格の安いアイテムを多く入れることができる。逆に、その時期に価格の高いアイテムを利用する傾向の強いユーザには、その時期に提供する推薦情報の中に、価格の高いアイテムを多く入れることができる。従って、ユーザが推薦情報を納得して受け入れやすくなる。このため推薦情報に基づくアイテム利用が活発になり、アイテム提供サービスの売上をさらに増大させることが期待できる。
また、第２実施例と第３実施例とを組み合わせて、ユーザごとに利用価格情報に応じて自動的に価格影響関数を設定した上で、ユーザの好みに応じてこの特性を変更できるようにしてもよい。このようにすれば、さらに受容性の高い推薦情報を提供することができる。

なお、第１〜第３実施例において、価格情報をアイテム属性格納部１０１に記録するようにして、価格情報格納部１０３を省略してもよい。また、価格情報をアイテム提供サーバ２０または他の外部の装置に格納するようにした上で、価格影響度算出部１０６が、その価格情報を取得して利用するようにしてもよい。

１０…情報選択装置、２０…アイテム提供サーバ、３０…端末装置、４０…ネットワーク、４２…ネットワーク、１０１…アイテム属性格納部、１０１Ａ…アイテム情報テーブル、１０１Ｂ…カテゴリ情報テーブル、１０２…利用履歴格納部、１０２Ａ…アイテム利用履歴テーブル、１０２Ｂ…カテゴリ利用履歴テーブル、１０３…価格情報格納部、１０３Ａ…アイテム価格情報テーブル、１０３Ｂ…カテゴリ価格情報テーブル、１０４…関連度算出部、１０５…関連集合格納部、１０５Ａ…関連度テーブル、１０５Ｂ…関連度テーブル、１０６…価格影響度算出部、１０７…情報選択部、１０８…推薦情報格納部、１０８Ａ…アイテム推薦情報テーブル、１０８Ｂ…カテゴリ推薦情報テーブル、１０９…送受信部、１１０…制御部、１１１…利用価格情報算出部、１１２…利用価格情報格納部、１１２Ａ…利用価格情報テーブル、１１２Ｂ…利用価格情報テーブル、１２０…表示装置、１３０…入力装置、２０１…ユーザ管理部、２０２…アイテム格納部、２０３…データ格納部、２０４…送受信部、２０５…制御部、３０１…制御部、３０２…送受信部、３０３…ブラウザ部、３０４…アプリケーション部、３２０…表示装置、３３０…入力装置

Claims (22)

1. アイテムを識別する識別子またはアイテムごとに定められたカテゴリを識別する識別子それぞれに係る価格情報を取得し、価格影響関数を用いて、前記価格情報を前記価格影響関数に入力して得られる価格影響度を、識別子それぞれについて算出する価格影響度算出部と、
   前記価格影響度が算出された識別子の中から、前記価格影響度に基づき決定された選択指標の大きな識別子を優先的に選択する情報選択部とを備え、
   前記価格影響度算出部は、所定の時点からの経過時間に応じて前記価格影響関数の特性を設定し、前記価格影響度を算出する
   ことを特徴とする情報選択装置。
2. 前記価格影響度算出部は、前記経過時間に応じて、出力値が極大または最大となるときの入力値、所定の出力値を得るための入力値、出力最大値と出力最小値との差、および出力最小値に対する出力最大値の倍率、出力値が極大となるピークの個数、のうちの少なくとも１つが変化するように前記価格影響関数の特性を設定する
   ことを特徴とする請求項２に記載の情報選択装置。
3. 前記価格影響度算出部は、前記経過時間が第１所定値以下である場合に、第１の価格情報に対応する第１の価格影響度を、第１の価格情報よりも小さい第２の価格情報に対応する第２の価格影響度よりも大きな値として算出し、前記経過時間が前記第１所定値より大きい場合に、前記第１の価格影響度を前記第２の価格影響度以下の値として算出する
   ことを特徴とする請求項１に記載の情報選択装置。
4. ユーザまたはユーザが利用する端末装置を識別するための利用主体識別子に対して、関連対象となる複数個のアイテムの識別子または複数個のカテゴリの識別子を、関連性の強さを示す関連度とともに格納する関連集合格納部をさらに備え、
   前記情報選択部は、情報選択に係る利用主体識別子について、前記関連対象とされた識別子それぞれの前記選択指標を、前記関連度が大きいほど、かつ前記価格影響度が大きいほど大きな値となる規則に従って算出し、前記関連対象とされた識別子の中から、算出された前記選択指標の大きな識別子を優先的に選択する
   ことを特徴とする請求項１〜請求項３のいずれか一項に記載の情報選択装置。
5. 前記情報選択部は、ユーザがアイテムを利用した利用回数に基づき、識別子ごとに算出された人気度、または識別子ごとに設定された推薦度を用い、識別子それぞれの前記選択指標を、前記人気度または前記推薦度が大きいほど、かつ前記価格影響度が大きいほど大きな値となる規則に従って算出し、算出された前記選択指標の大きな識別子を優先的に選択する
   ことを特徴とする請求項１〜請求項４のいずれか一項に記載の情報選択装置。
6. ユーザに提供されたアイテムの価格情報に基づく利用価格情報を算出する利用価格情報算出部をさらに備え、
   前記価格影響度算出部は、前記利用価格情報および前記経過時間に応じて前記価格影響関数の特性を設定し、前記価格影響度を算出する
   ことを特徴とする請求項１〜請求項５のいずれか一項に記載の情報選択装置。
7. 前記利用価格情報算出部は、情報選択に係るユーザまたはそのユーザが利用する端末装置を識別するための利用主体識別子に対応させて、そのユーザに提供されたアイテムの価格情報に基づく利用価格情報を算出し、
   前記価格影響度算出部は、前記情報選択に係る利用主体識別子の利用価格情報および前記経過時間に応じて前記価格影響関数の特性を設定し、前記情報選択に係る利用主体識別子に対して用いる前記価格影響度を算出することを特徴とする
   請求項６に記載の情報選択装置。
8. ユーザまたはユーザが利用する端末装置を識別するための利用主体識別子ごとに、その利用主体識別子に対応するユーザに提供されたアイテムの識別子と、提供時点の情報とを記録した利用履歴を格納する利用履歴格納部をさらに備え、
   前記利用価格情報算出部は、前記所定の時点または前記所定の時点から所定の時間だけ遡った時点を起点とし、前記起点から前記提供時点までの時間を用いて、利用履歴を複数の期間のいずれかに対応させると共に、それぞれの期間ごとに、提供されたアイテムの価格情報に基づく利用価格情報を算出し、
   前記価格影響度算出部は、前記複数の期間の中から前記経過時間に該当する期間を特定し、前記特定した期間に対応する利用価格情報に基づいて、前記価格影響関数の特性を設定する
   ことを特徴とする請求項６または請求項７に記載の情報選択装置。
9. 前記利用価格情報算出部は、ユーザに提供されたアイテムの価格の合計額、またはユーザに提供されたアイテムの価格の代表値を用いて、前記利用価格情報として価格水準値を算出し、
   前記価格影響度算出部は、前記価格水準値が大きいほど、出力値が極大または最大となるときの入力値、所定の出力値を得るための入力値、出力最大値と出力最小値との差、および出力最小値に対する出力最大値の倍率、のうちの少なくとも１つが大きくなるような傾向で前記価格影響関数の特性を設定する
   ことを特徴とする請求項６〜請求項８のいずれか一項に記載の情報選択装置。
10. 前記利用価格情報算出部は、ユーザに提供されたアイテムの価格の合計額、またはユーザに提供されたアイテムの価格の代表値を用いて、前記利用価格情報として価格水準値を算出し、
    前記価格影響度算出部は、前記価格水準値が大きいほど、入力が最小値であるときの出力値が小さくなるような傾向で前記価格影響関数を変化させる
    ことを特徴とする請求項６〜請求項９のいずれか１項に記載の情報選択装置。
11. 前記利用価格情報算出部は、ユーザに提供されたアイテムの価格、またはユーザに提供されたアイテムの合計額に関するばらつき度合いを示す価格分散値を前記利用価格情報として算出し、
    前記価格影響度算出部は、前記価格分散値が大きいほど、単調増加の区間の幅が大きくなるような傾向、出力が極大となるピーク部分の幅が大きくなるような傾向、出力が極大となるピーク部分の極大値と底部の出力値との差が低くなるような傾向、出力最大値と出力最小値との差が大きくなるような傾向、出力最小値に対する出力最大値の倍率が大きくなるような傾向、所定の出力値を得るための入力値が大きくなるような傾向、のうちの少なくとも１つの傾向で前記価格影響関数を変化させる
    ことを特徴とする請求項６〜請求項１０のいずれか１項に記載の情報選択装置。
12. 前記利用価格情報算出部は、前記利用価格情報として、ユーザに提供されたアイテムの価格に関する条件付き確率を示す確率関数であり、前記経過時間に関する情報を条件部に含む確率関数を算出し、
    前記価格影響度算出部は、前記経過時間が前記条件部に合致する確率関数に基づいて、前記価格影響関数の特性を設定する
    ことを特徴とする請求項６〜請求項８のいずれか１項に記載の情報選択装置。
13. ユーザまたはユーザが利用する端末装置を識別するための利用主体識別子に対して、関連対象となる複数個のアイテムの識別子または複数個のカテゴリの識別子を、関連性の強さを示す関連度とともに格納する関連集合格納部をさらに備え、
    前記利用価格情報算出部は、前記利用価格情報として、ユーザに提供されたアイテムの価格に関する条件付き確率を示す確率関数であり、前記経過時間および前記関連度に関する情報を条件部に含む確率関数を算出し、
    前記価格影響度算出部は、前記経過時間および前記関連度が前記条件部に合致する確率関数に基づいて、前記価格影響関数の特性を設定する
    ことを特徴とする請求項６〜請求項８のいずれか一項に記載の情報選択装置。
14. 前記アイテムまたはカテゴリを識別する識別子と、アイテム区分とを対応させて格納するアイテム属性格納部をさらに備え、
    前記利用価格情報算出部は、前記アイテム区分ごとに前記利用価格情報を算出し、
    前記価格影響度算出部は、前記アイテム属性格納部を参照し、前記識別子に対応するアイテム区分を特定し、前記特定されたアイテム区分について算出された利用価格情報に基づいて前記価格影響関数の特性を設定する
    ことを特徴とする請求項６〜請求項１３のいずれか１項に記載の情報選択装置。
15. 前記情報選択部は、前記選択指標が第１所定値以上の識別子、または前記選択指標の大きい順に第２所定値を超えない数の識別子を選択し、前記選択指標の大きさ順に関する情報を含めて、前記選択された識別子に係る情報を出力する
    ことを特徴とする請求項１〜請求項１４のいずれか１項に記載の情報選択装置。
16. ユーザまたはユーザが利用する端末装置を識別するための利用主体識別子ごとに、その利用主体識別子に対応するユーザに提供されたアイテムまたはそのアイテムのカテゴリの識別子を記録した利用履歴を格納する利用履歴格納部と、
    前記利用履歴に基づいて、利用主体識別子と識別子との前記関連度をそれぞれ算出し、算出された関連度が第３所定値以上の識別子、または算出された関連度の大きい順に第４所定値を超えない数の識別子を抽出し、抽出された識別子を前記情報選択に係る利用主体識別子に対する関連対象となる識別子とする関連度算出部とをさらに備える
    ことを特徴とする請求項４または請求項１３に記載の情報選択装置。
17. 前記関連度算出部は、前記利用履歴に基づいて情報選択に係る利用主体識別子と他の利用主体識別子との類似度を算出し、他の利用主体識別子の類似度と当該他の利用主体識別子に対応するユーザに提供されたアイテムの識別子とに基づいて、情報選択に係る利用主体識別子と識別子との前記関連度を算出する
    ことを特徴とする請求項１６に記載の情報選択装置。
18. 前記情報選択部によって過去に選択された識別子が示すアイテムまたは過去に選択された識別子が示すカテゴリに対応するアイテムが、選択された時点以降にユーザに提供された度合いを示す利用度を算出する利用度算出部をさらに備え、
    前記価格影響度算出部は、前記経過時間および前記利用度に応じて前記価格影響関数の特性を設定する
    ことを特徴とする請求項１〜請求項１７のいずれか１項に記載の情報選択装置。
19. 外部から前記経過時間および価格帯に関する制御データを受信する受信部をさらに備え、
    前記価格影響度算出部は、前記制御データに応じて、前記価格影響関数を変化させる
    ことを特徴とする請求項１〜請求項１８のいずれか１項に記載の情報選択装置。
20. 前記経過時間に応じて前記価格影響関数の特性を設定させるための表示制御情報を作成する表示制御情報作成部と、
    前記表示制御情報を外部に送信する送信部をさらに備える
    ことを特徴とする請求項１〜請求項１９のいずれか１項に記載の情報選択装置。
21. コンピュータが実行する情報選択方法であって、
    アイテムを識別する識別子またはアイテムごとに定められたカテゴリを識別する識別子それぞれに係る価格情報を取得し、価格影響関数を用いて、前記価格情報を前記価格影響関数に入力して得られる価格影響度を、識別子それぞれについて算出する価格影響度算出ステップと、
    前記価格影響度が算出された識別子の中から、前記価格影響度に基づき決定された選択指標の大きな識別子を優先的に選択する情報選択ステップとを含み、
    前記価格影響度算出ステップは、所定の時点からの経過時間に応じて前記価格影響関数の特性を設定し、前記価格影響度を算出する
    ことを特徴とする情報選択方法。
22. コンピュータに、
    アイテムを識別する識別子またはアイテムごとに定められたカテゴリを識別する識別子それぞれに係る価格情報を取得し、価格影響関数を用いて、前記価格情報を前記価格影響関数に入力して得られる価格影響度を、識別子それぞれについて算出する価格影響度算出工程と、
    前記価格影響度が算出された識別子の中から、前記価格影響度に基づき決定された選択指標の大きな識別子を優先的に選択する情報選択工程とを実行させ、
    前記価格影響度算出工程は、所定の時点からの経過時間に応じて前記価格影響関数の特性を設定し、前記価格影響度を算出する
    ことを特徴とする情報選択プログラム。