JP5993717B2 - 広告提供システム - Google Patents

Description

本発明は、自動取引装置を用いた広告提供システムに関する。

近年、ＡＴＭ（Automated Teller Machine）、ＣＤ（Cash Dispenser）等の自動取引装置と顧客情報管理（Customer Relationship Management）装置とを連携させ、自動取引装置での取引中における顧客操作の空き時間、例えば未記帳データの印字中、現金の計数中等に商品案内などの広告を顧客操作表示部の画面に表示するシステムが実用化されている（特許文献１参照）。
また、自動取引装置と、商品に関する情報を格納するＰＯＳ（Point Of Sales）端末とを連携させ、商品の販売実績と連携して自動取引装置でクーポンを発行するシステムが提案されている（特許文献２参照）。

特開２００９−３２２８５号公報 特開２００８−２３４５１２号公報

従来の技術では、自動取引装置にて広告表示あるいはクーポン発行する商品を決定する際、あらかじめデータベース等に格納された商品の情報や、ＰＯＳ端末に格納された商品の売上高および売上数の販売実績情報を基にしている。しかし商品の在庫数には着目していないため、自動取引装置での取引中に顧客に商品の広告表示を行っても、そのとき既に広告商品が売り切れているという現象が起こる可能性がある。売り切れている商品の広告を提供した場合、広告商品を取り扱う店舗側にも自動取引装置の利用顧客にもメリットが少ない。

また従来の技術では、ＰＯＳ端末に格納された商品の販売実績情報から「どの商品を」広告提供するかを決定している。しかし、この手法によっては「誰に（どんな顧客に）」対して広告を提供するかについて販売実績情報を活かせておらず、顧客に対しての訴求効果が低い。

本発明は、前記従来のシステムの問題点を解決し、顧客に対する訴求効果の高い広告提供を行うことが可能な広告提供システムを提供することを目的とする。

上記課題を解決するために、本発明は、自動取引装置による取引がされた時の商品の在庫に応じて、広告情報を自動取引装置に送信する管理システムを備える。

本発明によれば、商品の在庫に応じて広告を提供できる。

本発明の実施例１における自動取引装置広告提供システムの構成を例示する図である。 本発明の実施例１におけるストア・コントローラ内のＰＬＵファイルに格納されている情報を例示する図である。 本発明の実施例１におけるストア・コントローラ内の在庫ＤＢに格納されている情報を例示する図である。 本発明の実施例１におけるＣＲＭ装置内の顧客ＤＢに格納されている情報を例示する図である。 本発明の実施例１におけるＣＲＭ装置内の店舗ＤＢに格納されている情報を例示する図である。 本発明の実施例１におけるＣＲＭ装置内のＣＲＭ ＤＢに格納されている情報を例示する図である。 本発明の実施例１における各装置の処理及び情報の送受信を例示するシーケンス図である。 本発明の実施例１における自動取引装置１１１とＣＲＭ装置１２１との処理を例示するシーケンス図である。 本発明の実施例１におけるＣＲＭ装置が提供広告を決定する動作を例示するフローチャートである。 本発明の実施例１における自動取引装置の顧客操作画面に表示する広告を例示する図である。 本発明の実施例２におけるストア・コントローラ内の履歴ＤＢに格納されている情報を例示する図である。 本発明の実施例２におけるホストコンピュータで算出するデータを例示する図である。 本発明の実施例２におけるＣＲＭ装置内の顧客ＤＢに格納されている情報の一部を例示する図である。 本発明の実施例２におけるＣＲＭ装置内のＣＲＭ ＤＢに格納されている情報の一部を例示する図である。 本発明の実施例２における各装置の処理及び情報の送受信を例示するシーケンス図である。 本発明の実施例２におけるＣＲＭ装置が提供広告を決定する動作を例示するフローチャートである。 本発明の実施例３におけるストア・コントローラ内のＰＬＵファイルに格納されている情報を例示する図である。 本発明の実施例３におけるストア・コントローラ内のセールＤＢに格納されている情報を例示する図である。 本発明の実施例３におけるＣＲＭ装置内のＣＲＭ ＤＢに格納されている情報を例示する図である。 本発明の実施例３におけるＣＲＭ装置が提供広告を決定する動作を例示すするフローチャートである。

以下、実施例を図面を用いて説明する。

実施例１として、広告商品の在庫量に応じて広告提供をするか否かを決定する広告提供システムの例を説明する。図１は、本発明の実施例１における広告提供システムの構成図である。広告提供システムは、金融システム１００及びＰＯＳシステム２００を備える。金融システム１００及びＰＯＳシステム２００は、ネットワーク３００を介して接続されることにより連携して、広告提供システムを実現する。ネットワーク３００は、専用線等の通信回線である。

金融システム１００は、自動取引装置１１１と顧客情報管理装置（以下ＣＲＭ装置）１２１とを備える。自動取引装置１１１及びＣＲＭ装置１２１は、ネットワーク１３０を介して接続されている。ネットワーク１３０は、専用線等の通信回線である。自動取引装置１１１は、ＡＴＭ、ＣＤ等であり、ＣＰＵ（このＣＰＵを含め、以下、何れのＣＰＵも図示しない）とメモリ（フラッシュＲＯＭ、ＲＡＭ等）（このメモリを含め、以下、何れのメモリも図示しない）とを備える。

自動取引装置１１１は、銀行、信用金庫、郵便局、消費者金融会社等の金融機関の支店内または店外等（以下、単に「支店」という）１１０に設置される。自動取引装置１１１は、ＣＰＵとメモリとを備え、金融機関の顧客が自ら操作して入金、出金、通帳記帳、残高照会、振り込み、振替等の金融取引を行うための装置である。

ＣＲＭ装置１２１は、金融機関の地区センター１２０等に設置される。ＣＲＭ装置１２１は、ＣＰＵとメモリとを備え、顧客、商品、広告情報等を管理する装置である。ＣＲＭ装置１２１のメモリは、顧客情報データベース（以下「顧客ＤＢ」という）１２２と、店舗情報データベース（以下「店舗ＤＢ」という）１２３と、ＣＲＭ情報データベース（以下「ＣＲＭ ＤＢ」という）１２４とを格納する。

ＰＯＳシステム２００は、ホストコンピュータ２１１と商品情報管理装置（以下「ストア・コントローラ」という）２２１とを備える。ホストコンピュータ２１１及びストア・コントローラ２２１は、ネットワーク２３０を介して接続されている。ネットワーク２３０は、専用線等の通信回線である。ホストコンピュータ２１１は、ＣＰＵとメモリとを備え、小売店本部等（以下「本部」という）２１０に設置される。ホストコンピュータ２１１は、本部２１０の管理下の小売店店舗等（以下「店舗」という）２２０の情報を一元管理する装置である。ストア・コントローラ２２１は、店舗２２０に設置されるコンピュータであり、ＣＰＵとメモリとを備える。ストア・コントローラ２２１は、店舗２２０で取り扱う商品の商品名、価格、在庫数、店舗２２０の売り上げ等の情報を管理するために、ＰＬＵ（Price Look Up）ファイル２２２、在庫情報データベース（以下在庫ＤＢ）２２３を備える。

図２は、実施例１におけるＰＬＵファイル２２２に格納されている情報を例示する図である。ＰＬＵファイル２２２は、先述した通りストア・コントローラ２２１のメモリに格納されている。ＰＬＵファイル２２２は、店舗２２０で取り扱う商品の商品ＩＤ、商品名、価格等の情報を格納する。商品ＩＤは、同一店舗２２０内で取り扱う商品の種類を一意に識別するための情報である。

図３は、実施例１における在庫ＤＢ２２３に格納されている情報（在庫マスタ）を例示する図である。在庫ＤＢ２２３は、先述した通りストア・コントローラ２２１のメモリに格納されている。図３に示す在庫マスタは、店舗２２０で取り扱う商品の商品ＩＤ、在庫数等の情報を格納する。ここでの在庫数の情報は、店舗２２０において顧客が購入可能な商品数を示す。

図４は、本発明の実施例１におけるＣＲＭ装置１２１内の顧客ＤＢ１２２のメモリに格納されている情報（口座マスタ）を例示する図である。図４に示す口座マスタは、顧客が持っている口座の銀行コード、店番号、口座番号、顧客ＩＤ等の情報を格納する。銀行コード、店番号、口座番号の組み合わせは、同じ組み合わせが複数、存在しないように定められている。顧客ＩＤは、顧客を一意に識別するための情報である。

図５は、本発明の実施例１におけるＣＲＭ装置１２１内の店舗ＤＢ１２３のメモリに格納されている情報（店舗マスタ）を例示する図である。図５に示す店舗マスタは、店舗ＩＤ、店舗名等の情報を格納している。店舗ＩＤは、店舗２２０を一意に識別するための情報である。なお、店舗マスタは、住所、電話番号、営業時間等の情報を格納していてもよい。

図６は、本発明の実施例１におけるＣＲＭ ＤＢ１２４のメモリに格納されている情報（商品マスタ及びサービス決定マスタ）を例示する図である。

図６（ａ）に示す商品マスタは、コンテンツＩＤ、店舗ＩＤ、商品ＩＤ、商品名、在庫数、価格等の情報を格納する。店舗ＩＤ、商品ＩＤの組み合わせは、同じ組み合わせが複数、存在しないように定められている。コンテンツＩＤは、広告内容を一意に識別するための情報である。

ＣＲＭ ＤＢ１２４は、広告内容を示す情報を、随時、外部から取得する。広告内容を取得すると、ＣＲＭ装置１２１は、顧客ＤＢ１２２内の口座マスタに格納されている顧客ＩＤと、ＣＲＭ ＤＢ１２４内の商品マスタに格納されているコンテンツＩＤとを、予め定義した条件等で関連付けて、サービス決定マスタに格納する。このように情報が格納されることによって、どの顧客にどの商品の広告を提供するかが一意に決定される。

図６（ｂ）は、サービス決定マスタを例示する図である。サービス決定マスタは、顧客ＩＤ、コンテンツＩＤ等の情報を格納している。顧客ＩＤは、顧客を一意に識別するための情報である。

図７は、実施例１における各装置の処理と情報の送受信とを例示するシーケンス図である。ストア・コントローラ２２１が格納する情報が、ＣＲＭ装置１２１が格納する情報へ反映されることを、図７と共に説明する。ストア・コントローラ２２１のＣＰＵは、商品ＩＤ、商品名、価格、在庫数等の情報（以下、これらをまとめて「商品情報」という）の入力を受けると、入力された情報に従って、ＰＬＵファイル２２２に格納された情報と、在庫ＤＢ２２３の在庫マスタに格納された情報とを更新する（Ｓ１１）。上記情報の取得は、ＰＯＳ端末（図示しない）等からの入力を通じて実行される。上記情報の更新とは、情報の追加、変更、削除等である。

ストア・コントローラ２２１のＣＰＵは、上記情報の更新を実行することによって在庫が０個になった場合および在庫が０個から増えた場合、ＰＬＵファイル２２２又は在庫マスタに格納された商品情報と、店舗ＩＤ等の情報（以下、これらをまとめて「商品店舗情報」という）とを、ＣＲＭ装置１２１へ送信する（Ｓ１２）。なお、本部２１０が商品の在庫数を管理する場合には、同様の情報をストア・コントローラ２２１からホストコンピュータ２１１に送信する（Ｓ１３）。

ＣＲＭ装置１２１のＣＰＵは、ストア・コントローラ２２１から商品店舗情報を取得すると、ＣＲＭ ＤＢ１２４内の商品マスタに、受信した情報を格納する（Ｓ１４）。この格納は、該当するレコードに対する上書きによって実現される。

商品の在庫数が０個になった場合について説明する。店舗２２０で顧客が商品を購入すると、ＰＯＳ端末等は、購入された商品の商品ＩＤと購入数とを示す情報を、操作者による操作に従ってストア・コントローラ２２１に入力する。ストア・コントローラ２２１のＣＰＵは、購入された商品の商品ＩＤ、購入数を示す情報の入力を受けると、その情報に基づき在庫マスタを更新する（Ｓ１１）。商品が購入された場合の更新は、入力された商品ＩＤと、在庫ＤＢ２２３内の在庫マスタに格納されている商品ＩＤとを比較し、一致したレコードの在庫数から、入力された購入数を減算することによって実現される。

更新の結果、在庫マスタに格納されている在庫数が０個になった場合、ストア・コントローラ２２１は、在庫切れになった商品についての商品店舗情報をＣＲＭ装置１２１へ送信する（Ｓ１２）。

ＣＲＭ装置１２１は、ストア・コントローラ２２１から商品店舗情報を受信すると、受信した商品ＩＤと、ＣＲＭ ＤＢ１２４内の商品マスタに格納されている商品ＩＤとを比較して、一致したレコードの在庫数を、受信した在庫数（０個）に更新する（Ｓ１４）。

商品の在庫が補充された場合について説明する。店舗２２０において在庫マスタに格納されている在庫数が０個であった商品が小売店業者等によって補充された場合、ＰＯＳ端末等は、補充された商品の商品ＩＤと補充数とを示す情報を、操作者による操作に従ってストア・コントローラ２２１に入力する。ストア・コントローラ２２１のＣＰＵは、入力された商品ＩＤと、在庫ＤＢ２２３内の在庫マスタに格納されている商品ＩＤとを比較し、一致したレコードの在庫数に、入力された補充数を加算してレコードを更新する（Ｓ１１）。

ストア・コントローラ２２１のＣＰＵは、補充された商品についての商品店舗情報をＣＲＭ装置１２１へ送信する（Ｓ１２）。

ＣＲＭ装置１２１のＣＰＵは、ストア・コントローラ２２１から商品店舗情報を受信すると、受信した商品ＩＤとＣＲＭ ＤＢ１２４内の商品マスタに格納されている商品ＩＤとを比較して、一致したレコードの在庫数を、受信した在庫数（補充数）に更新する（Ｓ１４）。

なお、ストア・コントローラ２２１からＣＲＭ装置１２１へ送信する情報には、店舗ＩＤが含まれなくてもよい。この場合、ＣＲＭ装置１２１は、例えば、予め格納した店舗２２０を特定するための情報と、通信情報とによって送信元を識別することで、店舗を特定する。

図８は、自動取引装置１１１とＣＲＭ装置１２１との処理を例示するシーケンス図である。この処理は、自動取引装置１１１で顧客による取引があった場合に実行される。顧客が支店１１０に設置された自動取引装置１１１を操作して金融取引を行うと、自動取引装置１１１のＣＰＵは、銀行コード、店番号、口座番号等の顧客識別情報を取引媒体（キャッシュカード、通帳等）から取得する（Ｓ１５）。取引媒体からの情報取得は、顧客によって自動取引装置１１１の媒体挿入口に挿入された取引媒体を、自動取引装置１１１が読み込むことで実現される。

続いて自動取引装置１１１のＣＰＵは、読み取った顧客識別情報をＣＲＭ装置１２１へ送信する（Ｓ１６）。ＣＲＭ装置１２１のＣＰＵは、顧客識別情報を自動取引装置１１１から受信すると、ＤＢ検索処理を実行する（Ｓ１７）。

図９は、ＤＢ検索処理を例示するフローチャートである。ＤＢ検索処理は、実施例１におけるＣＲＭ装置１２１が提供広告をするか否かを決定するための処理である。図９を参照しながら、ＣＲＭ装置１２１が実行するＤＢ検索処理（Ｓ１７）について説明する。

ＣＲＭ装置１２１のＣＰＵは、自動取引装置１１１から顧客識別情報を受信すると、受信した顧客識別情報と、顧客ＤＢ１２２内の口座マスタに格納されている顧客識別情報とを比較して、一致したレコードの顧客ＩＤを取得する（Ｓ３１）。

次にＣＲＭ装置１２１のＣＰＵは、取得した顧客ＩＤと、ＣＲＭ ＤＢ１２４内のサービス決定マスタに格納されている顧客ＩＤとを比較して、一致したレコードのコンテンツＩＤを取得する（Ｓ３２）。

続いてＣＲＭ装置１２１のＣＰＵは、取得したコンテンツＩＤと、ＣＲＭ ＤＢ１２４内の商品マスタに格納されているコンテンツＩＤとを比較して、一致したレコードの在庫数の情報を取得し（Ｓ３３）、商品の在庫が有るか無いかを、取得した在庫数の情報に基づき判断する（Ｓ３４）。

商品の在庫が有る場合には（Ｓ３４、あり）、ＣＲＭ装置１２１のＣＰＵは、ＣＲＭ ＤＢ１２４内の商品マスタに格納されている商品店舗情報を取得し（Ｓ３５）、取得した店舗ＩＤと、顧客ＤＢ１２３内の店舗マスタに格納されている店舗ＩＤとを比較して、一致したレコードの店舗名等の店舗情報を取得し（Ｓ３６）、処理を終了する。商品の在庫が無い場合には（Ｓ３４、なし）、広告提供のための情報取得を行わず、処理を終了する。

図８に戻って説明する。ＣＲＭ装置１２１は、広告提供のための情報を取得した場合は、取得した商品情報、店舗情報等の広告情報を、自動取引装置１１１へ送信する（Ｓ１９）。広告提供のための情報を取得しなかった場合は、広告提供を行わない旨の情報を自動取引装置１１１へ送信する（Ｓ１９）。なお、広告提供を行わない場合は、広告提供についての情報を送信しなくてもよい。

自動取引装置１１１は、ＣＲＭ装置１２１内でのＤＢ検索処理（Ｓ１７）と並行して、顧客の選択した金融取引の処理を行う（Ｓ１８）。広告提供を行わない旨の情報を自動取引装置１１１がＣＲＭ装置１２１から受信した場合、又は広告提供についての情報を受信しなかった場合、自動取引装置１１１のＣＰＵは、未記帳データ印字中、又は現金の計数中等、顧客操作の空き時間に、顧客操作画面に「ただいま処理中です。しばらくお待ちください。」等の処理中メッセージを表示する（Ｓ２０）。

一方、自動取引装置１１１が、ＣＲＭ装置１２１から商品情報、店舗情報等の広告情報をＣＲＭ装置１２１から受信した場合、自動取引装置１１１のＣＰＵは、未記帳データ印字中、又は現金の計数中等、顧客操作の空き時間に、上記処理中メッセージに替えて、ＣＲＭ装置１２１から受信した店舗名、商品名、値段等の広告情報を、顧客操作画面へ表示する（Ｓ２１）。

図１０は、本発明の実施例１における自動取引装置１１１の顧客操作画面に表示される広告の例を示す。なお、自動取引装置１１１の顧客操作画面で表示する広告情報として、店舗２２０の住所、電話番号、営業時間等を表示させてもよい。

図８に戻って説明する。自動取引装置１１１は、取引明細票を排出し、取引媒体を返却して、取引を終了する（Ｓ２２）。金融取引における指示に基づき取引明細票を発行する場合、自動取引装置１１１は、自動取引装置１１１の顧客操作画面に表示した広告情報と同様の内容を、排出前の取引明細票に印字する。

なお、広告情報の提供については、自動取引装置１１１の顧客操作画面への表示及び取引明細票への印字を行うと説明したが、自動取引装置１１１の顧客操作画面への表示のみ、あるいは取引明細票への印字のみであってもよい。また、広告提供の方法は、顧客操作画面への表示や取引明細票の印字以外にも、音声案内等の手段を組み合わせてもよいし、画面の表示は動画であっても良い。また、自動取引装置１１１の顧客操作画面によって広告提供を行うタイミングについては金融取引処理の最中であっても、終了後であってもよい。

以上説明した実施例１によれば、店舗２２０で管理する在庫数情報をＣＲＭ装置１２１に送信し、ＣＲＭ ＤＢ１２４内の商品マスタに反映したことにより、在庫が有る商品についての広告を、自動取引装置１１１の利用顧客に提供できる。これによって、広告の訴求効果を高くすることができ、ひいては、サービスが顧客によって十分に活用され、顧客満足度を高くすることができる。また、金融取引を行う顧客は、金融資産を所有している可能性が高く、さらに、現金を引き出した顧客は、現金を所持していることによって購買意欲が高いと推定される。また、レジにおいて広告を提供する場合と異なり、買い物をする前に広告を提供できる。よって、このような顧客に広告を提供することは、効果が高いと言える。また、既存のハードウェアを用いて実現できるので、新たに必要なコストを抑制している。

商品の在庫数が０個になった場合において、ストア・コントローラ２２１からＣＲＭ装置１２１又はホストコンピュータ２１１へ送信される在庫数が０個という情報は、在庫無しを示す情報に変更しても良い。或いは、商品の在庫が補充された場合において、ＣＲＭ装置１２１内の商品マスタに格納される商品の在庫数を示す情報は、在庫有りを示す情報に変更しても良い。

ストア・コントローラ２２１からＣＲＭ装置１２１又はホストコンピュータ２１１へ商品店舗情報を送信するタイミングは、実施例１においては、在庫マスタに格納されている在庫数が０個になった場合、又は０個から１個以上に更新された場合である。この手法に替えて、閾値（０個でない個数を示す値）を採用し、在庫数が閾値を超えた、又は閾値以下になった商品についての商品店舗情報を送信するようにしてもよい（Ｓ１２）（Ｓ１３）。

上記閾値の採用に伴い、ＣＲＭ装置１２１内での広告提供をするか否かの判断基準を、在庫が有るか否かに替えて、在庫数が閾値以上か否かに変更してもよい。在庫数が閾値以下になった場合は、間もなく売り切れる可能性があることを考慮し、広告提供しないとしてもよい。或いは、在庫数が残りわずかなので急いで買い求めるよう勧めるようなメッセージを表示させてもよい。

実施例２では、ＰＯＳシステムで管理する販売履歴と販売傾向分析データとを基にして、顧客へ提供する広告を決定する広告提供システムの例を説明する。なお、実施例１と構成、又は各装置に格納されている情報が同じであるものについては説明を省略する。

実施例２における広告提供システムでは、ストア・コントローラ２２１が履歴ＤＢ２２４（図１参照）を格納する。

図１１〜図１３を参照しながら、各装置に格納される情報を説明する。これらの情報は、実施例１において説明した情報に対して、追加で格納される。

図１１は、本発明の実施例２におけるストア・コントローラ２２１内の履歴ＤＢ２２４に格納されている履歴情報を例示する図である。図１１に示す履歴情報は、商品の購入が行われた日時、商品ＩＤ、数量、購買者の年齢層、購買者の性別等の情報を含む。なお、履歴ＤＢ２２４に、購入された商品の商品名、価格等の情報を追加で格納してもよい。

図１２は、本発明の実施例２におけるホストコンピュータ２１１で算出するデータを例示する図である。図１２に示す販売傾向分析データは、年齢層、性別、商品ＩＤ、売れ行きレベル等の項目を含む。年齢層の項目は、値の範囲が重複しないようになっており、例えば、１０歳代、２０歳代等である。売り上げレベルは、実施例２では、販売した商品の数量の多さの順位を示す情報とする。

図１３は、本発明の実施例２におけるＣＲＭ装置１２１内の顧客ＤＢ１２２に格納されている情報の一部を例示する図である。ＣＲＭ装置１２１内の顧客ＤＢ１２２は、図４に示す口座マスタに加え、図１３に示す顧客マスタを格納する。顧客マスタは、顧客の顧客ＩＤ、年齢、性別等の情報を格納する。なお、顧客マスタには、顧客の顧客名、住所、電話番号等の情報が格納されてもよい。

図１４は、本発明の実施例２におけるＣＲＭ装置１２１内のＣＲＭ ＤＢ１２４に格納されている情報（サービス決定マスタ）の一部を例示する図である。この情報は、実施例１のサービス決定マスタ（図６（ｂ））の替わりに格納される情報である。図１４に示すサービス決定マスタは、年齢層、性別、コンテンツＩＤ、優先順位等の情報を格納する。実施例２のサービス決定マスタは、実施例１のサービス決定マスタ（図６（ｂ））に格納されている情報のうち、顧客ＩＤの代わりに年齢層、性別を格納し、さらに優先順位を追加したものである。なお、年齢層、性別の組み合わせには、重複があってもよい。

取り扱う商品の種類が増減、変更、又は価格変更した場合等に、ストア・コントローラ２２１が格納する情報を、ＣＲＭ装置１２１へ反映することについては、実施例１と同様であるため、説明を省略する。但し、サービス決定マスタへ情報を格納する点については、実施例１と異なるので後述する。

商品の在庫数が０個になった場合、及び商品の在庫が補充された場合については、ストア・コントローラ２２１、ＣＲＭ装置１２１の処理動作は実施例１と同様であるため、説明を省略する。

図１５は、本発明の実施例２における各装置の処理及び情報の送受信を例示するシーケンス図である。この処理は、実施例１の処理に追加される処理で実行される。店舗２２０で顧客が商品を購入すると、ストア・コントローラ２２１のＣＰＵは、ＰＯＳ端末等から履歴情報の入力を受け付け、入力された情報を履歴ＤＢに格納する（Ｓ４１）。

ストア・コントローラ２２１のＣＰＵは、履歴情報を一定期間分集計して蓄積し、蓄積した履歴情報を定期的にホストコンピュータ２１１へ送信する（Ｓ４２）。

ホストコンピュータ２１１のＣＰＵは、本部２１０管理下の各店舗のストア・コントローラ２２１から履歴情報を受信し、購買者の年齢層、性別等から、どの商品が多く購入されているかを集計して、年齢層、性別、商品ＩＤ、売れ行きレベル等の項目を含む販売傾向分析データを算出（Ｓ４３）する。ホストコンピュータ２１１のＣＰＵは、算出した販売傾向分析データを、ストア・コントローラ２２１へ送信する（Ｓ４４）。

実施例２では、売れ行きレベルは、例えば、ホストコンピュータ２１１のＣＰＵが集計した販売情報から、年齢層、性別等の項目ごとに、多く売れた商品の順に順位付けした情報である。

ストア・コントローラ２２１のＣＰＵは、ホストコンピュータ２１１から販売傾向分析データを受信すると、受信した販売傾向分析データ、及び店舗２２０ごとに付与された店舗ＩＤ等の情報を、ＣＲＭ装置１２１へ送信する（Ｓ４５）。

ＣＲＭ装置１２１のＣＰＵは、ストア・コントローラ２２１から販売傾向分析データ、店舗ＩＤ等の情報を受信すると、受信した商品ＩＤ、店舗ＩＤと、ＣＲＭ ＤＢ１２４内の商品マスタに格納されている商品ＩＤ、店舗ＩＤとを比較して、一致したレコードのコンテンツＩＤを取得する（Ｓ４６）。

ＣＲＭ装置１２１のＣＰＵは、受信した年齢層、性別等の情報、取得したコンテンツＩＤを、売れ行きレベルの情報を基に設定した優先順位と共に、ＣＲＭ ＤＢ１２４内のサービス決定マスタに格納する（Ｓ４７）。

売れ行きレベルと優先順位との対応付けの手法は種々、考えられる。例えば、販売傾向分析データにおいて、ある年齢層、性別に対して売れ行きレベルの高い商品は、その年齢層、性別の顧客への広告効果が高いと考えられるため、サービス決定マスタにおいても、同一の年齢層、性別の顧客に対して、同一商品の優先順位を高く設定することが望ましい。

ここでは売れ行きレベルの情報をそのまま優先順位に格納するが、例えば、売れ行きレベルの１〜１０位までを優先順位の情報として優先度が最も高いＡとし、売れ行きレベルの１１〜２０位までを優先順位の優先度が２番目に高いＢとする、等のように対応付けて格納してもよい。

自動取引装置１１１で顧客による取引があった場合について説明する。自動取引装置１１１で取引があった場合、実施例１と異なるのは、ＣＲＭ装置内での提供広告決定の流れ（ＤＢ検索処理）のみであり、他のステップは同じである。

図１６は、実施例２のＤＢ検索処理を例示するフローチャートである。図１６に示したＤＢ検索処理は、実施例１のＤＢ検索処理の替わりに実行される処理であり、本発明の実施例２におけるＣＲＭ装置１２１が提供する広告を決定するための処理である。

ＣＲＭ装置１２１のＣＰＵは、自動取引装置１１１から顧客識別情報を受信すると、受信した顧客識別情報と、顧客ＤＢ１２２内の口座マスタに格納されている顧客識別情報とを比較して、一致したレコードの顧客ＩＤを取得する（Ｓ６１）。

次にＣＲＭ装置１２１のＣＰＵは、取得した顧客ＩＤと、顧客ＤＢ１２２内の顧客マスタに格納されている顧客ＩＤとを比較して、一致したレコードの年齢、性別等の情報を取得する（Ｓ６２）。

ＣＲＭ装置１２１のＣＰＵは、取得した年齢、性別と、ＣＲＭ ＤＢ１２４内のサービス決定マスタに格納されている年齢層、性別とを比較して、一致したレコードのコンテンツＩＤを取得する（Ｓ６３）。一致するレコードが複数ある場合は、取得するコンテンツＩＤを優先順位に従って決定する。「取得するコンテンツＩＤを優先順位に従って決定する」とは、例えば、優先順位の高いレコードほど、選択される頻度が高いことを示す。

例えば、顧客ＤＢ１２２内の顧客マスタから２５歳という年齢の情報を取得した場合、ＣＲＭ ＤＢ１２４内のサービス決定マスタにおいては、その年齢の情報は、例えば２０歳代（２０〜２９歳）という年齢層の情報を格納するレコードと一致する。

ＣＲＭ装置１２１のＣＰＵは、取得したコンテンツＩＤと、ＣＲＭ ＤＢ１２４内の商品マスタに格納されているコンテンツＩＤとを比較して、一致したレコードの在庫数を取得し（Ｓ６４）、商品の在庫が有るか無いかを判断する（Ｓ６５）。

ＣＲＭ装置１２１のＣＰＵは、商品の在庫が有る場合には（Ｓ６５、あり）、ＣＲＭ ＤＢ１２４内の商品マスタに格納されている商品名、価格等の商品情報、及び店舗ＩＤを取得し（Ｓ６６）、取得した店舗ＩＤと、顧客ＤＢ１２３内の店舗マスタに格納されている店舗ＩＤとを比較して、一致したレコードの店舗名等の店舗情報を取得し（Ｓ６７）、処理を終了する。この後、実施例１と同様に、自動取引装置１１１による広告提供が実行される。

ＣＲＭ装置１２１のＣＰＵは、商品の在庫が無い場合には（Ｓ６５、なし）、広告提供のための情報取得を行わず、処理を終了する。

以上説明した実施例２によれば、本部２１０で管理する販売傾向分析データを、ＣＲＭ ＤＢ１２４内のサービス決定マスタに反映したことにより、販売傾向データにおける売れ行きレベルの高い商品の広告を自動取引装置１１１の利用顧客へ提供できる。売れ行きレベルの高い商品は、顧客への広告効果が高いと考えられる。このため、顧客への訴求効果が高くでき、ひいては、サービスが顧客によって十分に活用され、顧客満足度を高くすることができる。

ホストコンピュータ２１１で算出する販売傾向分析データの売れ行きレベルの項目は、上記では販売した商品の数量で順位付けした情報としたが、商品の売上金額で順位付けした情報でも、販売した商品の数量や、商品の売上金額に応じてランク付けした情報等でもよい。

どの広告を提供するかの判断材料は、上記では顧客の年齢、性別としたが、天候、イベント等の情報を判断材料として追加したり、年齢、性別と置き換えたりしてもよい。追加する場合は、例えば、以下の手順を採用してもよい。

ストア・コントローラ２２１内の履歴ＤＢに天候、イベント等の情報を格納し（Ｓ４１）、その他の履歴情報と共に、ホストコンピュータ２１１へ送信する（Ｓ４２）。ホストコンピュータ２１１は天候、イベント等の項目を含む販売傾向分析データを算出し（Ｓ４３）、算出した販売傾向分析データを、ストア・コントローラ２２１へ送信する（Ｓ４４）。ストア・コントローラ２２１は、ホストコンピュータ２１１から販売傾向分析データを受信すると、受信した販売傾向分析データ、及び店舗２２０ごとに付与された店舗ＩＤ等の情報を、ＣＲＭ装置１２１へ送信する（Ｓ４５）。ＣＲＭ装置１２１は、ストア・コントローラ２２１から販売傾向分析データ、店舗ＩＤ等の情報を受信すると、天候、イベント等の情報を他の情報と共にストア・コントローラ２２１内のサービス決定マスタへ格納する（Ｓ４６）。顧客が自動取引装置１１１による取引をしている時、自動取引装置１１１は、顧客識別情報に加えて、天候、イベント等の情報をＣＲＭ装置１２１へ送信する（Ｓ４８）。ＣＲＭ装置１２１が顧客識別情報、天候、イベント等の情報を受信すると、顧客ＤＢ１２２内の口座マスタ、及び顧客マスタ、ＣＲＭ ＤＢ１２４内のサービス決定マスタ、商品マスタを検索し（Ｓ４９）、受信した天候、イベント等の情報を照合する。

ＣＲＭ ＤＢ１２４内のサービス決定マスタに格納されている優先順位の情報の設定は、必須ではない。優先順位が設定されていない場合は、ＣＲＭ装置１２１内でのＤＢ検索処理（Ｓ４９）において、サービス決定マスタを検索し（Ｓ６３）、格納されている年齢層、性別と一致するレコードが複数あった場合に、ランダム、又は一致したレコード順に取得するコンテンツＩＤを決定する等としてもよい。

実施例３では、ＰＯＳシステムで管理するセール商品情報を基にして、顧客へ提供する広告を決定する広告提供システムの例を説明する。実施例１と同様であるものについては、説明を省略する。

実施例３における広告提供システムでは、ストア・コントローラ２２１がセールＤＢ２２５（図１参照）を格納する。

図１７は、本発明の実施例３におけるストア・コントローラ２２１内のＰＬＵファイル２２２に格納されている情報を例示する図である。図１７を参照しながら、実施例１のＰＬＵファイル２２２に格納される情報の替わりに、実施例３のストア・コントローラ２２１内のＰＬＵファイル２２２に格納される情報について説明する。ＰＬＵファイル２２２は、店舗２２０で取り扱う商品の商品ＩＤ、商品名、値引き前価格、値引き後価格、セールＩＤ等の情報を格納する。

セールＩＤは、店舗２２０でのセールイベントを一意に識別するための情報である。セールイベントとは、例えば、年末セール、早朝セール、バーゲンセール等を指す。実施例３のＰＬＵファイル２２２は、実施例１のＰＬＵファイル２２２（図２）に格納されている情報のうち、価格の代わりに値引き前価格、値引き後価格を格納し、さらにセールＩＤを追加したものである。セール対象の商品のレコードは、値引き前価格と値引き後価格の情報が異なっており、セールＩＤに情報が格納されている。セール対象外の商品については、値引き前価格、値引き後価格の両方に同じ情報が格納されており、セールＩＤに“-”が格納される。

図１８は、本発明の実施例３におけるストア・コントローラ２２１内のセールＤＢに格納されている情報を例示する図である。図１８を参照しながら、ストア・コントローラ２２１内のセールＤＢ２２５に格納される情報を説明する。セールＤＢ２２５は、実施例１の構成に対して追加されるものである。図１８に示すセールマスタは、セールＩＤ、セール開始日時、セール終了日時等の情報を格納する。

図１９は、本発明の実施例３におけるＣＲＭ装置１２１内のＣＲＭ ＤＢ１２４に格納されている情報を例示する図である。図１９を参照しながら、実施例１の商品マスタとサービス決定マスタとの替わりに、ＣＲＭ装置１２１内のＣＲＭ ＤＢ１２４に格納される商品マスタとサービス決定マスタについて説明する。

図１９（ａ）に示す商品マスタは、コンテンツＩＤ、店舗ＩＤ、商品ＩＤ、商品名、在庫数、値引き前価格、値引き後価格、セール開始日時、セール終了日時等の情報を格納する。図６（ａ）に示した商品マスタに格納されている情報のうち、価格の代わりに値引き前価格、値引き後価格を格納し、さらにセール開始日時、セール終了日時を追加したものである。セール対象の商品は、値引き前価格と値引き後価格の情報が異なっており、セール開始日時、セール終了日時に情報が格納されている。セール対象外の商品については、値引き前価格、値引き後価格の両方に同じ情報が格納されており、セール開始日時、セール終了日時に“-”が格納される。

図１９（ｂ）に示すサービス決定マスタは、顧客ＩＤ、コンテンツＩＤ、優先順位等の情報を格納する。図１９（ｂ）に示すサービス決定マスタは、図６（ｂ）に示したサービス決定マスタに格納されている情報に、優先順位を追加したものである。優先順位は、例えば、セール終了日時の日時情報が直近であるものから、優先度が高く設定される。

ストア・コントローラ２２１が格納する情報を、ＣＲＭ装置１２１へ反映することについて説明する。実施例１と異なる点は、在庫数に変化があった場合に加え、セールに関する情報に変化があった場合にも、その変化がＣＲＭ装置１２１へ反映されることである。以下で具体的に説明する。

ストア・コントローラ２２１は、商品またはセールに関する情報の入力を受け付けると、入力された情報に従って、ＰＬＵファイル２２２に格納された情報に対して追加、変更、削除を行う。その後、ストア・コントローラ２２１は、入力されたセールＩＤ、セール開始日時、セール終了日時等の情報に従って、セールＤＢ内のセールマスタに格納された情報に対して、追加、変更、削除を行う。商品またはセールに関する情報とは、商品ＩＤ、商品名、値引き前価格、値引き後価格、セールＩＤ、セール開始日時、セール終了日時、在庫数等の商品情報、セール情報等である。ストア・コントローラへの情報入力は、店舗２２０で取り扱う商品の種類が増減または変更したり、価格が変更されたりした場合、或いは店舗２２０でのセールイベントが企画、変更、中止された場合等に実行される。ストア・コントローラへの情報入力は、ホストコンピュータ２１１又はＰＯＳ端末等を通じて行われる。なお、在庫ＤＢ２２３内の在庫マスタに格納された情報に対する追加、変更、削除は、実施例１と同様であるため、説明を省略する。

そして、ストア・コントローラ２２１は、ＰＬＵファイル２２２、セールマスタ、在庫マスタに格納された商品ＩＤ、商品名、値引き前価格、値引き後価格、在庫数、セール開始日時、セール終了日時等の商品情報、及び店舗２２０ごとに付与された店舗ＩＤ等の情報を、ＣＲＭ装置１２１へ送信する。

ＣＲＭ装置１２１は、ストア・コントローラ２２１から商品ＩＤ、商品名、値引き前価格、値引き後価格、在庫数、セール開始日時、セール終了日時、店舗ＩＤ等の情報を受信すると、ＣＲＭ ＤＢ１２４内の商品マスタに、受信した店舗ＩＤ、商品ＩＤ、商品名、在庫数、値引き前価格、値引き後価格、セール開始日時、セール終了日時等を、レコードを一意に識別するコンテンツＩＤと共に格納する。さらに、どの顧客にどの商品を広告提供するかを定義するために、顧客ＤＢ１２２内の口座マスタに格納されている顧客ＩＤと、ＣＲＭ ＤＢ１２４内の商品マスタに格納されているコンテンツＩＤとを、あらかじめ定義した条件等で関連付けて、優先順位と共にサービス決定マスタへ格納する。

ここで、ＣＲＭ ＤＢ１２４内の商品マスタに格納されているコンテンツＩＤを抽出する条件は、例えば、セール対象の商品である。セール対象の商品かどうかは、値引き前価格と値引き後価格の情報に差がある、又はセール開始日時、セール終了日時に日時情報が格納されているレコードとする。

商品の在庫数が０個になった場合、商品の在庫が補充された場合、又は自動取引装置１１１で顧客による取引があった場合については、各装置の処理動作は実施例１と同様であるため、説明を省略する。

図２０は、本発明の実施例３におけるＤＢ検索処理を例示するフローチャートである。この検索処理は、実施例１のＤＢ検索処理の替わりに実行される。

ＣＲＭ装置１２１のＣＰＵは、自動取引装置１１１から顧客識別情報を受信すると、受信した銀行コード、店番号、口座番号等の顧客識別情報と、顧客ＤＢ１２２内の口座マスタに格納されている銀行コード、店番号、口座番号等の顧客識別情報を比較して、一致したレコードの顧客ＩＤを取得する（Ｓ７１）。

次にＣＲＭ装置１２１のＣＰＵは、取得した顧客ＩＤと、ＣＲＭ ＤＢ１２４内のサービス決定マスタに格納されている顧客ＩＤを比較して、一致したレコードのコンテンツＩＤを取得する（Ｓ７２）。一致するレコードが複数ある場合は、最も優先順位の高いコンテンツＩＤが取得される。

続いてＣＲＭ装置１２１のＣＰＵは、コンテンツＩＤを取得したかを判断し（Ｓ７３）、取得しなかった場合は（Ｓ７３、なし）、広告提供のための情報取得を行わず、処理を終了する。取得した場合は、取得したコンテンツＩＤと、ＣＲＭ ＤＢ１２４内の商品マスタに格納されているコンテンツＩＤとを比較して、一致したレコードのセール開始日時とセール終了日時とを取得し（Ｓ７４）、現時点の日時と比較して、セール期間中であるかを判断する（Ｓ７５）。

ＣＲＭ装置１２１のＣＰＵは、セール期間内である場合には（Ｓ７５、期間内）、ＣＲＭ ＤＢ１２４内の商品マスタの検索において一致したレコードの在庫数を取得し（Ｓ７６）、商品の在庫が有るか無いかを判断する（Ｓ７７）。

ＣＲＭ装置１２１のＣＰＵは、セール期間中であり（Ｓ７５、期間内）、かつ商品の在庫が有る場合には（Ｓ７７、あり）、ＣＲＭ ＤＢ１２４内の商品マスタに格納されている商品名、値引き前価格、値引き後価格、セール開始日時、セール終了日時等の商品情報、及び店舗ＩＤを取得し（Ｓ７８）、取得した店舗ＩＤと、顧客ＤＢ１２３内の店舗マスタに格納されている店舗ＩＤを比較して、一致したレコードの店舗名等の店舗情報を取得し（Ｓ７９）、処理を終了する。

ＣＲＭ装置１２１のＣＰＵは、セール期間中でない場合（Ｓ７５、期間外）、又は商品の在庫が無い場合には（Ｓ７７、なし）、先述のＳ７２の前に戻り、同一の顧客ＩＤに対して、次に優先順位が高いコンテンツＩＤを検索する（Ｓ７２）。

ＣＲＭ装置１２１のＣＰＵは、優先順位が次に高いコンテンツＩＤを取得できたかを判断し（Ｓ７３）、コンテンツＩＤを取得できた場合（Ｓ７３、あり）、取得したコンテンツＩＤと、ＣＲＭ ＤＢ１２４内の商品マスタに格納されているコンテンツＩＤとを比較して、一致したレコードの情報が、セール期間内（Ｓ７５、期間内）、かつ商品の在庫有り（Ｓ７７、あり）という条件を満たすまで、ＣＲＭ ＤＢ１２４内のサービス決定マスタ、商品マスタを検索する処理を繰り返す（Ｓ７２〜Ｓ７７）。

ＣＲＭ装置１２１のＣＰＵは、ＣＲＭ ＤＢ１２４内のサービス決定マスタの検索（Ｓ７２）の繰り返しにおいて、Ｓ７１で取得した顧客ＩＤと一致した全てのレコードが、セール期間内（Ｓ７５、期間内）、かつ商品の在庫有り（Ｓ７７、あり）という条件を満たさなかったと判断した場合は（Ｓ７３、なし）、広告提供のための情報取得を行わず、処理を終了する。

以上説明した実施例３によれば、店舗２２０で管理するセール情報をＣＲＭ装置１２１に送信し、ＣＲＭ ＤＢ１２４内の商品マスタ、サービス決定マスタに反映したことにより、自動取引装置１１１の利用顧客にリアルタイムかつ訴求効果の高いセール商品の広告を提供することができる。ひいては、サービスが顧客によって十分に活用され、顧客満足度を高くすることができる。また、顧客に広告提供しようとしたセール商品の在庫がない場合でも、代わりに在庫が有る他のセール商品の広告を優先順位に従って提供できるため、顧客への訴求機会を活用することができる。

商品がセール期間中かどうかの判断（Ｓ７５）と、商品の在庫が有るか無いかの判断（Ｓ７７）は、どちらが先であってもよい。

ストア・コントローラ２２１内のＰＬＵファイル２２２、ＣＲＭ ＤＢ１２４内の商品マスタに格納されている値引き前価格、値引き後価格は、値引き対象外の商品については、両方に同じ情報が格納されるものとしたが、片方だけに情報を格納してもよい。その場合は、ＤＢ検索処理のＳ７５の判断は、値引き前価格と値引き後価格の情報に差があるかどうかの判断ではなく、値引き前価格と値引き後価格の片方だけに情報が格納されているという判断になる。

ストア・コントローラ２２１内のＰＬＵファイル２２２、ＣＲＭ ＤＢ１２４内の商品マスタに格納されている価格情報は、上記では値引き前価格と値引き後価格としたが、定価および割引率、定価および値引き額等であってもよい。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記各構成、機能等は、プロセッサがそれぞれの機能を実現するためのプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するためのプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ（登録商標）等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上の制御線や情報線を必ずしも全て示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

Claims (4)

1. 外部から受信した広告情報に基づき取引者に対して広告を提供する自動取引装置と、
   前記自動取引装置による取引がされた時の商品の在庫に応じて、前記広告情報を前記自動取引装置に送信する管理システムと
   を備え、
   前記管理システムは、商品ごとに定められた優先順位に応じて、前記広告情報を前記自動取引装置に送信し、
   前記優先順位は、セール情報に応じて定められていることを特徴とする広告提供システム。
2. 請求項１に記載の広告提供システムであって、
   前記自動取引装置は、取引がされた場合に、取引者に関する情報である取引者情報を前記管理システムに送信し、
   前記管理システムは、
   商品の在庫状況を示す在庫情報をデータベースに格納し、
   顧客情報、店舗情報および前記広告情報を関連付けたデータベース、並びに前記自動取引装置から受信した前記取引者情報に基づき、前記取引者に提供される広告情報を決定し、
   その決定した広告情報に関する商品である対象商品の在庫の有無を、前記在庫情報のデータベースに基づき判定し、
   前記対象商品の在庫がある場合は、その対象商品に関する広告情報を前記自動取引装置に送信する
   ことを特徴とする広告提供システム。
3. 請求項１又は請求項２に記載の広告提供システムであって、
   前記管理システムは、前記自動取引装置の取引者の年齢と性別との少なくとも１つに応じて、前記広告情報を前記自動取引装置に送信する
   ことを特徴とする広告提供システム。
4. 請求項３に記載の広告提供システムであって、
   前記管理システムは、商品の販売実績に応じて、前記広告情報を前記自動取引装置に送信する
   ことを特徴とする広告提供システム。

Images