(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2021-12-17
(45)【発行日】2022-01-14
(54)【発明の名称】提案装置、提案方法及び提案プログラム
(51)【国際特許分類】
G06Q 30/02 20120101AFI20220106BHJP
【FI】
G06Q30/02 470
(21)【出願番号】P 2017192126
(22)【出願日】2017-09-29
【審査請求日】2020-06-02
(73)【特許権者】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(73)【特許権者】
【識別番号】517185458
【氏名又は名称】下村 拓滋
(73)【特許権者】
【識別番号】000237606
【氏名又は名称】加賀FEI株式会社
(73)【特許権者】
【識別番号】399128600
【氏名又は名称】株式会社ユナイテッドアローズ
(74)【代理人】
【識別番号】110002147
【氏名又は名称】特許業務法人酒井国際特許事務所
(72)【発明者】
【氏名】加藤 圭造
(72)【発明者】
【氏名】板▲崎▼ 輝
(72)【発明者】
【氏名】霜 仁世
(72)【発明者】
【氏名】富士 聡子
(72)【発明者】
【氏名】下村 拓滋
(72)【発明者】
【氏名】椎橋 義雄
(72)【発明者】
【氏名】村上 悠
(72)【発明者】
【氏名】橋本 史野
【審査官】青柳 光代
(56)【参考文献】
【文献】特開2009-122781(JP,A)
【文献】特開2014-102739(JP,A)
【文献】特開2014-164454(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
G16H 10/00 - 80/00
(57)【特許請求の範囲】
【請求項1】
ユーザが所有する各ユーザ商品に付与された識別情報を用いて、前記各ユーザ商品が利用されたか否かについて、前記識別情報が、センサにより所定の時間以上又は所定の回数以上連続して受信されない場合に、前記ユーザ商品が利用されたと検出する検出部と、
少なくとも1つのユーザ商品と対応づけて記憶された、前記ユーザ商品の利用回数に基づいて、少なくとも1つのユーザ商品を買取候補商品として特定する買取候補特定部と、
前記買取候補商品に関連付けられる、前記ユーザに対して新たに購入を提案する提案商品の情報と併せて、前記買取候補商品に関する情報を出力する出力部と
を有することを特徴とする提案装置。
【請求項2】
前記出力部は、前記買取候補商品の名称、カテゴリ、前記買取候補商品に関する説明文、前記買取候補商品の画像及び買取金額のうち少なくともいずれかを含む前記買取候補商品に関する情報及び前記提案商品に関する情報を出力することを特徴とする請求項
1に記載の提案装置。
【請求項3】
前記提案商品を、特定された前記買取候補商品に関する情報に基づいて関連付ける商品特定部をさらに有することを特徴とする請求項1
または2に記載の提案装置。
【請求項4】
前記買取候補特定部は、
前記買取候補商品を特定する際に、特定のイベント時
に利用されたことを示す情報に対応付けられるユーザ商品を前記買取候補商品から除外した上で、前記ユーザ商品の利用回数を用いて、前記買取候補商品を特定することを特徴とする請求項1乃至
3のいずれか1つに記載の提案装置。
【請求項5】
ユーザが所有する各ユーザ商品に付与された識別情報を用いて、前記各ユーザ商品が利用されたか否かについて、前記識別情報が、センサにより所定の時間以上又は所定の回数以上連続して受信されない場合に、前記ユーザ商品が利用されたと検出し、
少なくとも1つのユーザ商品と対応づけて記憶された、前記ユーザ商品の利用回数に基づいて、少なくとも1つのユーザ商品を買取候補商品として特定し、
前記買取候補商品に関連付けられる、前記ユーザに対して新たに購入を提案する提案商品の情報と併せて、前記買取候補商品に関する情報を出力する
処理をコンピュータが実行することを特徴とする提案方法。
【請求項6】
ユーザが所有する各ユーザ商品に付与された識別情報を用いて、前記各ユーザ商品が利用されたか否かについて、前記識別情報が、センサにより所定の時間以上又は所定の回数以上連続して受信されない場合に、前記ユーザ商品が利用されたと検出し、
少なくとも1つのユーザ商品と対応づけて記憶された、前記ユーザ商品の利用回数に基づいて、少なくとも1つのユーザ商品を買取候補商品として特定し、
前記買取候補商品に関連付けられる、前記ユーザに対して新たに購入を提案する提案商品の情報と併せて、前記買取候補商品に関する情報を出力する
処理をコンピュータに実行させることを特徴とする提案プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、提案装置、提案方法及び提案プログラムに関する。
【背景技術】
【0002】
衣料品のオンライン店舗等で、ユーザが所持する不要な商品の譲渡を促す情報を出力する技術が知られている。例えば、商品の購入履歴を利用して、商品購入時などに同ユーザが同種の製品を以前購入しているか否かを検索し、購入していれば買替による商品購入と判断する技術が知られている。当該技術においては、購入時期が古い方の商品を第三者に譲渡するようリコメンドする情報が出力される。
【0003】
また、衣類を選択する際に、ユーザが入力した情報に基づいて、衣類を選択する技術が知られている。例えば、ユーザから自分の着たい衣類を特定する情報の入力を受け付けると、着用の際の評価としての基準適正値を算出し、これ以上の適正値でユーザの特定した衣類に類似するものを選び出す技術が知られている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2009-122780号公報
【文献】国際公開第2008/142909号
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかし、上記技術においては、ユーザの衣料品の利用状況を適切に反映していないので、譲渡対象とする衣類を的確に選定できない場合がある。例えば、購入時期が古い方の商品であっても、ユーザが愛着を持っていて衣類を捨てずに使い続けている場合や、特定のイベントの際に限りユーザが当該衣類を着用する場合もある。この場合、選択された衣類を譲渡対象として提示することが適切ではないこともある。
【0006】
一つの側面では、ユーザの利用状況に即して買取候補となるアイテムを選定できる提案装置、提案方法及び提案プログラムを提供することを目的とする。
【課題を解決するための手段】
【0007】
一つの態様において、提案装置は、ユーザが所有する、少なくとも1つのユーザ商品と対応づけて記憶された、前記ユーザ商品の利用回数に基づいて、少なくとも1つのユーザ商品を買取候補商品として特定する。また、提案装置は、前記買取候補商品に関連付けられる、前記ユーザに対して新たに購入を提案する提案商品の情報と併せて、前記買取候補商品に関する情報を出力する。
【発明の効果】
【0008】
一つの態様によれば、ユーザの利用状況に即して買取候補となるアイテムを選定できる。
【図面の簡単な説明】
【0009】
【
図1】
図1は、実施例1における提案システムの一例を示す図である。
【
図2】
図2は、実施例1における提案装置の一例を示す図である。
【
図3】
図3は、実施例1におけるアイテムDBの一例を示す図である。
【
図4】
図4は、実施例1における着用履歴DBの一例を示す図である。
【
図5】
図5は、実施例1における商品DBの一例を示す図である。
【
図6】
図6は、実施例1における通知DBの一例を示す図である。
【
図7】
図7は、実施例1における提案画面の一例を示す図である。
【
図8】
図8は、実施例1における履歴更新処理の一例を示すフローチャートである。
【
図9】
図9は、実施例1における提案処理の一例を示すフローチャートである。
【
図10】
図10は、実施例2における提案装置の一例を示す図である。
【
図11】
図11は、実施例2における着用履歴DBの一例を示す図である。
【
図12】
図12は、実施例2における記念日DBの一例を示す図である。
【
図13】
図13は、実施例2における提案処理の一例を示すフローチャートである。
【
図14】
図14は、コンピュータのハードウェア構成例を示す図である。
【発明を実施するための形態】
【0010】
以下に、本願の開示する提案装置、提案方法及び提案プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、以下に示す各実施例は、矛盾を起こさない範囲で適宜組み合わせても良い。
【実施例1】
【0011】
まず、本実施例における買取候補の提案について、
図1を用いて説明する。
図1は、実施例1における提案システムの一例を示す図である。
図1に示す提案システム1は、提案装置100と、センサ600と、カメラ700と、携帯端末3100とを有する。提案装置100は、センサ600、カメラ700及び携帯端末3100と、例えば無線通信にて通信可能に接続される。なお、
図1における携帯端末3100a乃至3100cは、異なる時点における同一の携帯端末3100の位置を示す。
【0012】
図1に示すセンサ600及びカメラ700は、例えばユーザ3000が住む部屋10に設置される。携帯端末3100は、例えばユーザ3000により携帯される。なお、提案装置100は、例えば商品を販売するECサイト900を運営する企業のデータセンター等に設置される。また、
図1におけるユーザ3000a乃至3000cは、携帯端末3100a乃至3100cと同様に、同一のユーザ3000の異なる時点における位置を示す。
【0013】
図1に示すセンサ600は、例えば部屋10のクローゼット2000に設置される。クローゼット2000には、ユーザ3000が保有する洋服2100、2200及び2300並びにその他の洋服などのアイテムが収納される。なお、アイテムは、例えばユーザ3000が過去に購入した商品であり、ユーザ商品の一例である。
【0014】
クローゼット2000に収納される洋服2100には、識別情報を有するタグ2101が付与されている。本実施例において、洋服2200及び2300にも、同様に図示しないタグ2201及び2301がそれぞれ付与される。クローゼット2000に収納されるその他の洋服などのアイテムについても同様である。なお、本実施例におけるタグは、例えばNFC(Near Field Communication)タグなどのRF(Radio Frequency)タグであるが、これに限られない。センサ600は、タグ2101から識別情報を読み取り、提案装置100に送信する。
【0015】
また、
図1に示すカメラ700は、例えば部屋10の出入口2500に設置される。カメラ700は、出入口2500を通るユーザ3000が着用している洋服2100を撮影できる。カメラ700は、撮影した画像データを提案装置100に送信する。提案装置100は、カメラ700から受信した画像データを解析することにより、ユーザ3000bが着用している洋服2100を特定する。なお、カメラ700は、画像データに代えて、撮影した画像からユーザ3000bが着用している洋服2100を特定し、洋服2100を識別するデータを提案装置100に送信してもよい。
【0016】
図1に示す提案装置100は、ユーザ3000による洋服その他のアイテムの着用回数を記憶する。例えば、提案装置100は、センサ600から、タグ2101の識別情報を定期的に受信する。そして、提案装置100は、所定の時間以上タグ2101の識別情報を受信しない場合、タグ2101が付与された洋服2100をユーザ3000が着用していると判定する。また、提案装置100は、カメラ700から受信する画像データを用いて、ユーザ3000が洋服2100を着用していることを特定してもよい。なお、提案装置100は、識別情報又は画像データにより特定された洋服2100のレコードを追加する際に、着用回数を1増加させる。
【0017】
そして、提案装置100は、ユーザ3000が保有する洋服2100、2200及び2300並びにその他の洋服等のアイテムのうち、例えばもっとも着用回数が少ないものを、買取候補として特定する。なお、買取候補は、買取候補商品として特定されたユーザ商品の一例である。
【0018】
提案装置100は、買取候補として特定された洋服2300の買取を提案する画面3101cを、ユーザ3000の携帯端末3100に送信する。提案装置100は、例えば、ユーザ3000がECサイト900にアクセスし、商品を選択する際に画面3101cを携帯端末3100に送信し、ユーザ3000にアイテムの買取を提案する。なお、買取候補という表現は、アイテムの所有者であるユーザ3000の立場から見れば、下取りに出す候補、リサイクル品として供出する候補、もしくは、売却候補と言い換えることもできる。
【0019】
なお、
図1においては、クローゼット2000に設置されたセンサ600と、出入口2500に設置されたカメラ700との両方を用いてユーザ3000が来ている洋服を特定する構成について説明したが、実施の形態はこれに限られない。例えば、センサ600及びカメラ700のいずれか一方だけを用いて洋服を特定するような構成であってもよい。また、センサ600から取得したデータにより特定された洋服と、カメラ700から取得したデータにより特定された洋服とが異なる場合に、センサ600及びカメラ700のどちらから取得したデータを優先するかを予め決定してもよい。
【0020】
[機能ブロック]
次に、本実施例における提案装置の一例について、
図2を用いて説明する。
図2は、実施例1における提案装置の一例を示す図である。
図2に示すように、本実施例における提案装置100は、通信部110と、記憶部120と、制御部130とを有する。
【0021】
通信部110は、有線又は無線を問わず、図示しないネットワークを経由して、センサ600、カメラ700、携帯端末3100など、その他のコンピュータ及びセンサ等との通信を制御する。
【0022】
記憶部120は、例えば制御部130が実行するプログラムなどの各種データなどを記憶する。また、記憶部120は、アイテムDB121、着用履歴DB122、商品DB123及び通知DB124を有する。記憶部120は、RAM(Random Access Memory)、ROM(Read Only Memory)、フラッシュメモリなどの半導体メモリ素子や、HDD(Hard Disk Drive)などの記憶装置に対応する。
【0023】
アイテムDB121は、例えばユーザ3000が保有するアイテムに関する情報を記憶する。
図3は、実施例1におけるアイテムDBの一例を示す図である。
図3に示すように、アイテムDB121は、アイテムの「カテゴリ」、「購入日」、「購入価格」、「サイズ」、「カラー」、「画像」、「着用時期」及び「提案フラグ」を、「アイテムID」(Identifier)に対応付けて記憶する。
【0024】
図3において、アイテムIDは、アイテムを一意に識別する識別子であり、例えばタグ2101から読み取られる識別情報であってもよく、またアイテムDB121へのアイテム登録時に付与されるIDであってもよい。アイテムDB121は、例えばユーザごとに一つのテーブルを有する。なお、アイテムDB121に記憶される情報は、例えば後に説明するアイテム検出部131により入力される。
【0025】
図3において、「カテゴリ」は、ジャケットやスカート、アクセサリーなど、アイテムが属するカテゴリを記憶する。「購入日」及び「購入価格」は、アイテムを購入した日及び購入した価格をそれぞれ記憶する。「サイズ」及び「カラー」は、それぞれアイテムの大きさ及び色を記憶する。
【0026】
図3において、「画像」は、アイテムの画像データのファイル名を記憶する。なお、
図3に示すように、画像データは例えばjpgファイル形式であるが、これに限られず、pngファイルなど任意の形式の画像データを用いてもよい。なお、アイテムの画像データは、例えば記憶部120に記憶されるが、例えば提案装置100以外の外部のコンピュータに保存されるような構成であってもよい。
【0027】
図3において、「着用時期」は、当該アイテムが特定の季節限定で着用される場合に、着用される時期に関する情報を記憶する。なお、時期を問わず着用されるアイテムについては、例えばアイテムID「ABC-003」のように「1~12月」が着用時期として記憶される。なお、「カテゴリ」、「購入日」及び「購入価格」、「サイズ」、「「カラー」並びに「画像」のファイル名等の情報は、例えば洋服2100に付されたタグ2101から取得されるが、その他の方法により特定してもよい。
【0028】
図3において、「提案フラグ」は、該当するアイテムを買取候補として提案するか否かを記憶する。例えば、提案装置100は、提案フラグが「1」であるアイテムを、買取候補としてユーザ3000に提案する。
【0029】
図3に示すアイテムDB121は、例えばアイテムID「ABC-003」のアイテムは「2010年4月5日」に「10,000円」で購入された「アクセサリー」であることを記憶する。また、
図3に示すアイテムDB121は、アイテムID「ABC-003」のアイテムについて、サイズは指定されておらず、カラーは「プラチナ」であること、画像データのファイル名は「1231.jpg」であることを記憶する。また、
図3に示すアイテムDB121は、アイテムID「ABC-003」のアイテムの着用時期は「1~12月」であること、及び買取候補としては提案されていないことを記憶する。
【0030】
なお、アイテムDB121に記憶される項目は一例であり、アイテムIDに対応するアイテムの名称、アイテムに関する説明文、材質、販売元、ブランド名、生産国等の情報をさらに含んでもよい。また、アイテムDB121が、
図3に示すいずれかの情報を含まないような構成であってもよく、いずれかの情報が他のデータベースに記憶されるような構成であってもよい。
【0031】
図2に戻って、着用履歴DB122は、アイテムDB121に記憶されるアイテムの着用履歴に関する情報を記憶する。
図4は、実施例1における着用履歴DBの一例を示す図である。
図4に示すように、着用履歴DB122は、例えば、「着用日時」及び「帰宅日時」と、「アイテムID」と、「着用回数」と、「着用率」とを「着用ID」に対応付けて記憶する。着用履歴DB122は、例えばユーザごとに一つのテーブルを有する。なお、着用履歴DB122のレコードは、例えばユーザ3000によるアイテムの着用が検出される都度、後に説明するアイテム検出部131により追加される。
【0032】
図4において、「着用ID」は、アイテムの着用履歴を一意に識別する識別子である。「着用日時」及び「帰宅日時」は、当該アイテムを着用して外出した日時、及び帰宅した日時を記憶する。帰宅日時は、例えばカメラ700においてユーザ3000が帰宅したことを特定した日時であるが、これに限られず、例えばアイテムをクローゼットに収納した日時を帰宅日時として記憶してもよい。
【0033】
図4において、「着用回数」は、当該アイテムを購入してから通算する着用回数を記憶する。「着用率」は、当該アイテムを着用する頻度、例えば月に何回当該アイテムを着用したかを記憶する。
【0034】
例えば、
図4において、着用ID「ABC-W111-2」のレコードは、ユーザ3000が、アイテムID「ABC-002」のスカートを、「2017年3月25日10:00」に着用して外出し、同日の「19:00」に帰宅したことを記憶する。また、
図4は、アイテムID「ABC-002」のスカートは通算で「7回」着用され、一月あたりにすると「0.1」回着用されたことを記憶する。
【0035】
図2に戻って、商品DB123は、ECサイト900においてユーザ3000が選択できる商品を記憶する。なお、ECサイト900においてユーザ3000が選択できる商品は、提案商品の一例である。
【0036】
また、商品DB123に記憶される商品の情報は、後に説明する商品特定部132が、ユーザ3000に対して購入を提案する商品を特定する際にも用いられる。なお、購入を提案する商品という表現は、ECサイト900の運営者の立場から見れば、販売を提案する商品と言い換えることもできる。なお、以下において、後に説明する、ユーザ3000に対して販売を提案する商品として推薦する商品を、ユーザ3000に対する「リコメンド商品」と表現する場合がある。商品DB123は、例えばECサイト900ごとに一つのテーブルを有する。なお、商品DB123に記憶される情報は、例えばECサイト900の管理者により、予め入力される。
【0037】
図5は、実施例1における商品DBの一例を示す図である。
図5に示すように、商品DB123は、「アイテムID」に対応付けて、商品の「カテゴリ」と、「画像」と、「販売価格」とを記憶する。
図5において、「販売価格」は、当該商品のECサイト900における販売価格を記憶する。例えば、
図5に示す商品DB123は、アイテムID「XYZ-002」の「スカート」は、ECサイト900にて「5000」円で販売されることを記憶する。なお、商品DB123が記憶する情報は一例であり、例えばアイテムIDに対応する商品の名称、商品に関する説明文など、その他の商品に関する情報を含んでもよい。
【0038】
次に、通知DB124は、ユーザ3000に対して提案した買取候補、ユーザが選択した商品、及びリコメンド商品に関する情報を記憶する。
図6は、実施例1における通知DBの一例を示す図である。
図6に示すように、通知DB124は、「通知日時」と、「区分」と、「アイテムID」と、「金額」とを対応付けて記憶する。通知DB124は、例えばユーザごとに一つのテーブルを有する。なお、通知DB124に記憶される情報は、例えば後に説明する買取候補特定部133により入力される。
【0039】
図6において、「通知日時」は、ユーザ3000に対して買取候補の提案を行った日時を示す。
図6において、「区分」は、通知の内容を示す。例えば、「買取候補」は、ユーザ3000に対して通知される買取候補であることを示し、「商品推薦」は、商品特定部132がユーザ3000に対するリコメンド商品として推薦した商品であることを記憶する。また、「選択商品」は、ユーザ3000がECサイト900において選択した商品であることを記憶する。「アイテムID」及び「金額」は、買取候補となるアイテムの買取金額を記憶する。
【0040】
例えば、
図6に示す通知DB124は、アイテムID「ABC-002」のスカートを「買取候補」として、「2000」円で買い取ることを提案する通知を、「2017年3月25日10:00」に送信したことを記憶する。なお、通知DB124が記憶する情報は一例であり、例えばアイテムIDに対応する買取候補又はリコメンド商品の名称、カテゴリ、説明文及び画像のファイル名など、その他の買取候補に関する情報及びリコメンド商品に関する情報をさらに含んでもよい。
【0041】
図2に戻って、制御部130は、提案装置100の全体的な処理を司る処理部である。制御部130は、例えば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、内部の記憶装置に記憶されているプログラムがRAMを作業領域として実行されることにより実現される。また、制御部130は、例えば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現されるようにしてもよい。
【0042】
制御部130は、アイテム検出部131、商品特定部132、買取候補特定部133及び出力部134を有する。なお、アイテム検出部131、商品特定部132、買取候補特定部133及び出力部134は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。
【0043】
アイテム検出部131は、ユーザ3000が着用しているアイテムを特定する。アイテム検出部131は、例えば通信部110を通じてセンサ600及びカメラ700から受信する情報を用いて、ユーザ3000が着用しているアイテムを特定する。なお、アイテム検出部131は、検出部の一例である。
【0044】
例えば、アイテム検出部131は、センサ600から定期的に受信するタグ2101の識別情報が、所定の時間以上又は所定の回数以上連続して受信されない場合、タグ2101が付与された洋服2100をユーザ3000が着用したと判定する。
【0045】
なお、例えばユーザ3000がアイテムを選ぶために一時的にクローゼット2000から洋服2100を出したが、結局は着用しない場合もある。このような場合を着用回数としてカウントしないようにするため、本実施例におけるセンサ600は、洋服2100が着用されたとみなす場合を、識別情報を所定の時間以上又は所定の回数以上連続して受信されない場合に限定する。
【0046】
また、アイテム検出部131は、カメラ700から受信した画像を解析し、ユーザ3000が着用しているアイテムを特定する。そして、アイテム検出部131は、画像から洋服2100を検出した場合、ユーザ3000が洋服2100を着用していると判定する。
【0047】
アイテム検出部131は、ユーザ3000が着用していると判定したアイテムのアイテムIDが、アイテムDB121に登録されているか否かを判定する。例えば、アイテム検出部131は、アイテムに付与されたタグからセンサ600を通じて取得した識別情報が、アイテムDB121に記憶されているか否かを判定する。
【0048】
アイテム検出部131は、アイテムDB121にアイテムIDが登録されていないと判定した場合、ユーザ3000が着用していると判定したアイテムの情報を新たにアイテムDB121に登録する。また、アイテム検出部131は、着用履歴DB122に、当該アイテムIDに対応するアイテムの着用を示すレコードを追加する。その際、アイテム検出部131は、当該アイテムIDに対応するレコードを追加する際に、着用回数を「1」とする。また、アイテム検出部131は、当該アイテムIDに対応するレコードを追加する際に、例えば当該アイテムの購入日を用いて、着用率を算出する。
【0049】
一方、アイテム検出部131は、アイテムDB121にユーザ3000が着用していると判定したアイテムのアイテムIDが登録されていると判定した場合、着用履歴DB122に、当該アイテムIDに対応するレコードを追加する。その際、アイテム検出部131は、当該アイテムIDに対応するレコードを追加する際に、着用回数を1増加させるとともに、着用率を再計算する。
【0050】
次に、商品特定部132は、ユーザ3000が購入を希望する商品を特定する。商品特定部132は、例えばユーザ3000がECサイト900にアクセスして選択した商品に関する情報を取得する。また、商品特定部132が、ECサイト900にアクセスしたユーザ3000に対して、公知のリコメンド技術を用いて、ユーザ3000に対して推薦するリコメンド商品を選択するような構成であってもよい。商品特定部132は、特定した商品に関する情報を、買取候補特定部133に出力する。
【0051】
次に、買取候補特定部133は、着用履歴DB122を参照し、ユーザ3000に対して買取候補として提示するアイテムを特定する。買取候補特定部133は、着用履歴DB122に記憶されるアイテムのうち、例えば、最も「着用率」が低いアイテムを、買取候補として特定する。また、買取候補特定部133は、商品特定部132から商品に関する情報の出力を受けた場合、例えばアイテムDB121を参照して、当該商品と同じカテゴリのアイテムを特定する。そして、買取候補特定部133は、特定された当該商品と同じカテゴリのアイテムのうち、最も「着用率」が低いアイテムを買取候補として特定する。
【0052】
なお、買取候補特定部133は、常に買取候補を特定するのではなく、例えば、アイテムの数に応じて、買取候補を特定するか否かを判定してもよい。この場合、買取候補特定部133は、例えばアイテムの数が予め設定された所定の閾値未満である場合には買取候補を特定せず、アイテムの数が所定の閾値以上である場合にのみ買取候補を特定してもよい。これにより、需要がない場合における買取候補の提示を抑制できる。
【0053】
なお、当該所定の閾値は、例えば図示しない提案装置100の管理者により予め設定されているが、これに限られず、ユーザが任意に当該所定の閾値を設定してもよい。また、当該所定の閾値は、アイテムの種類ごとに異なっていてもよく、例えばTシャツに関する所定の閾値を、ジャケットに関する所定の閾値より大きくしてもよい。例えば、アイテムの数に関する所定の閾値の初期設定値が「5」である場合において、ユーザがTシャツに関する所定の閾値を「10」に、ジャケットに関する所定の閾値を「4」に、それぞれ変更してもよい。これにより、ユーザによるアイテムごとの着用頻度や好みに応じて、買取候補を提示するか否かを調整できる。
【0054】
次に、出力部134は、特定された買取候補に関する情報を出力する。出力部134は、例えば、ユーザ3000が携帯端末3100を用いてECサイト900にアクセスして商品を選択した際に、選択された商品の情報と、特定された買取候補に関する情報とを含む提案画面を、通信部110を通じて携帯端末3100に送信する。
【0055】
図7は、実施例1における提案画面の一例を示す図である。
図7に示すように、本実施例における提案画面4000は、ユーザ3000が選択した商品4001と、買取候補特定部133が特定した買取候補4101とを含む画面である。また、本実施例における提案画面4000は、通常の購入ボタン4002に加えて、買取候補の下取りを合わせて申し込むボタン4102も含む。これにより、提案装置100は、ユーザ3000に対して、買取候補のアイテムの買取を提案することができる。
【0056】
なお、出力部134が出力する情報はこれに限られず、例えば買取候補又はリコメンド商品の名称、カテゴリ、商品に関する説明文などの情報をさらに含んでもよい。また、出力部134は、例えば買取候補の画像データやアイテム名のみを出力し、買取金額を出力しないような構成であってもよい。また、以下において、ユーザ3000に対する商品の販売と合わせて行われるユーザ3000が保有するアイテムの下取りについても、アイテムの「買取」と表現する場合がある。
【0057】
[処理の流れ]
次に、本実施例における提案装置100による処理について、
図8及び
図9を用いて説明する。まず、アイテム検出部131によるアイテム検出及び着用履歴更新に関する処理について説明する。
図8は、実施例1における履歴更新処理の一例を示すフローチャートである。
図8に示すように、提案装置100のアイテム検出部131は、例えば通信部110を通じてセンサ600又はカメラ700から受信する情報等に基づいて、ユーザ3000によるアイテムの着用を検出するまで待機する(S100:No)。
【0058】
アイテム検出部131は、アイテムの着用を検出したと判定した場合(S100:Yes)、着用が検出されたアイテムのアイテムIDを特定する。そして、アイテム検出部131は、特定されたアイテムIDが、アイテムDB121に記憶されているか否かを判定する(S110)。アイテム検出部131は、特定されたアイテムIDがアイテムDB121に記憶されていないと判定した場合(S110:No)、アイテムDB121に、着用が検出されたアイテムに関するレコードを追加し(S111)、S120に移行する。
【0059】
一方、アイテム検出部131は、特定されたアイテムIDが、アイテムDB121に記憶されていると判定した場合(S110:Yes)、着用履歴DB122において、当該アイテムIDに対応する着用履歴のレコードを追加し(S120)、処理を終了する。
【0060】
次に、買取候補特定部133が買取候補を選定し、出力部134が出力する処理について説明する。
図9は、実施例1における提案処理の一例を示すフローチャートである。
図9に示すように、提案装置100の商品特定部132は、ユーザ3000がECサイト900にアクセスし、商品を選択するまで待機する(S200:No)。買取候補特定部133は、ユーザ3000により商品が選択されたと判定した場合(S200:Yes)、アイテムDB121に登録されている、選択された商品と同種のアイテムの数が、所定の閾値以上であるか否かを判定する(S210)。買取候補特定部133は、選択された商品と同種のアイテムの数が、所定の閾値未満であると判定した場合(S210:No)、買取候補の提示を行わずに処理を終了する。
【0061】
一方、買取候補特定部133は、ユーザ3000が保有する、選択された商品と同種のアイテムの数が、所定の閾値以上であると判定した場合(S210:Yes)、買取候補として特定する。例えば、買取候補特定部133は、アイテムDB121に登録された、選択された商品と同種のアイテムのうち、着用率が最も低いアイテムを買取候補として特定する(S211)。そして、出力部134は、特定されたアイテムを、買取候補としてユーザ3000に提示し(S212)、処理を終了する。
【0062】
[効果]
以上説明したように、本実施例における提案装置は、ユーザが所有する、少なくとも1つのユーザ商品と対応づけて記憶された、前記ユーザ商品の利用回数に基づいて、少なくとも1つのユーザ商品を買取候補商品として特定する。また、本実施例における提案装置は、前記買取候補商品に関連付けられる、前記ユーザに対して新たに購入を提案する提案商品の情報と併せて、前記買取候補商品に関する情報を出力する。これにより、提案装置は、ユーザの利用状況に即して買取候補となるアイテムを選定できる。
【0063】
また、本実施例における提案装置は、前記ユーザ商品に付与された識別情報を用いて、前記ユーザ商品が利用されたか否かを判定する。これにより、ユーザにアイテムの情報の入力等の煩雑な作業を要求することなく、提案装置は、アイテムの着用状況を把握することができる。
【0064】
また、本実施例における提案装置は、前記買取候補商品を、前記提案商品の名称、カテゴリ、前記提案商品に関する説明文、前記提案商品の画像及び販売金額のうち少なくともいずれかを含む前記提案商品に関する情報に基づいて特定する。また、前記出力部は、前記買取候補商品の名称、カテゴリ、前記買取候補商品に関する説明文、前記買取候補商品の画像及び買取金額のうち少なくともいずれかを含む前記買取候補商品に関する情報及び前記提案商品に関する情報を出力する。これにより、提案商品の種別等に関する条件に合致する買取候補商品を提案できる。
【0065】
さらに、本実施例における提案装置は、前記提案商品を、特定された前記買取候補商品に関する情報に基づいて関連付けてもよい。これにより、提案装置は、リコメンド商品と対応する買取候補を提案することができる。
【実施例2】
【0066】
ところで、買取候補を選定する基準は上述したものに限られない。例えば、着用頻度が低いアイテムであっても、誕生日や結婚記念日などのイベントに欠かさず着用するようなアイテムもある。このようなアイテムは、買取候補とすることが適切ではない。一方、過去によく着用していたアイテムであっても、急に着用する機会が少なくなった場合、着用頻度は高くとも買取候補とすることが適切である場合もある。そこで、本実施例においては、アイテムの着用状況の変化や、アイテムの着用と記念日との関係に着目して、ユーザによるアイテムの着用状況により即した買取候補を選定する構成について説明する。
【0067】
[機能ブロック]
まず、本実施例における提案装置の一例について説明する。
図10は、実施例2における提案装置の一例を示す図である。本実施例における提案装置200は、通信部210と、記憶部220と、制御部230とを有する。なお、通信部210については
図2に示す通信部110と同一の内容であるため、詳細な説明は省略する。
【0068】
記憶部220は、アイテムDB221、着用履歴DB222、商品DB223、通知DB224及び記念日DB225を有する。なお、アイテムDB221、商品DB223及び通知DB224については
図2に示すアイテムDB121、商品DB123及び通知DB124とそれぞれ同一の内容であるため、詳細な説明は省略する。
【0069】
本実施例における着用履歴DB222は、実施例1における着用履歴DB122に記憶される情報に加えて、アイテムの着用状況の変化や、アイテムの着用と記念日との関係に関する情報をさらに記憶する。
図11は、実施例2における着用履歴DBの一例を示す図である。
図11に示すように、着用履歴DB222は、
図4に示す情報に加えて、さらに「時期別着用率」と、「過去差分」と、「記念日」とを対応付けて記憶する。なお、着用履歴DB222に記憶される情報は、例えば後に説明するアイテム検出部231により入力される。
【0070】
図11において、「時期別着用率」は、
図3に示すアイテムDB121に記憶された着用時期における、アイテムの着用頻度を記憶する。例えば、着用ID「ABC-W001-2」は、アイテムID「ABC-011」の「ワンピース」が、アイテムDB121に記憶される着用時期「4~7月」の4か月間においては、一月あたり「0.24」回着用されたことを示す。
【0071】
図11において、「過去差分」は、直近の着用時期におけるアイテムの着用頻度と、直近の着用時期より前の着用時期におけるアイテム着用頻度との差分を記憶する。例えば、着用ID「ABC-W111-1」は、アイテムID「ABC-002」の「スカート」について、直近の着用時期における着用頻度が、直近の着用時期より前の着用時期における着用頻度の「0.25」倍に低下したことを示す。なお、アイテムID「ABC-002」の「スカート」の直近の着用時期は、例えば「2016年4~7月」であり、この場合の直近の着用時期より前の着用時期は「2015年4~7月」である。
【0072】
図11において、「記念日」は、アイテムを着用していた日時が、記念日DB225に記憶される記念日に該当するか否かを記憶する。
【0073】
なお、着用頻度の差分は、例えば前着用時期におけるアイテム着用頻度と直近の着用時期におけるアイテムの着用頻度との比率により求められるが、これに限られない。例えば、前着用時期におけるアイテム着用頻度から直近の着用時期におけるアイテムの着用頻度を減算することにより算出してもよい。また、その他の時系列データの解析に関する公知技術を用いて、過去差分を算出してもよい。なお、複数着用時期間での差分を保持するために、以下に示すような値を配列形式で保持してもよい。
【0074】
[[前着用時期におけるアイテム着用頻度-前々着用時期におけるアイテム着用頻度],[直近の着用時期におけるアイテム着用頻度-前着用時期におけるアイテム着用頻度],[2階微分値]]
【0075】
図11において、例えば着用ID「ABC-W111-2」のレコードは、アイテムID「ABC-002」のスカートの着用率は「0.1」であり、そのうち着用時期における着用率は「0.2」であることを示す。さらに、
図11は、アイテムID「ABC-002」のスカートの着用頻度が、前着用時期と比べると、「0.25」倍に低下していること、及び記念日ではない「2017年3月25日」に着用されたことを記憶する。一方、
図11において、例えば着用ID「ABC-W122-1」のレコードは、アイテムID「ABC-003」のアクセサリーが、記念日である「2017年4月5日」に着用されたことを記憶する。
【0076】
次に、記念日DB225は、ユーザ3000の誕生日や結婚記念日などのイベントに関する情報を記憶する。記念日DB225は、例えばユーザごとに一つのテーブルを有する。なお、記念日DB225に記憶される情報は、予めユーザ3000等により入力される。なお、提案装置200が、例えばユーザ3000のブログやSNS(Social Networking service)を参照して記念日を特定し、記念日DB225に記憶するような構成であってもよい。
【0077】
図12は、実施例2における記念日DBの一例を示す図である。
図12に示すように、記念日DB225は、「記念日」と、「イベント」とを、「記念日ID」に対応付けて記憶する。
図12において、「記念日ID」は、記念日を一意に識別する識別子である。「記念日」及び「イベント」は、イベントがある日を記憶する。なお、記念日は、毎年の決まった月日であっても、又は決まった曜日であってもよい。例えば、記念日ID「ABC-D001」は、「毎年4月5日」が、ユーザ3000の「結婚記念日」であることを示す。
【0078】
次に、制御部230は、アイテム検出部231、商品特定部232、買取候補特定部233及び出力部234を有する。なお、商品特定部232及び出力部234については
図2に示す商品特定部132及び出力部134とそれぞれ同一の内容であるため、詳細な説明は省略する。
【0079】
本実施例におけるアイテム検出部231は、ユーザ3000が着用しているアイテムのアイテムIDに対応するレコードを着用履歴DB222に登録する際に、着用日時が記念日に該当するか否かを判定する。アイテム検出部231は、着用日時が記念日に該当すると判定した場合、着用履歴DB222の「記念日」に「1」を記憶する。
【0080】
次に、買取候補特定部233は、着用履歴DB222を参照して買取候補として提示するアイテムを特定する際に、アイテムの「着用率」に加えて、「時期別着用率」と、「過去差分」と、「記念日」とを参照する。なお、買取候補特定部233も、買取候補特定部133と同様に、所定の閾値を用いて買取候補を特定するか否かを判定してもよい。
【0081】
例えば、買取候補特定部233は、買取候補のアイテムを特定する際に、買取候補のアイテムのアイテムIDに対応付けられた着用履歴DB222のレコードのうち、「記念日」が「1」であるレコードが登録されているか否かを判定する。買取候補特定部233は、「記念日」が「1」であるレコードが登録されていると判定した場合、当該アイテムIDのアイテムを、買取候補から除外する。これは、記念日に着用されるアイテムについては、ユーザ3000が愛着を持っている可能性が高いので、たとえ着用率が低くとも、買取候補として提示することは適切ではないためである。
【0082】
また、買取候補特定部233は、買取候補のアイテムを特定する際に、「着用率」が低いアイテムであっても、「時期別着用率」が高いアイテムは、買取候補から除外してもよい。これは、「時期別着用率」が高いアイテムは、例えば梅雨の時期などにユーザ3000に好んで着用される可能性が高いので、たとえ年間を通じての着用率が低くとも、買取候補として提示することは適切ではないためである。
【0083】
一方、買取候補特定部233は、「着用率」の高低にかかわらず、「過去差分」の値が小さいアイテムを、買取候補として提示してもよい。これは、「過去差分」の値が小さいアイテムは、かつてユーザ3000に好んで着用されていたが、現在は着用される機会が少なくなった可能性が高いので、買取候補として提示することが有効であるためである。
【0084】
なお、買取候補特定部233は、これらの複数のパラメータを用いて、機械学習的手法で買取候補を特定してもよい。例えば、買取候補特定部233は、以下のような数式を用いて算出したスコアを用いて、買取候補を特定できる。なお、以下の数式における「w1」、「w2」及び「w3」は、重み付けのために任意に設定されるパラメータである。また、「b」は定数である。
【0085】
買取候補スコア=w1×着用回数+w2×過去差分(1階微分)+w3×記念日着用回数+b
【0086】
[処理の流れ]
次に、本実施例における提案装置200による学習処理について、
図13を用いて説明する。
図13は、実施例2における提案処理の一例を示すフローチャートである。なお、以下の説明において、
図9に示すステップと同じ符号については同様のステップであるため、詳細な説明を省略する。
【0087】
図13に示すように、買取候補特定部233は、選択された商品と同種のアイテムの数が、所定の閾値以上であると判定した場合(S210:Yes)、当該同種のアイテムのうち、着用率が最も低いアイテムを選択する(S311)。次に、買取候補特定部233は、着用履歴DB222を参照し、選択したアイテムに対応付けられた全てのレコードについて、「記念日」が「0」であるか否かを判定する(S312)。買取候補特定部233は、全てのレコードについて、「記念日」が「0」であると判定した場合(S312:Yes)、選択したアイテムを買取候補に決定し(S313)、S212に移行する。
【0088】
一方、買取候補特定部233は、いずれかのレコードについて、「記念日」が「0」ではないと判定した場合(S312:No)、買取候補の提示を行わずに処理を終了する。
【0089】
[効果]
以上説明したように、本実施例における提案装置は、前記各アイテムの特定のイベント時における利用頻度を用いて、前記買取候補を特定する。これにより、結婚記念日や誕生日などのイベントにおけるアイテムの着用状況を考慮して、買取候補を提案することができる。
【0090】
なお、本実施例では記念日での着用回数に着目する構成について説明したが、買取候補を特定する構成はこれに限られない。例えば、着用履歴DB222に雨や雪などの天候に関する情報をさらに記憶してもよい。これにより、着用率は低いが、降雪時などの特定の状況で好んで着用されるアイテムを、買取候補から除外できるので、より的確に買取候補を提案することができる。
【実施例3】
【0091】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。例えば、各実施例において、出力部134が、ユーザ3000がECサイト900において商品を選択した際に買取候補に関する情報を出力する構成について説明したが、実施の形態はこれに限られない。例えば、出力部134は、ユーザ3000が図示しない実店舗に接近したことを検出したタイミングや、ユーザ3000が帰宅したことを検出したタイミングなど、任意のタイミングで買取候補に関する情報を出力してもよい。すなわち、出力部134は、商品特定部132による商品の特定とは無関係に、買取候補に関する情報だけを単独で出力してもよい。また、出力部134は、例えば公知のプッシュ配信技術や電子メールの送信、又はユーザ3000が検索サイト等を利用した場合にリコメンド広告を出稿するなどのその他の方法により、買取候補を出力してもよい。この場合、提案装置100又は200が、商品特定部132を有さず、ユーザ3000が購入を希望する商品又はユーザ3000に対するリコメンド商品を特定しないような構成であってもよい。
【0092】
また、買取候補特定部133は、ユーザ3000による購入予算を予め記憶し、ユーザ3000が商品の購入を希望する際に、商品の販売価格の合計が購入予算を超過する場合に、買取候補を特定するような構成であってもよい。これにより、ユーザ3000が商品の買取を申し出なくとも商品を購入できる場合において、買取候補の提示を抑制できる。
【0093】
また、買取候補特定部133は、着用履歴DB122を参照して買取候補のアイテムの着用回数及び購入日を特定し、特定された着用回数及び購入日を用いて買取候補のアイテムの買取価格を算出してもよい。
【0094】
また、買取候補特定部133は、ユーザ3000が購入を希望する商品とは無関係に、ユーザ3000が保有する全てのアイテムの中から買取候補を特定するような構成であってもよい。さらに、買取候補特定部133が特定するアイテムは1つに限らず、複数のアイテムを買取候補として特定してもよい。ユーザ3000は、保有するアイテムの買取金額を新たな購入代金に補充できるので、買取候補の対象を多く提示することで、ユーザ3000が購入代金の不足により商品の購入を断念することを抑制できる。
【0095】
また、上述した各実施例では、買取候補特定部133が、商品特定部132により特定された商品に基づいて、買取候補を特定するが、逆に、商品特定部132が、ユーザに対するリコメンド商品を、選定された買取候補を用いて決定してもよい。例えば、ユーザ3000に対する買取候補として「靴」が特定された場合、買取候補の靴に代替する靴を、リコメンド商品として決定してもよい。これにより、商品特定部132は、ユーザ3000による商品買取に応じた買い替え需要を喚起することができる。
【0096】
さらに、買取候補特定部133が買取候補を特定する条件は上述した例に限られず、例えば買取候補を購入日や購入価格などのその他の条件に基づいて特定してもよい。また、着用回数が多過ぎる場合は、アイテムが消耗して買取対象とすることが適切ではない場合もあるので、買取候補特定部133は、着用回数が多過ぎるアイテムを買取候補から除外してもよい。これにより、例えば買取価格が高いものだけを買取候補として提示するなど、よりユーザ3000の買取ニーズに即した買取候補を提案することができる。なお、アイテムの消耗度合を特定するために、例えばアイテムを洗濯する洗濯機等にもセンサ600を付与するような構成であってもよい。
【0097】
なお、例えば旅行先において洋服等のアイテムを着用する際に、ユーザ3000が外出時にはアイテムを着用せずに、旅行カバンやスーツケース等に収納して外出する場合がある。この場合、例えばカメラ700においては、ユーザ3000によるアイテムの着用を検出することができない。そこで、センサ600を旅行カバンやスーツケース等に付与し、センサ600がアイテムに付与されたタグの識別情報を受信するような構成であってもよい。
【0098】
この場合において、提案装置100のアイテム検出部131は、旅行カバンやスーツケース等に付与されたセンサ600からアイテムの識別情報を受信した場合に、当該アイテムが着用されたと判定する。また、アイテム検出部131は、カメラ700から、センサ600が付与された旅行カバンやスーツケース等が撮影された画像を取得した場合に、当該アイテムが着用されたと判定してもよい。これにより、アイテム検出部131は、ユーザ3000が外出時には着用せずに持ち出したアイテムについても検出することができる。
【0099】
さらに、センサ600の検出範囲は、収納されたアイテムが旅行カバンやスーツケース等から取り出され、ユーザ3000により着用されたことを検出できるように調整されてもよい。例えば、ユーザ3000が旅行カバンやスーツケース等を開き、アイテムを取り出して着用した場合、センサ600とアイテムとの距離が変動すると考えられる。そこで、センサ600は、旅行カバンやスーツケース等が開かれたことや、収納されたアイテムの識別情報との距離が所定の範囲以上変動したことを検出してもよい。これにより、アイテム検出部131は、ユーザ3000が外出時には着用せずに持ち出したアイテムを実際に着用したか否かをより精度よく検出することができる。
【0100】
また、出力部134は、ユーザ3000の携帯端末3100に買取候補を出力する際に、ユーザ3000の家族や友人等に対して、買取候補に基づいて特定したリコメンド商品に関する情報を送信してもよい。また、記念日に関する情報を、買取候補の特定の際に加えて、リコメンド商品の特定の際に用いてもよい。これにより、ユーザ3000による記念日に向けた購入需要や、ユーザ3000へのプレゼントの購入需要を喚起できる。
【0101】
また、買取候補を特定する際に、過去のユーザ3000やその他のユーザへの買取候補の提案と、実際にユーザから買取の申し出があったか否かとの関係をさらに用いてもよい。例えば、類似するアイテムについて、買取の申し出があった割合が高い場合、買取候補特定部133が、当該アイテムを買取候補として特定してもよい。
【0102】
なお、上述した提案装置100又は200の機能ブロックの一部は、外部のコンピュータに実装されていてもよい。例えば、提案装置100がアイテムDB121を有さない代わりに、ユーザ3000が保有するアイテムに関する情報をユーザ3000の携帯端末3100又は図示しないその他のデータベースから取得するような構成であってもよい。
【0103】
[システム]
この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【0104】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、
図2に示す商品特定部132と買取候補特定部133とを統合してもよい。また、
図2に示す着用履歴DB122を、着用日時及び帰宅日時を記憶するテーブルと、アイテムの着用頻度を記憶するテーブルとに分散してもよい。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【0105】
[ハードウェア構成]
図14は、コンピュータのハードウェア構成例を示す図である。
図14に示すように、コンピュータ500は、各種演算処理を実行するCPU501と、ユーザからのデータの入力を受け付ける入力装置502と、ディスプレイ503とを有する。また、コンピュータ500は、映像を撮影するカメラ504と、ネットワークを介して他のコンピュータとの間でデータの授受を行うインタフェース装置505とを有する。また、コンピュータ500は、各種情報を一時記憶するRAM506と、ハードディスク装置507とを有する。そして、各装置501~507は、バス508に接続される。
【0106】
ハードディスク装置507は、検出プログラム507a、特定プログラム507b、出力プログラム507cを有する。CPU501は、検出プログラム507a、特定プログラム507b、出力プログラム507cを読み出してRAM506に展開する。検出プログラム507aは、検出プロセス506aとして機能する。特定プログラム507aは、特定プロセス506bとして機能する。出力プログラム507cは、出力プロセス506cとして機能する。
【0107】
検出プロセス506aは、アイテム検出部131に対応する。特定プロセス506bは、商品特定部132及び買取候補特定部133に対応する。出力プロセス506cは、出力部134に対応する。
【0108】
なお、検出プログラム507a、特定プログラム507b、出力プログラム507cについては、必ずしも最初からハードディスク装置507に記憶させておかなくても良い。例えば、コンピュータ500に挿入されるフレキシブルディスク(FD)、CD-ROM、DVDディスク、光磁気ディスク、ICカードなどの「可搬用の物理媒体」に各プログラムを記憶させておく。そして、コンピュータ500が各プログラム507a~507cを読み出して実行するようにしてもよい。
【0109】
以上の各実施例を含む実施形態に関し、さらに以下の付記を開示する。
【0110】
(付記1)ユーザが所有する、少なくとも1つのユーザ商品と対応づけて記憶された、前記ユーザ商品の利用回数に基づいて、少なくとも1つのユーザ商品を買取候補商品として特定する買取候補特定部と、
前記買取候補商品に関連付けられる、前記ユーザに対して新たに購入を提案する提案商品の情報と併せて、前記買取候補商品に関する情報を出力する出力部と、
を有することを特徴とする提案装置。
【0111】
(付記2)前記ユーザ商品に付与された識別情報を用いて、前記ユーザ商品が利用されたか否かを判定する検出部をさらに有することを特徴とする付記1に記載の提案装置。
【0112】
(付記3)前記検出部は、所定の地点において、前記識別情報を受信した場合、当該ユーザ商品が利用されたと判定することを特徴とする付記2に記載の提案装置。
【0113】
(付記4)前記検出部は、前記ユーザ商品の収納場所において、所定の時間又は所定の回数連続して前記識別情報を受信しない場合、当該ユーザ商品が利用されたと判定することを特徴とする付記2又は3に記載の提案装置。
【0114】
(付記5)前記検出部は、前記ユーザ商品が所定のバッグ又はケースに入れられたことを検出した場合に、当該ユーザ商品が利用されたと判定することを特徴とする付記2乃至4のいずれか1つに記載の提案装置。
【0115】
(付記6)前記検出部は、撮影された画像において前記ユーザ商品が検出された場合、当該ユーザ商品が利用されたと判定することを特徴とする付記2乃至5のいずれか1つに記載の提案装置。
【0116】
(付記7)前記買取候補特定部は、前記買取候補商品を、前記提案商品の名称、カテゴリ、前記提案商品に関する説明文、前記提案商品の画像及び販売金額のうち少なくともいずれかを含む前記提案商品に関する情報に基づいて特定し、
前記出力部は、前記買取候補商品の名称、カテゴリ、前記買取候補商品に関する説明文、前記買取候補商品の画像及び買取金額のうち少なくともいずれかを含む前記買取候補商品に関する情報及び前記提案商品に関する情報を出力することを特徴とする付記1乃至6のいずれか1つに記載の提案装置。
【0117】
(付記8)前記提案商品を、特定された前記買取候補商品に関する情報に基づいて関連付ける商品特定部をさらに有することを特徴とする付記7に記載の提案装置。
【0118】
(付記9)前記商品特定部は、前記提案商品として、前記ユーザに対してリコメンドする商品を選定し、
前記買取候補特定部は、選定された前記提案商品に関する情報に基づいて、前記買取候補商品を特定することを特徴とする付記8に記載の提案装置。
【0119】
(付記10)前記買取候補特定部は、ユーザが商品を選択する際に、ユーザが設定した金額が選択された前記商品の価格に満たない場合に、前記買取候補商品を特定することを特徴とする付記1乃至9のいずれか1つに記載の提案装置。
【0120】
(付記11)前記買取候補特定部は、特定のイベント時における前記買取候補商品として特定されたユーザ商品の利用頻度を用いて、前記買取候補商品を特定することを特徴とする付記1乃至10のいずれか1つに記載の提案装置。
【0121】
(付記12)前記買取候補特定部は、前記買取候補商品の買取金額を、前記買取候補商品として特定されたユーザ商品の利用回数に応じて算出することを特徴とする付記1乃至11のいずれか1つに記載の提案装置。
【0122】
(付記13)前記特定部は、前記ユーザ商品が利用されたと判定した場合、前記ユーザ商品に関する情報が記憶部に登録されているか否かを判定し、前記ユーザ商品に関する情報が前記記憶部に登録されていないと判定した場合は前記ユーザ商品に関する情報を新たに前記記憶部に登録し、前記ユーザ商品に関する情報が前記記憶部に登録されていると判定した場合は、前記ユーザ商品の利用回数を増加させることを特徴とする付記1乃至11のいずれか1つに記載の提案装置。
【0123】
(付記14)ユーザが所有する、少なくとも1つのユーザ商品と対応づけて記憶された、前記ユーザ商品の利用回数に基づいて、少なくとも1つのユーザ商品を買取候補商品として特定し、
前記買取候補商品に関連付けられる、前記ユーザに対して新たに購入を提案する提案商品の情報と併せて、前記買取候補商品に関する情報を出力する
処理をコンピュータが実行することを特徴とする提案方法。
【0124】
(付記15)ユーザが所有する、少なくとも1つのユーザ商品と対応づけて記憶された、前記ユーザ商品の利用回数に基づいて、少なくとも1つのユーザ商品を買取候補商品として特定し、
前記買取候補商品に関連付けられる、前記ユーザに対して新たに購入を提案する提案商品の情報と併せて、前記買取候補商品に関する情報を出力する
処理をコンピュータに実行させることを特徴とする提案プログラム。
【符号の説明】
【0125】
100、200 提案装置
110、210 通信部
120、220 記憶部
121、221 アイテムDB
122、222 着用履歴DB
123、223 商品DB
124、224 通知DB
225 記念日DB
130、230 制御部
131、231 アイテム検出部
132、232 商品特定部
133、233 買取候補特定部
134、234 出力部