JP6203163B2 - 顧客管理装置、顧客管理システム及び方法 - Google Patents

Description

この明細書に記載の実施形態は、店舗で顧客が商品を購入した際に当該顧客に渡されるチラシなどの販促物を利用した顧客管理のためのコンピュータ技術に関する。

店舗での買い物客に対してその店舗の商品の購入を促す手段は様々あるが、その一つとして、決済直後にその購入商品に関連する商品の購入を促す印刷物を配る方法がある。かかる印刷物は、しばしばクーポンやチラシなどであり、手渡された直前に購入した商品に関連する商品であることからも、当該買い物客が関心を持つ可能性が高く、次回の来店時に当該関連商品の購入につながる可能性があるものと考えられる。したがって、印刷物にその商品に対応したコードを例えばクーポンコードとして印刷しておき、決済時にそのコードと印刷物に記された商品の商品コードがスキャンされることで、商品の購入をただ促すだけでなくその商品の購買を促したのがクーポンであるかを知ることが可能となり、顧客とのつながりを深めるＣＲＭ（Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ）の評価を行う指標とすることができる。

このような従来技術を開示したものとして、下記特許文献１が知られている。

特開２０１０−９１５８

しかしながら、上述の従来技術では、印刷物を持参した顧客という認識は可能であるが、それ以外の買い物については識別できず、長期的な顧客管理に用いることはできないという欠点（問題点）がある。

実施形態は、顧客ごとに登録された顧客情報を持たない場合でも顧客の購入履歴を管理できる技術を提供することを目的とする。

実施形態の顧客管理装置は、
商品購入の際に、購入商品のＩＤと、前記購入商品に関連したレコメンド商品に関する情報と、をレコメンドＩＤに対応付けてデータベースに記録する記録部と、
前記商品購入の際に購入者に配布される販促物に、前記レコメンドＩＤの情報と前記レコメンド商品の情報を印刷するように印刷装置に指示する印刷指示部と、
前記販促物を持参しての商品購入の際に、当該販促物に印刷された前記レコメンドＩＤの情報を受信する受信部と、
受信された前記レコメンドＩＤと同一のＩＤが前記データベースに記録された過去のレコメンドＩＤの中に存在するかを判定する判定部と、
同一のＩＤが過去のレコメンドＩＤの中に存在すると判定された場合に、当該レコメンドＩＤを有する各取引の記録に、同一の顧客識別情報を付与するように前記データベースを更新する管理制御部と、
を備える。

実施形態のシステムの概略構成を示す図である。 実施形態の各サーバのブロック構成を説明するための、中間サーバのハードウェアブロック図である。 中間サーバのレコメンド情報管理データベースに記録される情報を説明する図である。 顧客がチラシ持参なしで商品を購入した際のレコメンド情報管理データベースに記録される情報を説明する図であり、商品推薦サーバからのレコメンド情報を記録する前の状態を示す。 顧客がチラシ持参なしで商品を購入した際のレコメンド情報管理データベースに記録される情報を説明する図であり、発行されたレコメンドＩＤを含むレコメンド情報が記録された状態を示す。 顧客がチラシを持参して商品を購入した際のレコメンド情報管理データベースに記録される情報を説明する図であり、買い物客ＩＤがｎｕｌｌである状態を示す。 顧客がチラシを持参して商品を購入した際のレコメンド情報管理データベースに記録される情報を説明する図であり、買い物客ＩＤに仮買い物客ＩＤが付与された状態を示す。 買い物客管理サーバの買い物客管理領域に記録される情報を説明する図であり、通常の買い物客ＩＤと仮買い物客ＩＤとを比較して示す。 顧客がチラシを持参して商品を購入した際のレコメンド情報管理データベースに記録される情報を説明する図であり、新たに発行されたレコメンドＩＤを含むレコメンド情報が記録された状態を示す。 顧客が２枚目のチラシを持参して商品を購入した際のレコメンド情報管理データベースに記録される情報を説明する図である。 顧客が２枚目のチラシを持参して商品を購入した際のレコメンド情報管理データベースに記録される情報を説明する図であり、買い物客ＩＤ欄が書き換えられた状態を示す。 顧客が２枚目のチラシを持参して商品を購入した際の買い物客管理サーバの買い物客管理領域に記録される情報を説明する図であり、顧客の過去３回の購入履歴が記録された状態を示す。 顧客が２枚目のチラシを持参して商品を購入した際のレコメンド情報管理データベースに記録される情報を説明する図であり、３枚目のチラシが発行される場合の各欄の状態を示す。 顧客が３枚目のチラシを持参して商品を購入した際のレコメンド情報管理データベースに記録される情報を説明する図であり、会員番号を提示してチラシの推薦商品以外の商品を購入した場合の各欄の状態を示す。 買い物客管理サーバの買い物客管理領域に記録される情報を説明する図である。 顧客が３枚目のチラシを持参して商品を購入した際のレコメンド情報管理データベースに記録される情報を説明する図であり、会員番号を提示して商品を購入した場合に過去の取引の買い物客ＩＤが当該会員番号に書き換えられた状態を示す。 顧客が３枚目のチラシを持参して商品を購入した際の買い物客管理サーバの買い物客管理領域に記録される情報を示す図である。 買い物客管理サーバの買い物客管理領域に記録される情報を説明する図であり、会員番号１００００００１の顧客による商品の購入履歴が記録された状態を示す。 本システムの全体動作を説明するための、中間サーバの処理を表すフローチャートである。 本システムの全体動作を説明するための、中間サーバの処理を表すフローチャートである。

以下の実施形態では、説明の簡明化のために、決済対象を商品のみとした販促物評価装置及びシステムの構成例を記述する。

すなわち、実施形態の実施形態の顧客管理装置は、
商品購入の際に、購入商品のＩＤと、購入商品に関連したレコメンド商品に関する情報と、をレコメンドＩＤに対応付けてデータベースに記録する記録部と、商品購入の際に購入者に配布される販促物に、レコメンドＩＤの情報とレコメンド商品の情報を印刷するように印刷装置に指示する印刷指示部と、販促物を持参しての商品購入の際に、当該販促物に印刷されたレコメンドＩＤの情報を受信する受信部と、受信されたレコメンドＩＤと同一のＩＤがデータベースに記録された過去のレコメンドＩＤの中に存在するかを判定する判定部と、同一のＩＤが過去のレコメンドＩＤの中に存在すると判定された場合に、当該レコメンドＩＤを有する各取引の記録に、同一の顧客識別情報を付与するようにデータベースを更新する管理制御部と、を備える。

また、実施形態の顧客管理システムは、商品購入者に配布される販促物を用いて顧客を管理するために、販促物を印刷する印刷装置と、上記の顧客管理装置とを備える。

実施形態の顧客管理システムは、以下のような処理の流れとなる。

（チラシなしでの決済）
まず、ＰＯＳ端末を通じての顧客の商品決済時に、決済を行う商品に関連してお勧めする商品（推薦商品）の一覧をプリンタ（印刷装置）で用紙に印刷し、販促用のチラシとして当該顧客に手渡す。この際に、当該おすすめ内容（すなわち推薦商品の一覧）に対応した一意のＩＤ（レコメンドＩＤ）が割り振られ、割り振られたレコメンドＩＤをエンコードしたものもチラシに印刷される。顧客が決済した商品、推薦商品、及びレコメンドＩＤ等の各情報は、一意の取引ＩＤが割り当てられて端末のデータベースに記録される。

（１枚目のチラシ持参時の決済）
次に、顧客がこのチラシを持参して商品を決済する際に、レコメンドＩＤに係るチラシ上のコードをスキャンし、当該レコメンドＩＤに係るチラシが利用されたことを記録する。このチラシ持参での決済時にも、前回と同様に新たなレコメンドＩＤが割り振られたチラシが印刷されて顧客に手渡される。この際に、これらの取引を行った買い物客は同一であると認識し、利用されたチラシのレコメンドＩＤ（受領レコメンドＩＤ）と新たに手渡されるチラシのレコメンドＩＤ（発行レコメンドＩＤ）とを関連付け、かかる関連付けを１人の買い物客（新たな得意客）として仮の買い物客ＩＤ（顧客識別情報）を付与し、その際の購買商品一覧とともに記録する。

（２枚目以降のチラシ持参時の決済）
さらにまた次の回に、顧客が２回目の決済時に手渡された（２枚目の）チラシを持参して商品を決済した場合、前回と同様に、持参したチラシのレコメンドＩＤと今回発行したチラシのレコメンドＩＤ及び今回の購買商品一覧の関連付けが記録される。その際（もしくは後にまとめて）、利用されたチラシ（２枚目）のレコメンドＩＤを以前に発行されたチラシ（１枚目）のレコメンドＩＤとの対応を取ることで、先に記録された顧客と今回記録された顧客とが同一であることを識別できる。この後も、同様にして新たなレコメンドＩＤに係るチラシが発行され、先の決済で記録された顧客との同一性を識別することができる。

実施形態では、このようにして、顧客の個人情報や会員番号を登録せずともその顧客の購買履歴を蓄積し、顧客として管理することができる。

さらに、本明細書に記載の実施形態は、顧客の会員番号が登録された場合でも、仮の買い物客ＩＤを当該会員番号に書き換えることによって顧客を統合的に管理するための技術を提供する。

以下、実施の形態について図面を参照してより具体的に説明する。

図１に、本実施形態の代表的な構成例を示す。本実施形態の顧客管理システムは、商品推薦サーバ１と、ＰＯＳ（Ｐｏｉｎｔ Ｏｆ Ｓａｌｅ）端末２と、顧客管理装置としての中間サーバ３と、印刷装置としてのプリンタ４と、商品マスタサーバ５と、中間サーバ３とともに顧客を管理する買い物客管理サーバ６と、からなる。これら各装置は、専用回線やインターネット網などのネットワーク７を介して接続され、相互に通信可能となっている。

商品推薦サーバ１は、買い物客の購入商品一覧の記録を受信、蓄積し、その情報をもとにお勧めする商品（レコメンド商品）の一覧の情報を返信する機能を有する。

ＰＯＳ端末２は、買い物客が購入する商品の登録及び決済を行うとともに、当該登録された商品の一覧のデータを購入商品一覧データとして送信する機能を有する。

中間サーバ３は、本システムの中心的な役割を担う装置であり、買い物客の取引情報、レコメンド商品の情報及び発行するチラシに関する情報をデータベース化して管理する機能を有する。また、中間サーバ３は、ＰＯＳ端末２及び他のサーバ間の通信を仲介ないし中継しつつ、複数の取引間での買い物客の同一性を判定して買い物客毎に管理する機能を有する。

具体的には、中間サーバ３は、ＰＯＳ端末２から送信されて来る購入商品のデータを受信し、取引ＩＤを付与して自機のデータベースに記録するとともに、かかるデータを商品推薦サーバ１に送信する。また、中間サーバ３は、商品推薦サーバ１から送信されたおすすめ商品一覧に関するデータを受信し、該受信データに後述する自機による処理を施してプリンタ４に印刷指示を出す機能を有する。さらに、中間サーバ３は、買い物客の取引情報を買い物客管理サーバ６に送信する機能、買い物客管理サーバ６に仮買い物客ＩＤの発行を依頼する機能、買い物客ＩＤを書き換えて買い物客を個々に管理する機能を有する。中間サーバ３のこれらの機能の詳細や他の機能については後述する。

プリンタ４は、中間サーバ３から送信される印刷データ及び印刷指示を受信し、当該印刷指示に従った印刷を用紙に実行することで、買い物客に配布する販売促進用物品（販促物）であるチラシを印刷する。プリンタ４の印刷方式は特に限定されず、例えば電子写真方式、インクジェット方式のいずれでもよい。

商品マスタサーバ５は、自機の記録部（ＨＤＤ等）に、店舗で扱う商品（以下、「取扱商品」とも称する。）の識別子（この例ではＪＡＮコード）と個々の商品名が関連付けて記録される商品マスタデータベースを保有する。この商品マスタデータベースは、商品推薦サーバ１とＰＯＳ端末２それぞれがネットワーク７を通して参照可能となっている。

買い物客管理サーバ６は、主に、個別の買い物客の買い物の履歴と買い物客をデータベースで管理するサーバであり、後述する顧客識別情報の発行などの機能を有する。

商品推薦サーバ１、中間サーバ３、商品マスタサーバ５、及び買い物客管理サーバ６は、一般的なパーソナルコンピュータ（ＰＣ）と同様のハードウエア構成の装置である。これら各装置の内、中間サーバ３のハードウエアブロック構成を図２に示す。

図２に示すように、中間サーバ３は、当該装置全体の制御を司り各種演算を行うＣＰＵなどの演算部３１、演算部３１の作業領域となるＲＡＭ等の記憶部３２、本システムを実現するためのソフトウエアプログラム、データベース、及び各種のデータが格納されるＨＤＤなどの記録部３３、インターや各種通信回線を介して他の装置と接続するためのネットワーク接続部３４、各種の表示画面を表示する液晶ディスプレイなどの表示部３５、及び管理者などが各種の操作入力を行うためのマウスやキーボードなどの操作部３６を有し、これら各部がバスを介して相互に接続された構成となっている。図２に示す各部の構成は、他の商品推薦サーバ１、ＰＯＳ端末２、商品マスタサーバ５、及び買い物客管理サーバ６でも同等であるため、他のサーバ１，５，６及びＰＯＳ端末２についての内部ブロック構成の図示を省略する。

この実施形態では、ＰＯＳ端末２、中間サーバ３、プリンタ４、商品マスタサーバ５、及び買い物客管理サーバ６が同一店舗内に配置され、商品推薦サーバ１が店舗外に配置される。ただし、商品推薦サーバ１を同一店舗内に配置しても構わない。また、複数のサーバ１，３，５，６の機能を一台のコンピュータに集約することとしてもよい。特に、買い物客管理サーバ６の機能を中間サーバ３に集約することができる。

次に、各サーバ及び装置の機能をより詳細に説明する。

商品推薦サーバ１は、ネットワーク接続部を介して中間サーバ３から受信された取引情報に基づいて、購買を推薦する商品の一覧情報となるレコメンド情報とレコメンド印刷ファイルを生成する。かかる機能を実現するため、商品推薦サーバ１の記録部に図示しないレコメンドプログラム及び関連商品データベースが格納され、演算部がかかるプログラムを読み出して実行する。

中間サーバ３は、ネットワーク接続部を介してＰＯＳ端末２から送られて来る取引情報と、当該取引情報に関連付けられ、商品推薦サーバ１から送られて来るレコメンド情報とを記録するレコメンド情報管理データベースを保有する。このレコメンド情報管理データベースは、中間サーバ３の記録部３２に格納され、取引がなされると更新される。中間サーバ３の記録部３３に格納されるレコメンド情報管理データベースのデータ構造の一例を図３に示す。

図３に示すように、レコメンド情報管理データベースは、「取引情報」と「レコメンド情報」が一意の「取引ＩＤ」に対応付けられたデータ構造を有する。このうち、取引情報の領域は、顧客が商品を購入した際の情報が記録される領域であり、具体的には、「取引日時」、「買い物客ＩＤ」、「受領レコメンドＩＤ」、及び顧客が購入した商品に係る「ＪＡＮコード一覧」のデータが記録される。他方、レコメンド情報の領域は、顧客が商品を購入した際に生成される推薦商品に関する情報が記録される領域であり、具体的には、推薦商品に係る「ＪＡＮコード一覧」、「レコメンド印刷ファイル」、及び「発行レコメンドＩＤ」のデータが記録される。

買い物客管理サーバ６は、主として、個々の買い物客を識別する「買い物客ＩＤ」に当該買い物客が購入した商品の一覧を関連付けて、記録部の買い物客管理領域に記録する。かかる機能を実現するため、買い物客管理サーバ６の記録部に買い物客管理プログラムが格納され、演算部がこの買い物客管理プログラムを読み出して実行する。

図１８、図８、図１２、図１５、及び図１７は、買い物客管理サーバ６の買い物客管理領域に記録及び更新される情報を示す。図示のように、買い物客管理領域には、「買い物客ＩＤ」、買い物客の「取引日時」及び購入した商品の「ＪＡＮコード一覧」からなる「購入履歴」が記録される欄が設けられる。かかる買い物客管理領域が更新される態様の詳細は後述する。

ここで、「買い物客ＩＤ」欄に記録される買い物客ＩＤは、図示しない会員カードと共に発行される本会員番号としての「会員ＩＤ」と、買い物客ＩＤとは別個に発行される顧客識別情報である「仮買い物客ＩＤ」とに大別される。「会員ＩＤ」及び「仮買い物客ＩＤ」は、両者を区別できるようにするために、相互に別の番号体系となっている。本実施形態では、「会員ＩＤ」は「１」で始まる８桁の番号であり（図１８参照）、「仮買い物客ＩＤ」は「９」で始まる８桁の番号（図８参照）である。

また、「会員ＩＤ」は、会員カードに刻印及びバーコードとして印刷され、会員カードの配布とともに会員に通知されるものである。かかる会員カードの発行の際には、買い物客の同意のもとに、当該顧客の個人情報（氏名、住所、連絡先等）が会員ＩＤとともに買い物客管理サーバ６に登録される。

これに対して、「仮買い物客ＩＤ」は、中間サーバ３及び買い物客管理サーバ６の管理用（すなわち顧客識別用）に使用されるＩＤであり、顧客（買い物客）には通知されない。この「仮買い物客ＩＤ」は、後述のように、中間サーバ３からの発行依頼により買い物客管理サーバ６が発行する。

ＰＯＳ端末２は、買い物客の購入商品を登録しその商品について決済を行うという基本機能を有する端末である。このため、ＰＯＳ端末２は、予め商品マスタサーバ５からその店舗で販売される取扱商品のＪＡＮコードと商品名を受信し、自機の記録部に記録する。また、ＰＯＳ端末２は、クレジットカードなどの決済を行うために、図示しない金融機関の決済サーバと接続可能となっている。

さらに、ＰＯＳ端末２は、当該登録された商品の一覧のデータを購入商品一覧データとして中間サーバ３に送信する。さらにまた、ＰＯＳ端末２は、買い物客が持参したチラシに印刷された識別情報（レコメンドＩＤ）を読み取り、当該読み取られたレコメンドＩＤを中間サーバ３に送信する。このレコメンドＩＤを読み取る（スキャン等する）ために、ＰＯＳ端末２は、図示しないバーコードリーダなどの読取部が設けられる。

以下、本システム全体の動作及び中間サーバ３の動作について、図１９（図１９Ａ及び図１９Ｂ）のフローチャートを参照しながら説明する。ここで、図１９は中間サーバ３で遂行する処理を示すフローチャートであり、かかるフローチャートにおける各処理の主体は、他の処理主体の明記がない限り演算部３１である。

（チラシなしでの商品購入）
まず、顧客がチラシの持参なしで商品を購入する場合について説明する。ＰＯＳ端末２が設置されている店舗においてある買い物客が一以上の商品を購入する場合、店員によりＰＯＳ端末２の操作部が操作され、あるいは商品の包装などに付されたバーコードを読取部で読み取ることで、当該購入された商品の登録及び決済が行われる。

この際に、ＰＯＳ端末２は、当該登録された商品のＪＡＮコード一覧及び買い物客ＩＤを関連付けた取引情報を生成する。かかる商品登録時に買い物客の会員カードが提示された場合には、かかる会員カードに付された会員ＩＤのバーコードを読取部で読み取ってデコードすることで、ＰＯＳ端末２は、買い物客ＩＤとして「１」で始まる会員ＩＤを入力し、かかる会員ＩＤを含めた取引情報を生成する（図１８参照）。

他方、かかる商品登録時に会員ＩＤが入力されなかった場合、ＰＯＳ端末２は、会員ＩＤの入力が無いことを示す”ｎｕｌｌ”を記録した取引情報を生成する。その後、ＰＯＳ端末２は、当該生成された取引情報を中間サーバ３に送信する。ここで、会員ＩＤが入力されない場合としては、決済時に当該買い物客が未だ会員でなかった場合、あるいは会員であっても会員カードが提示されないなどの理由で会員ＩＤが入力されなかった場合が挙げられる。以下は、商品登録時に会員ＩＤが入力されなかった場合を前提として説明する。

中間サーバ３は、ＰＯＳ端末２から送られて来る取引情報を受信すると（ＡＣＴ１０１のＹｅｓ）、その取引情報に一意となる取引ＩＤを付与する（ＡＣＴ１０２）。さらに、中間サーバ３は、当該取引情報及び取引ＩＤを自機のレコメンド情報管理データベースに記録する（ＡＣＴ１０３）。

図４は、ＰＯＳ端末２が置かれている店舗において、ある買い物客が、チラシを持参せずに商品を購入した場合のレコメンド情報管理データベースに記録された情報の一例である。この例は、買い物客が２つの商品を購入した場合であって、「取引ＩＤ」が１、取引情報として、「取引日時」が２０１４年４月１日の１５時、購入された２つの商品の「ＪＡＮコード」が各々、４９ｘｘｘｘｘｘｘｘｘｘｘ及び４９ｙｙｙｙｙｙｙｙｙｙｙであった場合を仮定する。なお、取引情報の内、「買い物客ＩＤ」は、上述のように買い物客からの提示がないためにｎｕｌｌ値である。

また、この段階では、チラシ及びそのレコメンドＩＤが発行されていない状態であり（図４、ＡＣＴ１０４参照）、取引情報の「受領レコメンドＩＤ」欄もｎｕｌｌ値になっている。したがって、中間サーバ３は、ＡＣＴ１０４の判定処理でＮｏすなわち受領レコメンドＩＤがｎｕｌｌであると判定した後に、今回の決済での取引情報及び取引ＩＤを商品推薦サーバ１に対して送信する（ＡＣＴ１１７）。

商品推薦サーバ１は、中間サーバ３から取引情報及び取引ＩＤを受信すると、当該取引情報をもとにその取引ＩＤの買い物客に対して何を推薦すればよいのかを分析する。この分析は、本システムでは、１つの商品のＪＡＮコードに対し、その商品に関連するｎ個の商品のＪＡＮコードが対応付けられて登録される、自機内の関連商品データベース（図示せず）を参照することによって、分析される。ここで、関連商品データベースに登録される「関連する商品」としては、例えば商品が「ＭサイズのＴシャツ」であれば、色やデザインが異なる同サイズのＴシャツ、現在人気の或いは特売中のＭサイズのズボン、下着などが挙げられる。また、関連する商品の他の例としては、例えば商品がデジタルカメラなどの電化製品である場合に、その製品に使われる電池やフラッシュメモリ等の部品などが挙げられる。但し、これらは単なる例示であり、実際には関連する商品の態様として種々の形態が有り得る。

商品推薦サーバ１は、かかる分析の結果、その時点でその買い物客にお勧めするべき商品群のＪＡＮコード一覧を決定する。また、商品推薦サーバ１は、当該決定されたＪＡＮコード一覧の推薦商品（商品群）の情報を、１枚の用紙（すなわちチラシ）内に配列し、印刷可能なファイル形式（この例ではＰＤＦファイル）に変換することで、レコメンド印刷ファイルを生成する。さらに、商品推薦サーバ１は、決定された推薦商品のＪＡＮコード一覧、生成されたレコメンド印刷ファイル、及び元の取引情報に含まれる取引ＩＤを、レコメンド情報として中間サーバ３に送信する。

この例では、ＪＡＮコード「４９ｘｘｘｘｘｘｘｘｘｘｘ」の購買商品に対してＪＡＮコード「４９ａａａａａａａａａａａ」の商品、ＪＡＮコード「４９ｙｙｙｙｙｙｙｙｙｙｙ」の購買商品に対してＪＡＮコード「４９ｂｂｂｂｂｂｂｂｂｂｂ」の商品が各々レコメンド情報のＪＡＮコード一覧として決定され、中間サーバ３に送信されたものと仮定する（図５参照）。なお、この例では説明の簡明化のために推薦商品の数を少なくしており、実際は一つの購買商品に対して多数の推薦商品を生成・送信等することができる。

中間サーバ３は、商品推薦サーバ１からのレコメンド情報（すなわち、推薦商品のＪＡＮコード、レコメンド印刷ファイル、及び取引ＩＤ）を受信すると（ＡＣＴ１１８のＹｅｓ）、当該レコメンド情報を、受信された取引ＩＤと関連付けられているレコメンド情報管理データベースの該当欄、すなわち「ＪＡＮコード一覧」及び「レコメンド印刷ファィル」欄に追加記録する（図５参照）。この際に、中間サーバ３は、レコメンド情報に対して一意となるレコメンドＩＤを発行し（ＡＣＴ１１９）、かかるレコメンドＩＤもレコメンド情報欄の「発行レコメンドＩＤ」欄に記録する（ＡＣＴ１２０）。

本実施形態では、管理者による管理容易化の観点から、取引ＩＤの番号が末尾に付与される１３桁の数字のレコメンドＩＤが発行される（図５、図９等参照）。なお、かかる形態（番号体系）に限定されるものではなく、取引ＩＤとレコメンドＩＤとの対応付けがなされていれば他の形態でもかまわない。

続いて、中間サーバ３は、発行されたレコメンドＩＤをＰＯＳ端末２の読取部でスキャン及びデコードできるバーコードなどの画像情報としてエンコードする（ＡＣＴ１２１）。さらに、中間サーバ３は、当該エンコードされた画像情報を、レコメンド印刷ファイルの紙面の所定位置（例えば紙面の隅部など）に合成する処理を行う（ＡＣＴ１２２）。さらに、中間サーバ３は、当該該レコメンドＩＤの画像情報が合成されたレコメンド印刷ファイルを、印刷指示とともにプリンタ４に送信する（ＡＣＴ１２３）。

中間サーバ３からレコメンド印刷ファイル及び印刷指示を受信したプリンタ４は、用紙に当該レコメンド印刷ファイルの画像を印刷することで、買い物客（この例ではＪＡＮコード「４９ｘｘｘｘｘｘｘｘｘｘｘ」及び「４９ｙｙｙｙｙｙｙｙｙｙｙ」の２つの商品を購入した顧客）に配布されるチラシを印刷する。この例では、ＪＡＮコード「４９ａａａａａａａａａａａ」及び「４９ｂｂｂｂｂｂｂｂｂｂｂ」の推薦商品に関する説明（例えば、各推薦商品の画像、名称、値段、性能、特徴、など）と、レコメンドＩＤ「９９００００００００００１」を示す画像情報（バーコード等）と、クーポン情報と、が印字されたチラシがプリンタ４から出力される。出力されたチラシは、店員から当該買い物客に手渡される。

ここでクーポン情報とは、例えば「このチラシを持参したお客様には、次回買い物時に○％の割引をします」などの買い物客にとって有利になる情報である。すなわち、チラシにクーポンの役割を持たせることで、買い物客が次回に買い物するときに、今回配布されたチラシを持参して店に来る可能性が高くなることを考慮したものである。したがって、クーポン情報は、チラシから切り離せるようにする必要はなく、また、上述した割引情報に限られず、次回来店時までにチラシを保存し次回来店時にチラシを持参する動機付けを与えるような情報であればよい。

（１回目のチラシ持参時の決済）
次に、上述したチラシを渡された買い物客が、当該チラシを持参して再び同じ店舗で買い物を行った場合について説明する。

この場合も、買い物客が購入する商品については、その決済時に、ＰＯＳ端末２での入力操作を通じて前回同様に商品登録等の処理が行われる（ＡＣＴ１０１乃至１０３参照）。この例では、買い物客がＪＡＮコード「４９ａａａａａａａａａａａ」と「４９ｚｚｚｚｚｚｚｚｚｚｚ」の２つの商品を購入したと仮定する。

さらに、この例はチラシ持参での購入であり、この場合、決済時におけるＰＯＳ端末２での入力操作の際に、チラシに印字されたレコメンドＩＤのコード（画像）がＰＯＳ端末２の読取部でスキャン及びデコードされる。デコードされたレコメンドＩＤ（この例では「９９００００００００００１」）は、受領レコメンドＩＤとして取引情報に埋め込まれてＰＯＳ端末２から中間サーバ３に送信される。

これら各データを受信した中間サーバ３は、上述した前回の決済時と同様に、レコメンド情報管理データベースに新しい取引として取引情報を記録する。かかる取引情報が記録された状態を図６の下段に示す。

すなわち、ＰＯＳ端末２及び中間サーバ３の上述したＡＣＴ１０１乃至１０３の処理により、今回の決済では、取引ＩＤ「１０」が付与され、かつ、取引日時の「２０１４／４／２ １１：００：００」、購入商品のＪＡＮコード「４９ａａａａａａａａａａａ」と「４９ｚｚｚｚｚｚｚｚｚｚｚ」、受領レコメンドＩＤ「９９００００００００００１」が各々情報管理領域の該当欄に記録されたことが分かる。

中間サーバ３は、続くＡＣＴ１０４で、受領レコメンドＩＤがｎｕｌｌ以外であるかを判定する。この判定により、チラシを持参しない取引であるか否かが確認される。この例では、チラシ持参での取引であるため、中間サーバ３は、ＡＣＴ１０４でＹｅｓ、すなわち受領レコメンドＩＤがｎｕｌｌ以外であると判定する。

さらに、ＡＣＴ１０５で、中間サーバ３は、買い物客ＩＤがｎｕｌｌか否かを判定し、ＹｅｓすなわちｎｕｌｌであればＡＣＴ１０６に移行し、Ｎｏすなわちｎｕｌｌでない場合はＡＣＴ１１４に移行する。この例すなわち１回目のチラシ持参時の決済段階では、未だ特定の買い物客ＩＤが記録されていないｎｕｌｌの状態であるため（図６参照）、中間サーバ３は、ＡＣＴ１０６に移行する。

中間サーバ３は、レコメンド情報管理データベースを参照して、受領レコメンドＩＤと一致するＩＤを、過去の取引に係る発行レコメンドＩＤから検索し（ＡＣＴ１０６）、受領レコメンドＩＤと一致する発行レコメンドＩＤが存在するか否かを判定する（ＡＣＴ１０７）。

中間サーバ３は、この検索及び判定の結果、受領レコメンドＩＤと一致する発行レコメンドＩＤがレコメンド情報管理データベースに存在する場合には（ＡＣＴ１０７でＹｅｓ）、これらの取引を行った買い物客は同一であると認識してＡＣＴ１０８に移行する。

他方、受領レコメンドＩＤと一致する発行レコメンドＩＤが存在しないと判定された場合には（ＡＣＴ１０７でＮｏ）、中間サーバ３は、発行レコメンドＩＤのデータが失われた等の何らかのエラーが発生したものとみなして、ＡＣＴ１１７に移行し、以下はチラシなしで決済した場合と同様に処理を遂行する。なお、この場合でも、実際はチラシ持参での買い物であるため、顧客は、チラシに記載された割引等の適用を受けることができる。

ＡＣＴ１０８で、中間サーバ３は、受領レコメンドＩＤと一致した発行レコメンドＩＤの買い物客ＩＤがｎｕｌｌか否かについて判定する。この判定結果がＹｅｓすなわちｎｕｌｌの場合には、中間サーバ３は、この決済が同一顧客による２回目の商品購入であるとみなしてＡＣＴ１０９に移行する。他方、判定結果がＮｏすなわちｎｕｌｌ以外の場合には、中間サーバ３は、この決済が同一顧客による３回目以降の商品購入であるとみなしてＡＣＴ１１３に移行する。

ＡＣＴ１０９で、中間サーバ３は、当該買い物客は「新たな得意客である」として、買い物客管理サーバ６に対して、顧客識別情報としての仮の買い物客ＩＤの発行を依頼する。その後、中間サーバ３は、買い物客管理サーバ６からの返答があるまで待機する（ＡＣＴ１１０）。

かかる依頼を受信した買い物客管理サーバ６は、上述した本会員番号としての会員ＩＤとは異なる番号体系のＩＤを仮のＩＤ（仮買い物客ＩＤ）として発行し、買い物客管理領域の「買い物客ＩＤ」欄に仮買い物客ＩＤを記録するとともに、その仮の顧客の商品購入の履歴を管理する領域を確保する。

本実施形態では、上述のように、本会員番号としての会員ＩＤが１から始まる８ケタの数字であり、仮買い物客ＩＤは９から始まる８ケタの数字となっている。この例では、仮の買い物客ＩＤとして、「９００００００１」が発行されたものと仮定する。買い物客管理サーバ６は、このようにして発行された仮買い物客ＩＤを中間サーバ３に返信する。

中間サーバ３は、買い物客管理サーバ６から送られて来た仮買い物客ＩＤを受信すると（ＡＣＴ１１０でＹｅｓ）、続くＡＣＴ１１１で、当該取引および当該取引の受領レコメンドＩＤと一致する発行レコメンドＩＤに係る取引のそれぞれの「買い物客ＩＤ」の欄を、当該受信した仮買い物客ＩＤ（この例では「９００００００１」）で書き換える。当該書き換えられた後の状態を図７に示す。

続いて中間サーバ３は、これら、すなわち今回及び過去の取引情報を、仮買い物客ＩＤとともに買い物客管理サーバ６に送信し（ＡＣＴ１１２）、買い物客管理サーバ６からの返信があるまで待機する（ＡＣＴ１１５）。

これらの情報を受信した買い物客管理サーバ６は、当該受信された（仮の）買い物客ＩＤの買い物客管理領域に、受信した取引情報のうち日時とＪＡＮコード一覧を関連付けて記録し、その買い物客の買い物履歴として記録する。このようにして記録された状態を図８の下段に示す。図示のように、２０１４年４月２日の今回の取引とその前の４月１日の取引とが同じ買い物客によりなされたことが分かる。

買い物客管理サーバ６は、この記録が終了すると、正常に記録した旨のメッセージを中間サーバ３に送信する。中間サーバ３は、かかるメッセージを受信すると（ＡＣＴ１１５及びＡＣＴ１１６でＹｅｓ）、上述したＡＣＴ１１７乃至ＡＣＴ１２３以下の処理を遂行する。

すなわち、中間サーバ３は、今回の取引情報を商品推薦サーバ１に送信して推薦商品及びチラシの情報の生成を依頼し（ＡＣＴ１１７）、以後の処理は前回の取引と同様に行われ、新たなチラシが印字されて買い物客に手渡される。かかる処理完了時のレコメンド情報管理データベース内の情報の模式図を図９に示す。この例では、ＪＡＮコード「４９ａａａａａａａａａａａ」、「４９ｚｚｚｚｚｚｚｚｚｚｚ」の購入商品に対して、各々ＪＡＮコード「４９ｃｃｃｃｃｃｃｃｃｃｃｃ」及び「４９ｄｄｄｄｄｄｄｄｄｄｄ」の推薦商品が選出され、これら推薦商品の情報がレコメンドＩＤ「９９０００００００００１０」の情報とともにチラシ（すなわち２枚目のチラシ）に印刷されたことが分かる。

このように、本実施形態では、チラシを持参しない１回目の決済段階では買い物客管理サーバ６による仮買い物客ＩＤは発行されず、チラシ持参による２回目の決済段階で顧客の同一性が確認されることで、仮買い物客ＩＤが発行される。

（２枚目のチラシ持参時の決済）
次に、上述した２枚目のチラシを渡された買い物客が、当該チラシを持参して再び同じ店舗で買い物を行った場合について説明する。

この場合、当該買い物客は、１枚目のチラシ持参での決済時に、既に仮買い物客ＩＤ「９００００００１」を与えられている。このため、１枚目のチラシ持参での決済時と異なる処理が行われる。

すなわち、先の発行レコメンドＩＤ９９０００００００００１０が記録されたチラシを持参し、買い物時に提示した買い物客の決済が完了すると、ＰＯＳ端末２は、前回同様、買い物客ＩＤがｎｕｌｌである取引情報を生成し中間サーバ３に送信する。

中間サーバ３は、当該受信された取引情報に取引ＩＤを付与し、これら情報をレコメンド情報管理データベースに記録する（ＡＣＴ１０１乃至１０３、図１０参照）。図１０の下段に示すように、この例では、２０１４年４月３日の１３時に２つの商品が購入され、その内のＪＡＮコード「４９ｄｄｄｄｄｄｄｄｄｄｄ」の商品は１枚目のチラシに印刷された推薦商品であり、取引ＩＤとして「２４」生成されたものと仮定する。

ここでは、先の取引と同様に、受領レコメンドＩＤがｎｕｌｌではなく（ＡＣＴ１０４でＹｅｓ）、かつ、買い物客ＩＤがｎｕｌｌであることから（ＡＣＴ１０５でＹｅｓ）、中間サーバ３は、レコメンド情報管理データベース中の過去の発行レコメンドＩＤから今回の受領レコメンドＩＤ（この例では「９９０００００００００１０」）を検索し（ＡＣＴ１０６）、一致する過去の発行レコメンドＩＤが見つかれば（ＡＣＴ１０７でＹｅｓ）、当該発行レコメンドＩＤの買い物客ＩＤがｎｕｌｌであるかを判定する（ＡＣＴ１０８）。

この判定で、一致する過去の発行レコメンドＩＤの買い物客ＩＤはｎｕｌｌでなく仮買い物客ＩＤの「９００００００１」であるため（図１０参照）、中間サーバ３は、ＡＣＴ１１３に移行する。ＡＣＴ１１３で、中間サーバ３は、当該発行レコメンドＩＤの取引情報に含まれる買い物客ＩＤ（「９００００００１」）で新たな取引情報の「買い物客ＩＤ」欄を上書きする（ＡＣＴ１１３、図１１参照）。

さらに、中間サーバ３は、今回の決済に係る取引情報を上書きした買い物客ＩＤとともに買い物客管理サーバ６に送信する（ＡＣＴ１１４）。

これらの情報を受信した買い物客管理サーバ６は、前回の決済時と同様に処理を行う。すなわち、買い物客管理サーバ６は、当該受信された買い物客ＩＤ（すなわち「９００００００１」）の買い物客管理領域に、受信した取引情報のうち日時とＪＡＮコード一覧を関連付けて記録し、その買い物客の買い物履歴として記録する。このようにして記録された状態を図１２の下段に示す。図８と図１２を比較して分かるように、２０１４年４月３日の今回の決済に係る取引日時及び購入商品のＪＡＮコード一覧が買い物客管理領域に追記されたことが分かる。また、２０１４年４月３日の今回の取引と、その前の４月２日さらには４月１日の取引とが同じ買い物客によりなされたことが分かる。

以降の動作は前回の取引と同様に行われ、新たな（３枚目の）チラシが印字されて買い物客に手渡される。かかる処理の完了時のレコメンド情報管理データベースに記録された情報の例を図１３に示す。

このように、本実施形態の顧客管理システムによれば、決済時に顧客により利用されたチラシ（２枚目以降のチラシ）に印刷されたチラシ毎の識別情報（レコメンドＩＤ）を、以前に発行され利用されたチラシ（１枚目以降のチラシ）の識別情報（レコメンドＩＤ）の記録（利用記録）から検索して顧客の同一性を判定し確認する。

したがって、本システムでは、顧客が会員登録していない場合や、会員登録した顧客が会員番号を提示しない場合であっても、顧客の同一性が確認された複数の取引に関し、当該レコメンドＩＤを有する各取引の記録に顧客識別情報としての仮買い物客ＩＤを付与するようにデータベースを更新することで、同一顧客による取引の内容を容易に把握し管理することができる。

具体的には、管理者等が仮買い物客ＩＤで中間サーバ３のレコメンド情報管理データベースを検索することにより、顧客毎の取引の内容を容易に視認、把握することができる。さらには、本システムでは、顧客毎の取引の内容が買い物客管理サーバ６の買い物客管理領域に順次自動で記録、更新されるので（図１８、図８、図１２、図１５、及び図１７参照）、管理者等が仮買い物客ＩＤで買い物客管理サーバ６の買い物客管理領域を検索することによって、顧客毎の取引の内容をさらに容易に視認、把握することができる。

さらに、本実施形態によれば、顧客に渡されるチラシ毎に一意の識別情報（レコメンドＩＤ）が付与されることから、チラシに印刷された推薦商品を購入したか否かにかかわらず、顧客毎の取引の内容を管理することができる。

さらにまた、本実施形態の顧客管理システムでは、チラシを持参した買い物客が、事前にその店舗の顧客登録を済ませて本会員としての会員番号が登録された場合でも、仮の買い物客ＩＤを当該会員番号に書き換えることによって、顧客を統合的に管理できるようになっている。以下、このための処理を説明する。

（決済時に会員ＩＤが入力された場合）
以下は、さらに以降の取引で、前回のチラシを持参した上述の買い物客が、事前にその店舗の顧客登録を済ませており、商品購入の際に会員カードを提示した場合について説明する。

次の来店時に、上述した顧客が、先の発行レコメンドＩＤ「９９０００００００００２４」（図１３参照）に係るバーコード等の画像が印刷されたチラシと会員カードを商品購入の際に提示した事例を仮定する。この場合、当該買い物客の決済処理の際に、ＰＯＳ端末２は、提示された会員カードの会員ＩＤ（この例では「１００００００２」と仮定する）を入力し、かかる会員ＩＤを買い物客ＩＤとして含めた取引情報を中間サーバ３に送信する。

中間サーバ３は、会員ＩＤが含まれた取引情報をＰＯＳ端末２から受信すると（ＡＣＴ１０１、Ｙｅｓ）、当該受信された情報に新たな取引ＩＤを付与し（ＡＣＴ１０２）、これらの情報を自機のレコメンド情報管理データベースに記録する（ＡＣＴ１０３）。

この場合のレコメンド情報管理データベースに記録された各情報を図１４の下段に示す。図１４から分かるように、取引ＩＤ「１」，「１０」，「２４」及び「３２」の各取引が同一の顧客による決済であっても、今回の決済での「買い物客ＩＤ」欄の値が以前の決済とは異なるものとなる。

続いて、中間サーバ３は、受領レコメンドＩＤ「９９０００００００００２４」はｎｕｌｌ以外であると判定し（ＡＣＴ１０４でＹｅｓ）、さらに、買い物客ＩＤ「１００００００２」がｎｕｌｌでないと判定し（ＡＣＴ１０５でＮｏ）、当該取引情報を買い物客ＩＤ「１００００００２」とともに買い物客管理サーバ６に送信する（ＡＣＴ１１４）。

これらの情報を受信した買い物客管理サーバ６は、当該受信された買い物客ＩＤが会員ＩＤである場合には、かかる会員ＩＤ「１００００００２」の買い物客管理領域を確保する際に（図１５参照）、正規のＩＤである会員ＩＤ「１００００００２」の購入履歴が存在するか否かを判定し、その時点で存在しなければ、過去の履歴がないため正常に記録できない旨のメッセージを中間サーバ３に返信する。

中間サーバ３は、かかる返信を受信すると（ＡＣＴ１１６でＮｏ）、自機のレコメンド情報管理データベースの過去の取引ＩＤの「発行レコメンドＩＤ」欄を検索し、過去の取引の発行レコメンドＩＤと今回の取引の受領レコメンドＩＤとを比較する（ＡＣＴ１２４）。中間サーバ３は、過去の取引の発行レコメンドＩＤ中に受領レコメンドＩＤと一致するものが存在するかにについて判定し（ＡＣＴ１２５）、存在する場合には（ＡＣＴ１２５でＹｅｓ）、これら一連の取引を行った買い物客が同一であると認識する。

続くＡＣＴ１２６で、中間サーバ３は、これらの過去の取引について買い物ＩＤがｎｕｌｌまたは仮の買い物客ＩＤであるかを判定する。この事例では、図１４に示すように、過去の取引に係る取引ＩＤ１，１０，２４の取引はいずれも仮の買い物客ＩＤ「９００００００１」なので、中間サーバ３は、Ｙｅｓと判定してＡＣＴ１２７に移行する。

ＡＣＴ１２７で、中間サーバ３は、これらの過去の取引の「買い物客ＩＤ」欄を、今回受信した取引情報に含まれる正式な買い物客ＩＤ（すなわち会員ＩＤ）に書き換え（図１６参照）、その書き換えた取引情報を購入履歴データとして買い物客管理サーバ６に送信する。図１４と図１６とを比較して明らかなように、ＡＣＴ１２７の処理で、過去の取引に係る取引ＩＤ１，１０，２４の買い物客ＩＤが、仮の買い物客ＩＤ「９００００００１」から正式な会員ＩＤ「１００００００２」で上書きされたことが分かる。

中間サーバ３からの購入履歴データを受信した買い物客管理サーバ６は、その買い物客ＩＤ「１００００００２」の領域に、受信された購入履歴を追記する（図１７参照）。

その後、中間サーバ３は、買い物客管理サーバ６からの正常に記録した旨のメッセージを受信し（ＡＣＴ１１５及び１１６でＹｅｓ）、商品推薦サーバ１に対して推薦情報の生成を依頼する（ＡＣＴ１１７）。以降の動作は前回の取引と同様に行われ（ＡＣＴ１１８乃至１２３）、新たなチラシが印字されて買い物客に手渡される。

このように、本実施形態の顧客システムによれば、チラシを持参した買い物客が、事前にその店舗の顧客登録を済ませて本会員としての正式な会員番号が登録された場合でも、過去の取引情報として記録された仮の買い物客ＩＤを、商品購入時に提示された正式な会員番号に書き換えることによって、顧客を統合的に管理することができる。

なお、図１９Ｂのフロー中、過去の履歴がないため正常に記録できない旨の買い物客管理サーバ６からのメッセージを中間サーバ３で受信し（ＡＣＴ１１６でＮｏ）、それにもかかわらず、中間サーバ３が取引情報に含まれる受領レコメンドＩＤと一致する過去の発行レコメンドＩＤを発見できない場合（ＡＣＴ１２４，ＡＣＴ１２５でＮｏ）、データ破損等、何らかの理由で発行レコメンドＩＤの記録が消えたと考えられる。この場合は履歴の追跡が不可能であるため、中間サーバ３は、履歴が存在しない旨のメッセージを買い物客管理サーバ６に送信する（ＡＣＴ１２９）。かかるメッセージを受信した買い物客管理サーバ６は、今回受信した取引情報のみを買い物客管理領域に記録する。

さらに、過去の履歴がないため正常に記録できない旨の買い物客管理サーバ６からのメッセージを中間サーバ３で受信し（ＡＣＴ１１６でＮｏ）、なおかつ、当該メッセージを受信した中間サーバ３が取引情報に含まれる受領レコメンドＩＤと一致する過去の発行レコメンドＩＤを発見できたにも関わらず（ＡＣＴ１２４，ＡＣＴ１２５でＹｅｓ）、その発行レコメンドＩＤがｎｕｌｌもしくは仮ＩＤでない場合（ＡＣＴ１２６でＮｏ）は、その顧客が複数の会員ＩＤ（すなわち正式なＩＤ）を持っていることになる。この場合、中間サーバ３は、今回送られてきた買い物客ＩＤの過去履歴は探し出すことができなかったものとして、履歴が存在しない旨のメッセージを買い物客管理サーバ６に送信する（ＡＣＴ１２９）。かかるメッセージを受信した買い物客管理サーバ６は、今回受信した取引情報のみを買い物客管理領域に記録する。

このように、本実施形態の顧客システムによれば、データ破損や会員の二重登録等の場合にもシステム停止が発生しにくいメリットがある。

以上のように、本実施形態の顧客システムによれば、顧客ごとに登録された顧客情報を持たない場合でも顧客の購入履歴を長期に亘って管理することができる。

上述した実施形態では、説明の簡明化のため、決済対象を商品のみとして説明したが、これに限られない。例えば、店舗で扱う決済対象として、商品のみならず役務（サービス）を含めてもよいことは勿論である。したがって、決済対象が商品である場合に、チラシに印刷されるレコメンド対象が役務となること、あるいはこの逆に、決済役務に対してチラシにレコメンド商品が印刷されることもできる。

本発明は、その精神または主要な特徴から逸脱することなく、他の様々な形で実施することができる。そのため、前述の実施の形態はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には、なんら拘束されない。さらに、特許請求の範囲の均等範囲に属する全ての変形、様々な改良、代替及び改質は、すべて本発明の範囲内のものである。

１ 商品推薦サーバ
２ ＰＯＳ端末
３ 中間サーバ（顧客管理装置）
３１ 演算部
３２ 記憶部
３３ 記録部
３４ ネットワーク接続部
３５ 表示部
３６ 操作部
４ プリンタ（印刷装置）
５ 商品マスタサーバ
６ 買い物客管理サーバ
７ ネットワーク

Claims (5)

1. 商品購入または役務提供の決済の際に、決済に係る商品または役務（以下、商品または役務を「商品等」、決済に係る商品または役務を「決済商品等」と称する。）のＩＤと、前記決済に係る商品等に基づくレコメンド商品または役務（以下「レコメンド商品等」と称する。）の情報と、をレコメンドＩＤに対応付けてデータベースに記録する記録部と、
   前記決済の際に商品購入者または役務の提供を受ける者（以下「決済者」と称する。）に渡される販促物に、前記レコメンドＩＤの情報と前記レコメンド商品等の情報を印刷するように外部の印刷装置に指示する印刷指示部と、
   前記販促物を提示しての商品等の決済の際に、当該決済商品等のＩＤ及び当該販促物に印刷された前記レコメンドＩＤの情報を受信する受信部と、
   受信された前記レコメンドＩＤと同一のＩＤが前記データベースに記録された過去のレコメンドＩＤの中に存在するかを判定する判定部と、
   同一のＩＤが過去のレコメンドＩＤの中に存在すると判定された場合に、当該レコメンドＩＤを有する各取引の記録に、同一の顧客識別情報を付与するように前記データベースを更新する管理制御部と、
   を備える顧客管理装置。
2. 前記決済の際に、前記レコメンドＩＤの情報とともに、前記顧客識別情報とは異なる番号体系の本会員ＩＤが前記受信部で受信され、該受信された前記レコメンドＩＤと同一のＩＤが前記データベースに記録された過去のレコメンドＩＤの中に存在すると前記判定部が判定した場合、
   前記管理制御部は、前記受信されたレコメンドＩＤと同一のＩＤを有する過去の取引の前記顧客識別情報を、当該本会員ＩＤに書き換えるようにデータベースを更新する請求項１記載の顧客管理装置。
3. 前記管理制御部は、前記データベースを更新すると、更新された取引に係る取引情報のうち前記顧客識別情報及び決済商品等のＩＤを外部装置に送信する請求項１又は２記載の顧客管理装置。
4. 商品購入者または役務の提供を受ける者（以下「決済者」と称する。）に渡される販促物を用いて顧客を管理するシステムであって、
   前記販促物を印刷する印刷装置と、
   商品購入または役務提供の決済の際に、決済に係る商品または役務（以下、商品または役務を「商品等」、決済に係る商品または役務を「決済商品等」と称する。）のＩＤと、前記決済に係る商品等に基づくレコメンド商品または役務（以下「レコメンド商品等」と称する。）の情報と、をレコメンドＩＤに対応付けてデータベースに記録する記録部と、
   前記決済の際に前記決済者に渡される前記販促物に、前記レコメンドＩＤの情報と前記レコメンド商品等の情報を印刷するように外部の印刷装置に指示する印刷指示部と、
   前記販促物を提示しての商品等の決済の際に、当該決済商品等のＩＤ及び当該販促物に印刷された前記レコメンドＩＤの情報を受信する受信部と、
   受信された前記レコメンドＩＤと同一のＩＤが前記データベースに記録された過去のレコメンドＩＤの中に存在するかを判定する判定部と、
   同一のＩＤが過去のレコメンドＩＤの中に存在すると判定された場合に、当該レコメンドＩＤを有する各取引の記録に、同一の顧客識別情報を付与するように前記データベースを更新する管理制御部と、を備える顧客管理装置と、
   を含む顧客管理システム。
5. 商品購入または役務提供の決済時に商品購入者または役務の提供を受ける者（以下「決済者」と称する。）に渡される販促物を用いて顧客を管理する方法であって、
   コンピュータが、
   商品購入または役務提供の決済の際に、決済に係る商品または役務（以下、商品または役務を「商品等」、決済に係る商品または役務を「決済商品等」と称する。）のＩＤと、前記決済に係る商品等に基づくレコメンド商品または役務（以下「レコメンド商品等」と称する。）の情報と、を外部装置から受信し、
   受信された決済商品等のＩＤ及び前記レコメンド商品等に関する情報をレコメンドＩＤに対応付けてデータベースに記録し、
   印刷装置に印刷指示を出力し、
   前記印刷装置が、前記印刷指示に基づいて前記販促物に前記レコメンドＩＤの情報と前記レコメンド商品等の情報を印刷し、
   前記販促物を提示しての商品等の決済の際に、前記コンピュータが、
   当該販促物に印刷された前記レコメンドＩＤの情報を外部装置から受信し、
   受信された前記レコメンドＩＤと同一のＩＤが前記データベースに記録された過去のレコメンドＩＤの中に存在するかを判定し、
   同一のＩＤが過去のレコメンドＩＤの中に存在すると判定された場合に、当該レコメンドＩＤを有する各取引の記録に、同一の顧客識別情報を付与するように前記データベースを更新する
   顧客管理方法。