JP7136730B2 - 商品推奨装置及び情報処理プログラム - Google Patents

Description

本発明の実施形態は、商品推奨装置及び情報処理プログラムに関する。

購買者に対して、当該購買者が設定した嗜好に適合する商品を推奨する仕組みは、種々考えられている。
例えば、商品のカテゴリとしての「カレールウ」に対して、その嗜好の項目である「辛さ」について１～５の５段階の指標値を定めて、購買者は自らの嗜好に合うと考える指標値を設定する。また、「カレールウ」に属する商品のそれぞれに対して、製造者や販売店などの販売側が、その商品の「辛さ」についての指標値を定めておく。そして「カレールウ」に関する商品を購買者に推奨すべきときには、その購買者が定めた指標値により近い指標値が設定されている商品を推奨する商品として決定することが考えられる。

しかしながら、購買者による指標値の設定は、あくまでも購買者の主観により、商品に対して定められる指標値とは必ずしも一致しない。従って、上記のようにして決定された商品を購買者に推奨しても、その商品が購買者の嗜好に適合した商品ではないこともあった。
このような事情から、購買者の嗜好に適合した商品を推奨することが望まれていた。

特開２００４－２６４５５７号公報

本発明が解決しようとする課題は、購買者の嗜好に適合した商品を推奨できる商品推奨装置及び情報処理プログラムを提供することである。

実施形態の商品推奨装置は、取得手段、決定手段、推奨手段、設定手段及び変更手段を備える。取得手段は、推奨対象となる商品カテゴリの嗜好に関わる指標値であって購買者により定められた嗜好指標値を取得する。決定手段は、商品カテゴリに属する商品であって、当該商品の嗜好に関わる指標値として予め定められた商品指標値が取得手段により取得された嗜好指標値と所定の関係にある商品を推奨商品として決定する。推奨手段は、決定手段により決定された推奨商品を購買者に推奨する。設定手段は、推奨商品が推奨手段による推奨後に購買者により購買され、さらにその後に、推奨商品に関する商品指標値とは異なる商品指標値が定められており、かつ商品カテゴリに属する推奨商品とは異なる１つ又は複数の別商品が購買者により継続して購買された場合に、別商品に定められた商品指標値に基づいて商品カテゴリの嗜好に関わる指標値を評価指標値として設定する。変更手段は、設定手段により設定された評価指標値と嗜好指標値との差が小さくなるように嗜好指標値を変更する。

一実施形態に係るレシートサーバの要部回路構成を示すブロック図。 図１中の販売側指標テーブルに含まれる商品レコードの構造を模式的に示す図。 図１中の購買側指標テーブルに含まれる嗜好レコードの構造を模式的に示す図。 図１中の管理テーブルに含まれる管理レコードの構造を模式的に示す図。 図１中のプロセッサによる推奨処理のフローチャート。 図５中のＡＣＴ６にて管理テーブルに追加される管理レコードの構成を示す図。 図１中のプロセッサによる管理処理のフローチャート。 図７中のＡＣＴ１３にて更新された後の管理レコードの構成を示す図。 図７中のＡＣＴ１６にて更新された後の管理レコードの構成を示す図。 図７中のＡＣＴ１８にて更新された後の管理レコードの構成を示す図。

以下、実施の形態の一例について図面を用いて説明する。なお、本実施の形態では、商品推奨装置としての機能を備えたレシートサーバを例に説明する。
図１は本実施形態に係るレシートサーバ１の要部回路構成を示すブロック図である。

レシートサーバ１は、プロセッサ１１、メインメモリ１２、補助記憶デバイス１３、通信インタフェース１４及び伝送路１５等を備える。プロセッサ１１と、メインメモリ１２、補助記憶デバイス１３及び通信インタフェース１４とは、伝送路１５によって接続される。
レシートサーバ１においては、プロセッサ１１、メインメモリ１２及び補助記憶デバイス１３を伝送路１５で接続することによって、レシートサーバ１を制御するための情報処理を行うコンピュータを構成する。

プロセッサ１１は、上記コンピュータの中枢部分に相当する。プロセッサ１１は、オペレーティングシステム、ミドルウェア及びアプリケーションプログラムなどの情報処理プログラムに従って、レシートサーバ１としての各種の機能を実現するべく各部を制御する。

メインメモリ１２は、上記コンピュータの主記憶部分に相当する。メインメモリ１２は、不揮発性のメモリ領域と揮発性のメモリ領域とを含む。メインメモリ１２は、不揮発性のメモリ領域では上記の情報処理プログラムを記憶する。またメインメモリ１２は、プロセッサ１１が各部を制御するための処理を実行する上で必要なデータを不揮発性又は揮発性のメモリ領域で記憶する場合もある。メインメモリ１２は、揮発性のメモリ領域を、プロセッサ１１によってデータが適宜書き換えられるワークエリアとして使用する。

補助記憶デバイス１３は、上記コンピュータの補助記憶部分に相当する。補助記憶デバイス１３としては、例えばＥＥＰＲＯＭ（electric erasable programmable read-only memory）、ＨＤＤ（hard disc drive）又はＳＳＤ（solid state drive）を単独で、あるいは複数組み合わせて用いることができる。補助記憶デバイス１３は、プロセッサ１１が各種の処理を行う上で使用するデータや、プロセッサ１１での処理によって生成されたデータを保存する。補助記憶デバイス１３は、上記の情報処理プログラムを記憶する場合もある。本実施形態では、補助記憶デバイス１３は、レシートサーバ１としての動作のためのアプリケーションプログラム（以下、レシートサーバアプリと称する）ＡＰ１と、後述する情報処理について記述したアプリケーションプログラム（以下、リコメンドアプリと称する）ＡＰ２とを記憶する。また補助記憶デバイス１３は、取引データベースＤＢ１、販売側指標テーブルＴＤ１、購買側指標テーブルＴＤ２及び管理テーブルＴＤ３を記憶する。取引データベースＤＢ１は、ＰＯＳシステム２から収集した取引データに含まれるデータを集積したデータベースである。取引データベースＤＢ１は、購買者の会員コードと、当該購買者が購買した商品の商品コードと、購買日時とを関連付けて少なくとも表す。販売側指標テーブルＴＤ１、購買側指標テーブルＴＤ２及び管理テーブルＴＤ３については後述する。

通信インタフェース１４は、ＰＯＳシステム２及び購買者端末３などと通信ネットワーク４を介してデータ通信するためのインタフェースである。通信インタフェース１４としては、例えばインターネットを介したデータ通信を行うための周知の通信デバイスを利用できる。
伝送路１５は、アドレスバス、データバス及び制御信号線等を含み、接続された各部の間で授受されるデータ及び制御信号を伝送する。

レシートサーバ１は、例えば汎用のコンピュータ装置を基本ハードウェアとして用いることができる。このときに典型的には、レシートサーバアプリＡＰ１及びリコメンドアプリＡＰ２が補助記憶デバイス１３に記憶されない状態のコンピュータ装置とレシートサーバアプリＡＰ１及びリコメンドアプリＡＰ２とが個別にレシートサーバ１の運営者に譲渡される。レシートサーバアプリＡＰ１及びリコメンドアプリＡＰ２の譲渡は、磁気ディスク、光磁気ディスク、光ディスク、半導体メモリなどのようなリムーバブルな記録媒体に記録して、あるいはネットワークを介したダウンロードにより実現できる。そしてこの場合は、レシートサーバ１の管理者又はレシートサーバ１の設置作業者などによる操作に応じて、レシートサーバアプリＡＰ１及びリコメンドアプリＡＰ２が補助記憶デバイス１３に書き込まれる。なお、レシートサーバアプリＡＰ１及びリコメンドアプリＡＰ２の譲渡及び補助記憶デバイス１３への書き込みは、別々に行われても構わない。

図２は販売側指標テーブルＴＤ１に含まれるレコードデータ（以下、商品レコードと称する）ＲＤ１の構造を模式的に示す図である。
販売側指標テーブルＴＤ１は、図２に示すような構造の商品レコードＲＤ１を少なくとも１つ含んだテーブルデータである。１つの商品レコードＲＤ１は、購買者への推奨の対象になり得る１つの商品に関連づけられている。商品レコードＲＤ１は、フィールドＦ１１，Ｆ１２，Ｆ１３，Ｆ１４を含む。商品レコードＲＤ１は、フィールドＦ１５以降のフィールドを含む場合もある。

フィールドＦ１１には、当該商品レコードＲＤ１が関連付けられた商品を識別するための商品コードがセットされる。フィールドＦ１２には、当該商品レコードＲＤ１が関連付けられた商品が属する商品カテゴリを識別するためのカテゴリコードがセットされる。フィールドＦ１３には、上記の商品カテゴリの名称（以下、カテゴリ名と称する）がセットされる。フィールドＦ１４には、当該商品レコードＲＤ１が関連付けられた商品の嗜好に関わる項目の名称（以下、嗜好項目名と称する）の１つがセットされる。フィールドＦ１４に嗜好項目名としてセットされるデータは、例えば「辛さ」「堅さ」又は「スパイシーさ」などである。フィールドＦ１５には、当該商品レコードＲＤ１が関連付けられた商品に関してフィールドＦ１４にセットされた嗜好項目名について設定された指標値（以下、商品指標値と称する）がセットされる。フィールドＦ１６には、フィールドＦ１４とは別の１つの嗜好項目名がセットされる。フィールドＦ１７には、当該商品レコードＲＤ１が関連付けられた商品に関してフィールドＦ１６にセットされた嗜好項目名について設定された商品指標値がセットされる。かくしてフィールドＦ１４以降の各フィールドは、２つずつがセットとなって、嗜好項目名と商品指標値とがセットされる。そしてフィールドＦ１６以降にいくつのフィールドが含まれるかは、当該商品レコードＲＤ１が関連付けられた商品に対して商品指標値が設定される嗜好項目名の数に応じて変化する。なお、商品指標値は、商品の性質を考慮して、その製造業者又は販売業者などの販売側にて適宜に設定される。

本実施形態において商品カテゴリとは、例えば「カレールウ」のように、互いに代替できる商品を纏めるカテゴリである。そして、例えばＡ社製のカレールウの甘口、Ａ社製のカレールウの中辛、Ａ社製のカレールウの辛口、Ｂ社製のカレールウの甘口、Ｂ社製のカレールウの辛口などが、「カレールウ」なる商品カテゴリに属する商品となる。

図３は購買側指標テーブルＴＤ２に含まれるレコードデータ（以下、嗜好レコードと称する）ＲＤ２の構造を模式的に示す図である。
購買側指標テーブルＴＤ２は、図３に示すような構造の嗜好レコードＲＤ２を少なくとも１つ含んだテーブルデータである。１つの嗜好レコードＲＤ２は、電子レシートサービスの会員と商品カテゴリとの組み合わせに関連づけられている。嗜好レコードＲＤ２は、フィールドＦ２１，Ｆ２２，Ｆ２３，Ｆ２４，Ｆ２５を含む。嗜好レコードＲＤ２は、フィールドＦ２６以降のフィールドを含む場合もある。

フィールドＦ２１には、当該嗜好レコードＲＤ２が関連付けられた会員を識別するための会員コードがセットされる。フィールドＦ２２には、当該嗜好レコードＲＤ２が関連付けられた商品カテゴリのカテゴリコードがセットされる。フィールドＦ２３には、当該嗜好レコードＲＤ２が関連付けられた商品カテゴリのカテゴリ名がセットされる。フィールドＦ２４には、当該嗜好レコードＲＤ２が関連付けられた商品カテゴリに関する嗜好項目名の１つがセットされる。フィールドＦ２５には、当該嗜好レコードＲＤ２が関連付けられた商品カテゴリに関してフィールドＦ２４にセットされた嗜好項目名について設定された指標値（以下、嗜好指標値と称する）がセットされる。フィールドＦ２６には、フィールドＦ２４とは別の１つの嗜好項目名がセットされる。フィールドＦ２７には、当該嗜好レコードＲＤ２が関連付けられた商品カテゴリに関してフィールドＦ２６にセットされた嗜好項目名について設定された商品指標値がセットされる。かくしてフィールドＦ２４以降の各フィールドは、２つずつがセットとなって、嗜好項目名と嗜好指標値とがセットされる。そしてフィールドＦ２６以降にいくつのフィールドが含まれるかは、当該嗜好レコードＲＤ２が関連付けられた商品カテゴリに対して嗜好指標値が設定される嗜好項目名の数に応じて変化する。なお、嗜好指標値は、会員によって、会員自らの嗜好に応じて適宜に設定される。嗜好指標値は、後述するように補正される場合もある。嗜好指標値は、会員によって再設定されてもよい。

図４は管理テーブルＴＤ３に含まれるレコードデータ（以下、管理レコードと称する）ＲＤ３の構造を模式的に示す図である。
管理テーブルＴＤ３は、図４に示すような構造の管理レコードＲＤ３を少なくとも１つ含んだテーブルデータである。１つの管理レコードＲＤ３は、会員とその会員に対して推奨した商品との組み合わせに関連づけられている。管理レコードＲＤ３は、フィールドＦ３１，Ｆ３２，Ｆ３３，Ｆ３４を含む。管理レコードＲＤ３は、フィールドＦ３５以降のフィールドを含む場合もある。管理レコードＲＤ３の各フィールドには、プロセッサ１１が後述する情報処理によって各種のデータをセットする。そこで管理レコードＲＤ３の各フィールドにセットされるデータについては後述する。

次に以上のように構成されたレシートサーバ１の動作について説明する。なお、以下に説明する各種の処理の内容は一例であって、一部の処理の順序の変更、一部の処理の省略、あるいは別の処理の追加などは適宜に可能である。

本実施形態におけるレシートサーバ１の動作の特徴的なところは、収集した取引データを参照して、購買者による購買実績を考慮しながら購買者に商品を推奨するための動作である。そして、例えばレシートサーバアプリＡＰ１に従ってプロセッサ１１が実行する情報処理、すなわち、ＰＯＳシステム２から取引データを収集し、取引データベースＤＢ１を管理するための情報処理に関しては、例えば既存の電子レシートシステムで行われている動作を流用できる。そこで以下においては、これら既存の動作を流用できる動作についての説明は省略する。なお取引データは、購買者が販売者から商品を購買する取引に関するデータであり、購買者に対して電子レシートサービスを利用するために決定された会員コードと、購買者が購買した商品の商品コードとを少なくとも含む。

プロセッサ１１は、予め定められた推奨タイミングになると、リコメンドアプリＡＰ２に従って以下に説明する情報処理（以下、推奨処理と称する）を実行する。推奨タイミングは例えば、予めスケジュールされた日時が到来したタイミングである。推奨タイミングは例えば、レシートサーバ１の管理者などにより開始指示がなされたことを検知したタイミングである。推奨タイミングは例えば、購買者端末３から商品の推奨が要求されたことを検知したタイミングである。推奨タイミングは例えば、購買者が特定の商品を購買した場合、あるいは購買者が店舗に入店した場合などのような予め定めた動作を購買者が行ったことを検知したタイミングである。どのようなタイミングを推奨タイミングとするかは、レシートサーバ１の設計者、リコメンドアプリＡＰ２の作成者、あるいはレシートサーバ１の管理者などにより適宜に定められてよい。

図５はプロセッサ１１による推奨処理のフローチャートである。
ＡＣＴ１としてプロセッサ１１は、推奨の対象とする商品カテゴリを対象カテゴリとして決定する。プロセッサ１１は例えば、当該推奨処理を開始した推奨タイミングに対して予めスケジュールされた商品カテゴリを対象カテゴリとする。プロセッサ１１は例えば、管理者又は購買者が指定した商品カテゴリを対象カテゴリとする。プロセッサ１１は例えば、予め定められた商品カテゴリのリストの中から、予め定められたルールに従って、あるいはランダムに選択した商品カテゴリを対象カテゴリとする。どのように対象カテゴリを決定するかは、上記の設計者、作成者又は管理者などにより適宜に定められてよい。

ＡＣＴ２としてプロセッサ１１は、推奨する対象としての購買者（以下、対象購買者と称する）を会員の中から決定する。プロセッサ１１は例えば、開始タイミングに対して予めスケジュールされた会員を対象購買者とする。プロセッサ１１は例えば、管理者が指定した会員を対象購買者とする。プロセッサ１１は例えば、推奨を要求した会員を対象購買者とする。プロセッサ１１は例えば、予め定められた会員のリストの中から、予め定められたルールに従って、あるいはランダムに選択した会員を対象購買者とする。どのように対象購買者を決定するかは、上記の設計者、作成者又は管理者などにより適宜に定められてよい。

ＡＣＴ３としてプロセッサ１１は、上記の決定した対象カテゴリと購買者である会員との組み合わせに関連付けられた嗜好レコードＲＤ２を購買側指標テーブルＴＤ２から抽出する。プロセッサ１１は例えば、ＡＣＴ１にて決定した対象カテゴリのカテゴリコードがフィールドＦ２２にセットされ、かつＡＣＴ２にて決定した対象購買者の会員コードがフィールドＦ２１にセットされている嗜好レコードＲＤ２を購買側指標テーブルＴＤ２から抽出する。これによりプロセッサ１１は、推奨対象となる商品カテゴリの嗜好に関わる指標値であって購買者により定められた嗜好指標値を取得することになる。かくしてリコメンドアプリＡＰ２に基づく情報処理をプロセッサ１１が実行することによって、プロセッサ１１を中枢部分とするコンピュータは取得手段として機能する。

ＡＣＴ４としてプロセッサ１１は、今回の推奨処理により推奨する商品（以下、推奨商品と称する）を決定する。ここでプロセッサ１１は、ＡＣＴ３にて抽出した嗜好レコードＲＤ２のフィールドＦ２４以降の各フィールドにセットされたデータを参照する。またプロセッサ１１は、対象カテゴリに属する商品のそれぞれに関連付けられた商品レコードＲＤ１のフィールドＦ１４以降の各フィールドにセットされたデータを参照する。そして、プロセッサ１１は、予め定められたアルゴリズムによって推奨商品を決定する。かくしてリコメンドアプリＡＰ２に基づく情報処理をプロセッサ１１が実行することによって、プロセッサ１１を中枢部分とするコンピュータは推奨商品を決定する決定手段として機能する。

プロセッサ１１は例えば、次のような条件で、１つの商品レコードＲＤ１を絞り込む。そしてプロセッサ１１は、その商品レコードＲＤ１のフィールドＦ１１にセットされた商品コードにより識別される商品を推奨商品として決定する。
(1) 対象カテゴリのカテゴリコードがフィールドＦ１２にセットされている。
(2) ＡＣＴ３にて抽出した嗜好レコードＲＤ２のフィールドＦ２４以降の各フィールドにセットされた嗜好項目名と同じ嗜好項目名（以下、共通項目名と称する）がフィールドＦ１４以降の各フィールドのいずれかにセットされている。かつ、商品レコードＲＤ１において共通項目名がセットされているフィールドの次のフィールドにセットされた商品指標値が、嗜好レコードＲＤ２において共通項目名がセットされているフィールドの次のフィールドにセットされた嗜好指標値と一致する。
(3) 商品指標値が嗜好指標値と一致する共通項目名の数がより多い。
(4) 商品レコードＲＤ１において共通項目名がセットされているフィールドの次のフィールドにセットされた商品指標値が、嗜好レコードＲＤ２において共通項目名がセットされているフィールドの次のフィールドにセットされた嗜好指標値と異なる共通項目の数がより少ない。
(5) 共通項目名とは別の嗜好項目名の数がより少ない。
(6) ランダム選択。

なお、上記の絞り込みの条件には、商品レコードＲＤ１毎に設定された優先度、あるいは嗜好項目名毎に設定された重要度などの別の条件を加味してもよい。
また、上記の(1)～(5)に代えて例えば「個々の共通項目名に関する商品指標値と嗜好指標値との差の合計がより少ない。」を適用するなど、推奨商品を決定するアルゴリズムは、レシートサーバ１の設計者、リコメンドアプリＡＰ２の作成者、あるいはレシートサーバ１の管理者などにより適宜に定められてよい。

具体例として、カテゴリ名が「カレールウ」である商品カテゴリに関する嗜好項目名「辛さ」に対応する嗜好指標値として、「１」～「５」の５段階の指標値のうちの「５」を購買者が設定しているとする。この場合にプロセッサ１１は、この購買者に関しては、カテゴリ名が「カレールウ」である商品カテゴリに属する商品のうちで、嗜好項目名「辛さ」に対応する商品指標値として「５」が設定されている商品のうちの１つを推奨商品とする。
ただし、プロセッサ１１は、条件に合致する複数の商品を推奨商品として決定してもよい。

ＡＣＴ５としてプロセッサ１１は、推奨商品を対象購買者に知らせるための通知処理を実行する。この通知処理は例えば、推奨商品を対象購買者に対してアピールする内容の電子メールを、対象購買者に予め紐付けられたメールアドレスに宛てて送信する処理とする。通知処理は例えば、推奨商品を対象購買者に対してアピールする内容の通知画面の表示を、対象購買者に予め紐付けられた購買者端末３に対して要求する、いわゆるプッシュ通知のための処理とする。あるいは通知処理は例えば、推奨商品を対象購買者に対してアピールする内容のウェブページを購買者端末３で表示させるための処理とする。この通知処理によって、推奨商品が購買者に推奨される。かくしてリコメンドアプリＡＰ２に基づく情報処理をプロセッサ１１が実行することによって、プロセッサ１１を中枢部分とするコンピュータは推奨手段として機能する。

ＡＣＴ６としてプロセッサ１１は、管理テーブルＤＴ３を更新する。つまりプロセッサ１１は、今回行った商品の推奨における対象購買者と推奨商品との組み合わせに関連づけられる管理レコードＲＤ３を管理テーブルＤＴ３に追加する。

図６はＡＣＴ６にて管理テーブルＤＴ３に追加される管理レコードＲＤ３の構成を示す図である。なお、図６は１つの管理レコードＲＤ３の遷移を表すいくつかの図面のうちの１つである。しかしながら、これら複数の図面に示すそれぞれ異なる状態の管理レコードＲＤ３の区別を容易とするため、便宜的に符号を「ＲＤ３－１」としている。
図６に示す管理レコードＲＤ３－１は、対象購買者の会員コードが「0023561」であり、推奨商品の商品コードが「4901234567890」であり、通知処理が２０１９年１月１日の１０時００分に行われた場合の一例である。

このためプロセッサ１１はＡＣＴ６においては、「0023561」、「4901234567890」及び「2019/01/01 10:00」をフィールドＦ３１，Ｆ３２，Ｆ３３にそれぞれセットするとともに、購買フラグをリセット状態とした図６に示すような管理レコードＲＤ３－１を生成する。そしてプロセッサ１１は、この管理レコードＲＤ３－１を新たに含むように管理テーブルＤＴ３を更新する。
そしてプロセッサ１１は、管理テーブルＤＴ３を更新し終えたならば、推奨処理を終了する。

一方でプロセッサ１１は、予め定められた管理タイミングになると、リコメンドアプリＡＰ２に従って以下に説明する情報処理（以下、管理処理と称する）を実行する。プロセッサ１１は例えば、管理テーブルＤＴ３に含まれる管理レコードＤＲ３を順次に対象として管理処理を繰り返し行う。この場合において管理タイミングは、プロセッサ１１が１つの管理レコードＤＲ３を対象とした管理処理を終え、別の管理レコードＤＲ３を対象とした管理処理を開始することが可能となったタイミングである。なおプロセッサ１１は、複数の管理処理を並列して実行してもよい。どのようなタイミングを管理タイミングとするかは、レシートサーバ１の設計者、リコメンドアプリＡＰ２の作成者、あるいはレシートサーバ１の管理者などにより適宜に定められてよい。

図７はプロセッサ１１による管理処理のフローチャートである。なお、この図７に関する以下の説明においては、単に「管理レコードＲＤ３」と記載した場合は、管理処理の対象としている管理レコードＲＤ３を指すこととする。
ＡＣＴ１１としてプロセッサ１１は、管理レコードＲＤ３のフィールドＦ３４にセットされた購買フラグがセット状態であるか否かを確認する。そしてプロセッサ１１は、購買フラグがリセット状態であるならばＮＯと判定し、ＡＣＴ１２へと進む。

ＡＣＴ１２としてプロセッサ１１は、管理レコードＲＤ３が関連付けられている推奨商品が推奨後に対象購買者によって購買済みであるか否かを確認する。プロセッサ１１は例えば、管理レコードＲＤ３のフィールドＦ３２にセットされた商品コードが、管理レコードＲＤ３のフィールドＦ３１にセットされた会員コードに関連付けて取引データベースＤＢ１に含まれ、かつその購買日時が管理レコードＲＤ３のフィールドＦ３３にセットされた実施日時よりも後である場合にＹＥＳと判定し、ＡＣＴ１３へと進む。

ＡＣＴ１３としてプロセッサ１１は、管理レコードＲＤ３を更新する。つまりプロセッサ１１は例えば、管理レコードＲＤ３のフィールドＦ３４にセットされた購買フラグをセット状態に変更する。またプロセッサ１１は例えば、管理レコードＲＤ３にフィールドＦ３５を追加し、当該フィールドＦ３５に取引データベースＤＢ１に示された推奨商品の購買日時をセットする。

図８はＡＣＴ１３にて更新された後の管理レコードＲＤ３の構成を示す図である。なお図８は、更新前が図６に示す管理レコードＲＤ３－１である場合の更新例を表し、便宜的に符号を「ＲＤ３－２」としている。
図８に示す管理レコードＲＤ３－２は、推奨商品が２０１９年１月５日の１７時２３分に購買された場合の一例である。
このためプロセッサ１１はＡＣＴ１３においては、購買フラグをセット状態に変更するとともに、「2019/01/05 17:23」をセットしたフィールドＦ３５を管理レコードＲＤ３－１に追加して管理レコードＲＤ３－２としている。

そしてプロセッサ１１は、ＡＣＴ１３にて管理レコードＲＤ３を更新し終えたならば、管理処理を終了する。なおプロセッサ１１は例えば、管理レコードＲＤ３のフィールドＦ３２にセットされた商品コードが、管理レコードＲＤ３のフィールドＦ３１にセットされた会員コードに関連付けて取引データベースＤＢ１に含まれていない場合、あるいはそのような商品コードが取引データベースＤＢ１に含まれているものの、その購買日時が管理レコードＲＤ３のフィールドＦ３３にセットされた実施日時よりも前である場合には、ＡＣＴ１２にてＮＯと判定し、ＡＣＴ１３を行うことなく管理処理を終了する。
つまりプロセッサ１１は、同じ管理レコードＲＤ３に関する管理処理を繰り返すことによって、推奨商品が対処購買者によって購買されるのを待ち受ける。そしてプロセッサ１１は、推奨商品が対処購買者によって購買されたならば、購買フラグをセット状態とする。

さてプロセッサ１１は、管理処理を開始した際に、管理レコードＲＤ３のフィールドＦ３４にセットされた購買フラグがセット状態となっているならば、ＡＣＴ１１にてＹＥＳと判定し、ＡＣＴ１４へと進む。つまりプロセッサ１１は、推奨商品が購買済みであるならばＡＣＴ１４へと進む。
ＡＣＴ１４としてプロセッサ１１は、代替商品の購買を検知済みであるか否かを確認する。代替商品とは、推奨商品と同じ商品カテゴリに属し、推奨商品とは異なり、かつ推奨商品よりも後に購買された商品である。プロセッサ１１は例えば、図８に示す管理レコードＲＤ３－２のように管理レコードＲＤ３にフィールドＦ３６が含まれない場合にＮＯと判定し、ＡＣＴ１５へと進む。

ＡＣＴ１５としてプロセッサ１１は、代替商品が購買されたか否かを確認する。プロセッサ１１は例えば、次の条件に合致する商品を代替商品として判定する。プロセッサ１１は、条件に合致する商品が複数存在するならば、それらをいずれも代替商品として判定する。
(1) 管理レコードＲＤ３のフィールドＦ３２にセットされた商品コードで識別される商品と同じ商品カテゴリに属し、かつ上記の商品コードとは異なる商品コードで識別される。
(2) 管理レコードＲＤ３のフィールドＦ３１にセットされた会員コードに関連付けて取引データベースＤＢ１に含まれる商品コードで識別される。
(3) 取引データベースＤＢ１に示された購買日時が、管理レコードＲＤ３のフィールドＦ３５にセットされた購買日時よりも後である。
そしてプロセッサ１１は、代替商品を１つでも判定できたならばＹＥＳと判定し、ＡＣＴ１６へと進む。

ＡＣＴ１６としてプロセッサ１１は、管理レコードＲＤ３を更新する。つまりプロセッサ１１は、判定された代替商品を識別するための商品コードとその購買日時とをそれぞれセットした２つのフィールドを末尾に追加するように管理レコードＲＤ３を更新する。なおプロセッサ１１は、ＡＣＴ１５にて代替商品を複数判定しているならば、代替商品を識別するための商品コードとその購買日時とをそれぞれセットした２つのフィールドの組を、ＡＣＴ１５にて判定した代替商品の数だけ追加するように管理レコードＲＤ３を更新する。

図９はＡＣＴ１６にて更新された後の管理レコードＲＤ３の構成を示す図である。なお図９は、更新前が図８に示す管理レコードＲＤ３－２である場合の更新例を表し、便宜的に符号を「ＲＤ３－３」としている。
図９に示す管理レコードＲＤ３－３は、商品コードが「4909999999999」である代替商品が２０１９年１月２１日の１８時３７分に購買された場合の一例である。
このためプロセッサ１１はＡＣＴ１６においては、「4909999999999」をセットしたフィールドＦ３６及び「2019/01/21 18:37」をセットしたフィールドＦ３７を管理レコードＲＤ３－２に対して追加して管理レコードＲＤ３－３としている。

そしてプロセッサ１１は、ＡＣＴ１６にて管理レコードＲＤ３を更新し終えたならば、管理処理を終了する。なおプロセッサ１１は、代替商品が購買されたことが確認できないならばＡＣＴ１５にてＮＯと判定し、ＡＣＴ１６を行うことなく管理処理を終了する。
つまりプロセッサ１１は、推奨商品が購買済みであるものの、代替商品が１つも購買されていない状況にあっては、管理処理を繰り返すことによって、代替商品が購買されるのを待ち受けることになる。そしてプロセッサ１１は、代替商品が購買されたならば、その購買の履歴を表すように管理レコードＲＤ３を更新する。

さてプロセッサ１１は、管理処理を開始した際に、管理レコードＲＤ３がフィールドＦ３５を含むならば、ＡＣＴ１４にてＹＥＳと判定し、ＡＣＴ１７へと進む。つまりプロセッサ１１は、代替商品の購買を過去に確認済みであるならばＡＣＴ１７へと進む。

ＡＣＴ１７としてプロセッサ１１は、購買を確認済みの代替商品とは別の代替商品が新規に購買されたか否かを確認する。プロセッサ１１は例えば、次の条件に合致する商品を新規に購買された代替商品として判定する。なおプロセッサ１１は、条件に合致する商品が複数存在するならば、それらをそれぞれ新規に購買された代替商品として判定する。
(1) 管理レコードＲＤ３のフィールドＦ３２にセットされた商品コードで識別される商品が属する商品カテゴリに属し、かつ推奨商品とは異なる商品の商品コードで識別される。
(2) 管理レコードＲＤ３のフィールドＦ３１にセットされた会員コードに関連付けて取引データベースＤＢ１に含まれた商品コードで識別される。
(3) 購買日時が管理レコードＲＤ３の末尾のフィールドにセットされた購買日時よりも後である。
そしてプロセッサ１１は、新規に購買された代替商品を１つも判定することができなかったならばＮＯと判定し、そのまま管理処理を終了する。つまりプロセッサ１１は、代替商品が新規に購買されない状況にあっては、管理処理を繰り返すことにより、代替商品が新規に購買されるのを待ち受ける。そしてプロセッサ１１は、購買商品が新規に購買されたことを確認できたならば、ＡＣＴ１７にてＹＥＳと判定して、ＡＣＴ１８へと進む。

ＡＣＴ１８としてプロセッサ１１は、管理レコードＲＤ３を更新する。つまりプロセッサ１１は、購買された代替商品を識別するための商品コードとその購買日時とをそれぞれセットした２つのフィールドを末尾に追加するように管理レコードＲＤ３を更新する。なおプロセッサ１１は、ＡＣＴ１７にて代替商品を複数判定しているならば、代替商品を識別するための商品コードとその購買日時とをそれぞれセットした２つのフィールドの組を、ＡＣＴ１７にて判定した代替商品の数だけ追加するように管理レコードＲＤ３を更新する。

図１０はＡＣＴ１８にて更新された後の管理レコードＲＤ３の構成を示す図である。なお図１０は、更新前が図９に示す管理レコードＲＤ３－３である場合の更新例を表し、便宜的に符号を「ＲＤ３－４」としている。
図１０に示す管理レコードＲＤ３－４は、商品コードが「4902233445566」である代替商品が２０１９年１月２７日の１５時４９分に購買された場合の一例である。
このためプロセッサ１１はＡＣＴ１８においては、「4902233445566」をセットしたフィールドＦ３８及び「2019/01/27 15:49」をセットしたフィールドＦ３９を管理レコードＲＤ３－３に対して追加して管理レコードＲＤ３－４としている。
このようにして管理レコードＲＤ３には、代替商品の購買に関する履歴が記録されてゆく。そしてプロセッサ１１がＡＣＴ１８へと進む場合は、推奨商品が購買された後、代替商品が複数回に渡って継続して購買された場合である。

ＡＣＴ１９としてプロセッサ１１は、評価指標値を判定する。評価指標値は、代替商品に関して設定された商品指標値に基づいて評価した購買者の嗜好についての指標値である。プロセッサ１１は例えば、代替商品が関連付けられた商品レコードＲＤ１の全てを販売側指標テーブルＴＤ１から抽出する。当該抽出する商品レコードＲＤ１を、ここでは便宜的に代替品レコードＲＤ１と称する。またプロセッサ１１は、管理レコードＲＤ３のフィールドＦ３１にセットされた会員コードと一致する会員コードがフィールドＦ２１にセットされ、かつ管理レコードＲＤ３に関連付けられた推奨商品が属する商品カテゴリのカテゴリコードがフィールドＦ２２にセットされた嗜好レコードＲＤ２を購買側指標テーブルＴＤ２から選択する。当該選択する嗜好レコードＲＤ２を、ここでは便宜的に補正対象レコードＲＤ２と称する。プロセッサ１１は、補正対象レコードＲＤ２にセットされている嗜好項目名のそれぞれに関して、その嗜好項目名に関連付けて代替品レコードＲＤ１にセットされている商品指標値に基づいて評価指標値を判定する。代替品レコードＲＤ１は少なくとも２つ存在するが、補正対象レコードＲＤ２にセットされている嗜好項目名が代替品レコードＲＤ１のそれぞれに必ずセットされているとは限らない。つまり、評価指標値の判定に用いるべき商品指標値の数は不定である。ただし、補正対象レコードＲＤ２にセットされている嗜好項目名が代替品レコードＲＤ１のそれぞれになるべくセットされているように販売側指標テーブルＴＤ１及び購買側指標テーブルＴＤ２を作成しておくことが望ましい。

プロセッサ１１が評価指標値を判定するためのアルゴリズムは、レシートサーバ１の設計者、リコメンドアプリＡＰ２の作成者、あるいはレシートサーバ１の管理者などにより適宜に定められてよい。一例として、評価指標値の判定に用いるべき商品指標値が１つも無い場合には、補正対象レコードＲＤ２に同じ嗜好項目名に関連付けてセットされている嗜好指標値と同じ値を評価指標値とする。評価指標値の判定に用いるべき商品指標値が１つも無い場合にはあるいは、嗜好指標値として設定され得る値の平均値を評価指標値としてもよい。また評価指標値の判定に用いるべき商品指標値が１つ以上有る場合には、それらの商品指標値の平均値を評価指標値とする。評価指標値の判定に用いるべき商品指標値が１つ以上有る場合には、それらの商品指標値の最大値など、平均値以外の統計値を評価指標値としてもよい。

具体例として、カテゴリ名が「カレールウ」である商品カテゴリに属する商品のうちで、嗜好項目名「辛さ」に対応する商品指標値として「５」が設定されている商品のうちの１つを推奨商品としている場合において、当該推奨商品が一旦は購買されたものの、その後に２度に渡って、嗜好項目名「辛さ」に対応する商品指標値として「３」が設定されている商品が購買されたとする。この場合にはプロセッサ１１は、例えば評価指標値を「３」とする。
かくしてリコメンドアプリＡＰ２に基づく情報処理をプロセッサ１１が実行することによって、プロセッサ１１を中枢部分とするコンピュータは評価指標値を設定する設定手段として機能する。

ＡＣＴ２０としてプロセッサ１１は、補正対象レコードＲＤ２にセットされている購買側指標値を補正する。プロセッサ１１が購買側指標値を補正するためのアルゴリズムは、レシートサーバ１の設計者、リコメンドアプリＡＰ２の作成者、あるいはレシートサーバ１の管理者などにより適宜に定められてよい。一例として、対象の購買側指標値を、同じ嗜好項目名に関してＡＣＴ１９にて判定した評価指標値でそのまま置き換える。あるいは、対象の購買側指標値と同じ嗜好項目名に関してＡＣＴ１９にて判定した評価指標値とを比較し、前者が後者よりも低いならば対象の購買側指標値を一定値増加し、前者が後者よりも高いならば対象の購買側指標値を一定値減少する。なお当該アルゴリズムは、少なくとも対象の購買側指標値と同じ嗜好項目名に関してＡＣＴ１９にて判定した評価指標値との差を低減するように定めておく。
具体例として、嗜好項目名「辛さ」に対応する購買側指標値が「５」であり、評価指標値が上記のように「３」であるならば、プロセッサ１１は購買側指標値を「３」に更新する。あるいはプロセッサ１１は購買指標値を補正前の「５」から一定値「１」を減じた「４」に更新する。

かくしてリコメンドアプリに基づく情報処理をプロセッサ１１が実行することによって、プロセッサ１１を中枢部分とするコンピュータは評価指標値と嗜好指標値との差が小さくなるように嗜好指標値を変更する変更手段として機能する。
そしてプロセッサ１１は、ＡＣＴ２０にて購買側指標値を更新し終えたならば、管理処理を終了する。

以上のようにレシートサーバ１によれば、購買者が推奨商品を購買した後、別の代替商品を継続して購買した場合には、代替商品として購買された商品に関する商品指標値を考慮して判定した評価指標値と購買者に関しての嗜好指標値との差を減少するように嗜好指標値が補正される。これにより、購買者が設定した嗜好指標値が適正では無いために推奨商品が購買者の嗜好に合っておらず、そのため購買者が代替商品を購買するようになった場合に、嗜好指標値が補正されることになる。そして、補正後の嗜好指標値に基づいて決定される推奨商品は、購買者の嗜好に適合した商品となる可能性が高まる。つまり、購買者の嗜好に適合した商品を推奨できるようになる。

かつ本実施形態によれば、推奨商品が一度も購買されていない状況においては、嗜好指標値は補正されない。従って、購買者が推奨商品をまだ試していない状況にあっては、設定されている嗜好指標値を尊重しての商品の推奨が繰り返される。つまり、単に購買実績に基づいて商品の推奨が行われるのではなく、購買者による設定がある程度は尊重される。

またレシートサーバ１によれば、代替商品が新規に購買される毎に、過去に購買された代替商品のそれぞれの商品指標値を考慮して購買側指標値の補正が行われることになる。このため、代替商品となる商品の数が増加するに従って、購買実績に応じて判明する購買者の嗜好をより反映して推奨商品が選定されるようになる。

この実施形態は、次のような種々の変形実施が可能である。
レシートサーバとしての機能を備えず、他のレシートサーバにより管理されている取引データベースＤＢ１を参照して上記の各処理に特化して実行するように構成した商品推奨装置として実現することも可能である。あるいは、ＰＯＳサーバなどのような別の装置の一機能として上記の各処理を実行する機能を備えるようにしてもよい。

商品指標値を判定するために参照する商品指標値を、最近の一定期間内に購買された代替商品に限ってもよい。このようにすれば、購買者の嗜好の変化が生じた場合に、最近における嗜好に適合した商品を推奨することが可能となる。

プロセッサ１１はＡＣＴ１２においては、推奨商品そのものの他、当該商品コードで識別される商品と同等の商品が購買済みである場合にもＹＥＳと判定してもよい。つまり購買者は、推奨商品の購買を検討する際に、推奨商品の近隣に陳列された同種の別の商品を比較検討し、同等であるとの判断の下に別の商品を購入する場合もあり得る。従ってこのような場合には、その後に代替商品が継続して購入されるのであれば、推奨商品が購買者の嗜好に合わなかった場合と等価であると考えることができる。

情報処理によりプロセッサ１１が実現する各機能は、その一部又は全てをロジック回路などのようなプログラムに基づかない情報処理を実行するハードウェアにより実現することも可能である。また上記の各機能のそれぞれは、上記のロジック回路などのハードウェアにソフトウェア制御を組み合わせて実現することも可能である。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…レシートサーバ、２…ＰＯＳシステム、３…購買者端末、４…通信ネットワーク、１１…プロセッサ、１２…メインメモリ、１３…補助記憶デバイス、１４…通信インタフェース、１５…伝送路。

Claims (2)

1. 推奨対象となる商品カテゴリの嗜好に関わる指標値であって購買者により定められた嗜好指標値を取得する取得手段と、
   前記商品カテゴリに属する商品であって、当該商品の嗜好に関わる指標値として予め定められた商品指標値が前記取得手段により取得された前記嗜好指標値と所定の関係にある商品を推奨商品として決定する決定手段と、
   前記決定手段により決定された推奨商品を前記購買者に推奨する推奨手段と、
   前記推奨商品が前記推奨手段による推奨後に前記購買者により購買され、さらにその後に、前記推奨商品に関する前記商品指標値とは異なる前記商品指標値が定められており、かつ前記商品カテゴリに属する前記推奨商品とは異なる１つ又は複数の別商品が前記購買者により継続して購買された場合に、前記別商品に定められた前記商品指標値に基づいて前記商品カテゴリの嗜好に関わる指標値を評価指標値として設定する設定手段と、
   前記設定手段により設定された前記評価指標値と前記嗜好指標値との差が小さくなるように前記嗜好指標値を変更する変更手段と、
   を具備した商品推奨装置。
2. コンピュータを、
   推奨対象となる商品カテゴリの嗜好に関わる指標値であって購買者により定められた嗜好指標値を取得する取得手段と、
   前記商品カテゴリに属する商品であって、当該商品の嗜好に関わる指標値として予め定められた商品指標値が前記取得手段により取得された前記嗜好指標値と所定の関係にある商品を推奨商品として決定する決定手段と、
   前記決定手段により決定された推奨商品を前記購買者に推奨する推奨手段と、
   前記推奨商品が前記推奨手段による推奨後に前記購買者により購買され、さらにその後に、前記推奨商品に関する前記商品指標値とは異なる前記商品指標値が定められており、かつ前記商品カテゴリに属する前記推奨商品とは異なる１つ又は複数の別商品が前記購買者により継続して購買された場合に、前記別商品に定められた前記商品指標値に基づいて前記商品カテゴリの嗜好に関わる指標値を評価指標値として設定する設定手段と、
   前記設定手段により設定された前記評価指標値と前記嗜好指標値との差が小さくなるように前記嗜好指標値を変更する変更手段と、
   して機能させるための情報処理プログラム。

Images