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

Description

この明細書に記載の実施形態は、店舗で買い物をする顧客向けに、商品の情報を発信する技術に関する。

買い物客が店舗に来店した際、その買い物客の趣向に沿った商品や、後日購入すると思われる商品の広告をシートに印刷し、当該買い物客に提供するシステムがある。

このシステムは、当該買い物客の購入履歴情報に基づき、また製品を通常よりも安く販売するなどの特価情報に基づき、買い物客向けの広告画像を生成する。広告画像は、決められた日時になると、バッチ処理により生成され、買い物客が後日来店した際、当該買い物客からの要求に従って広告画像を印刷する。

上記のように、このシステムは、買い物客が後日来店した際に広告画像を印刷する。買い物客が商品を購入してから、後日来店するまでの期間が長い場合、買い物客の趣向が変わったり、セールス期間が終了したり、該当商品が品切れ／製造中止となったりすることもある。このような状況で過去の広告画像を印刷すると、出力内容が陳腐化して買い物客が所望している広告では無くなる可能性がある。

実施形態は、出力内容が陳腐化せずに新しい広告を維持する技術を提供することを目的とする。

実施形態の広告提供システムは、買い物客に広告画像データを提供する広告システムであって、生成部と、画像形成装置と、データ制御部とを有する。生成部は、買い物客に推薦する商品に関する情報である第１情報を取得し、第１情報に基づき、買い物客に推薦する商品の広告画像データを生成する。画像形成装置は、広告画像データを印刷する。データ制御部は、生成部で生成される広告画像データを１つまたは複数記憶部に蓄積しておき、画像形成装置から広告画像データの印刷指示を受けたときに既に事前に規定されている第１の状態となっている場合、広告画像データを買い物客に提供不可となるようにする。

第１実施形態のシステム構成例を示す図である。 中間サーバの内部構成例を示した図である。 ファイル保存サーバの内部構成例を示した図である。 実施形態で使用するデータの構成例を示す図である。 買い物客が商品を購入した後のデータ構成例を示す図である。 レコメンド情報を取得し、印刷ファイルを生成した後のデータ構成例を示す図である。 第１実施形態の中間サーバの動作例を示すフローチャートである。 第１実施形態のファイル保存サーバのデータ削除時の動作例を示すフローチャートである。 第１実施形態のファイル保存サーバの印刷時の動作例を示すフローチャートである。 第２実施形態のシステム構成例を示す図である。 第２実施形態のファイル保存サーバのデータ削除時の動作例を示すフローチャートである。 第２実施形態の中間サーバの動作例を示すフローチャートである。 第３実施形態のファイル保存サーバのファイル更新時の動作例を示すフローチャートである。 第３実施形態の中間サーバの動作例を示すフローチャートである。 第４実施形態のシステム構成例を示す図である。 第４実施形態の中間サーバの動作例を示すフローチャートである。 第４実施形態の統合在庫管理サーバの動作例を示すフローチャートである。 第４実施形態の統合在庫管理サーバが有する各店舗の在庫リストの例である。 印刷する広告画像データの一例を示す図である。

実施形態のシステムは、広告情報を印刷するための印刷ファイル（以下、広告用の印刷ファイル、印刷ファイル、もしくは単にファイルと称する）を生成するサーバ、および、そのファイルを保存するファイル保存サーバを有する。また実施形態のシステムは、ファイルを生成する際に使用する、推薦商品に関するデータを保存して管理する商品推薦サーバを有する。

実施形態のシステムは、一定期間経過した印刷ファイルを削除する。あるいは、商品の在庫状況に応じて、広告用の印刷ファイルを削除したり、印刷ファイルの一部を更新したりする。尚、印刷ファイルの削除や更新を一定期間としているが、買い物客の購入履歴記録にアクセスし、その買い物客がどの程度の頻度で来店しているかを算出し、その頻度に基づきファイルを保存する期間を設定するような実装でもよい。

以下、各実施形態について説明する。

（第１実施形態）
図１に第１実施形態のシステム構成例を示す。第１実施形態の広告提供システム１００は、商品推薦サーバ１と、ＰＯＳ端末２と、中間サーバ３と、プリンタ４と、商品マスタサーバ５と、ファイル保存サーバ６とを有し、これら各装置がネットワーク９１を介して相互にデータの送受信を行う。

商品推薦サーバ１は、買い物客の来店日時や購入商品一覧を受信、蓄積し、その情報をもとに、お勧めする推薦商品の識別情報などを記録して管理するサーバである。また商品推薦サーバ１は、各サーバからの要求に従い、推薦商品の識別情報などを送信元へ返信する。商品推薦サーバ１は、購入商品の識別情報、および推薦商品の識別情報を、買い物客の識別情報（買い物客ＩＤと称する）に対応付けて記憶している。尚、推薦商品は、既知の技術に従い買い物客の購入履歴、特価情報などに基づき導出される。また購入商品の識別情報や推薦商品の識別情報は、本例では各商品のＪＡＮ（Japanese Article Number）コードとする。商品推薦サーバ１には、上記動作を実行するためのプログラムがストレージに記憶されている。

ＰＯＳ端末２は、買い物客の購入商品を登録し、その商品について決済を行う機能を有する端末である。ＰＯＳ端末２は、買い物客が購入する商品の登録および決済を行い、さらに登録された購入商品の一覧を、中間サーバ３やその他のサーバに送信する。

中間サーバ３は、商品推薦サーバ１とＰＯＳ端末２とにネットワーク９１で接続され、ＰＯＳ端末２から送られてきた購入商品一覧を仲介して、商品推薦サーバ１に送信する。また中間サーバ３は、商品推薦サーバ１から送信された推薦商品の識別情報の一覧を受信し、後述する処理に従い印刷用ファイルを生成し、ファイル保存サーバ６に印刷ファイルを送信する。

ファイル保存サーバ６は、中間サーバ３から広告用の印刷ファイルを受信して、印刷ファイルを蓄積する。ファイル保存サーバ６は、その後、プリンタ４からの要求を受信してプリンタ４に印刷ファイルを送信する。これにより、買い物客は広告シートを得ることができる。またファイル保存サーバ６は、生成されてから一定期間経過しているファイルを削除する機能も有する。

プリンタ４は、ファイル保存サーバ６より印刷ファイルを受信してその印刷を実行する。プリンタ４は、買い物客、店員の操作を受け付けるとともに、操作方法など、買い物客、店員が操作するための案内画面を表示する表示操作部４１を有する。またプリンタ４は、買い物客の会員カードなどを読み取るカードリーダ４２を有する。プリンタ４は、カードリーダ４２で読み取った買い物客ＩＤを、ファイル保存サーバ６に送信し、買い物客ＩＤに紐付けられた広告用の印刷ファイルを受信して印刷する。

プリンタ４は、会員登録を行っていない買い物客に対しても、広告シートを提供することができる。この場合、プリンタ４は、取引ごとに付与される識別情報（取引ＩＤと称する）を、表示操作部４１を介してユーザから取得すると、この取引ＩＤをファイル保存サーバ６に送信する。プリンタ４は、当該取引ＩＤに紐付けられた印刷ファイルを受信して印刷する。尚、取引ＩＤは前回購入時のレシートなどに印字されており、買い物客はこの印字された取引ＩＤを入力する。

商品マスタサーバ５は、その店舗で扱う商品の個々の名称、当該商品を識別する識別情報(ＪＡＮコードなど)、設定価格、当該商品の画像がある場合はその画像データを少なくとも対応付けて記録するデータベースを有する。このデータベースは、図１に示す各サーバそれぞれがネットワーク９１を通して参照可能となる。

図２は、中間サーバ３の内部構成例を示すブロック図である。中間サーバ３は、演算部３１、メモリ３２、ストレージ３３、ネットワーク接続部３４、表示部３５、操作部３６を有する。中間サーバ３は、従前のコンピュータと同様構成である。

演算部３１は、ＣＰＵ（Central Processing Unit）などの演算装置である。演算部３１は、ストレージ３３に記憶されたプログラム３８をメモリ３２に展開し、演算実行する。これにより演算部３１は、各ハードウェアと協働しながら以下に記す機能を提供する。メモリ３２は主記憶装置であり、演算部３１から直接的にデータの受け渡しを行う。ストレージ３３は、プログラム３８や、動作を制御するためのデータなどを不揮発性に記憶する補助記憶装置である。ストレージ３３には、広告提供システム１００が使用するデータを格納するためのレコメンド情報管理領域３９がある。この記憶領域は、例えばフォルダであったり、データベースで管理された領域であったりする。レコメンド情報管理領域３９には、ＰＯＳ端末２から送られてきた取引情報、商品推薦サーバ１から送られてくるレコメンド情報、印刷ファイルの識別情報（ファイル名など）、買い物客ＩＤを対応付けたデータが少なくとも記憶される。

ネットワーク接続部３４は、ネットワークインターフェイスカードを含み、ネットワーク９１を介して外部機器とデータ通信を制御する。操作部３６は、ユーザが使用するキーボード、マウスなどの入力デバイスであり、システム管理者、保守者からの指示を受け付ける。表示部３５は、モニタやディスプレイを含み、システム管理者、保守者に通知すべき情報を表示する。

図３は、ファイル保存サーバ６の内部構成例を示す図である。ファイル保存サーバ６は、演算部６１、メモリ６２、ストレージ６３、ネットワーク接続部６４、表示部６５、操作部６６を有する。ファイル保存サーバ６の内部構成も、図２に示す中間サーバ３の内部構成と同様、従前のコンピュータの構成を有する。図３に示す各ユニットは、図２の中間サーバ３のものと同様であるため、説明を割愛する。

尚、ファイル保存サーバ６のストレージ６３には、ファイル保存領域６９、ファイル期間保存領域６７がある。ファイル保存領域６９は、広告用の印刷ファイルを蓄積して記憶する領域である。またファイル保存領域６９には、広告用の印刷ファイルの作成された日時が、各印刷ファイルと関連付けて記憶される。ファイル期間保存領域６７は、ファイルの保存期間や更新期間の値を記憶する領域である。この保存期間などは、操作部６６を介してシステム管理者などが指定、変更することができる。

その他の商品推薦サーバ１、商品マスタサーバ５も、図２、図３に示す各サーバと同様の構成であるため、図面および説明を省略する。尚、商品推薦サーバ１は、演算部１１、メモリ１２、ストレージ１３、ネットワーク接続部１４、表示部１５、操作部１６を有するものとする。また商品マスタサーバ５は、演算部５１、メモリ５２、ストレージ５３、ネットワーク接続部５４、表示部５５、操作部５６を有するものとする。

図４は、レコメンド情報管理領域３９に記憶されるデータ構成例を示す図であり、図５、図６は、後述する動作に従い、レコメンド情報管理領域３９にどのようにデータが格納されていくのかの遷移を示した図である。

レコメンド情報管理領域３９には、取引を一意に定義づける取引ＩＤ、取引情報、レコメンド情報が対応付けられて記憶される。

取引情報は、取引日時、買い物客を一意に定義する買い物客ＩＤ、受領レコメンドＩＤ、買い物客が購入した１つまたは複数の商品それぞれのＪＡＮコード（ＪＡＮコード一覧）の各データを含む。レコメンド情報は、商品推薦サーバ１が導出した推薦商品のＪＡＮコード一覧、広告用の印刷ファイルの名称（レコメンド印刷ファイル）、当該レコメンド情報を一意に定義する発行レコメンドＩＤの各データを含む。図５、図６については、次のフローチャートの説明の際に参照する。

広告提供システム１００の動作について、図７〜図９のフローチャートに基づき説明する。尚、図７は、中間サーバ３の動作例を示したフローチャートであり、図８、図９は、ファイル保存サーバ６の動作例である。これら各フローチャートは、図２、図３に示す演算部がプログラムを実行することで、各ハードウェアと協働することで実現される。

ＰＯＳ端末２において、ある買い物客の商品登録および決済が行われると、そのとき登録された商品のＪＡＮコードの一覧、および買い物客ＩＤを関連付けた取引情報が生成される。この際、商品登録時に買い物客の会員カードが提示されないなどの理由で、買い物客ＩＤが入力されなかった場合、そこには入力がないことを示す「ｎｕｌｌ」が記録された状態で取引情報が生成される。その後、ＰＯＳ端末２は、生成された取引情報を中間サーバ３に送信する。

中間サーバ３の演算部３１は、取引情報が到達するまで待機する（ＡＣＴ００１−Ｎｏのループ）。取引情報が到達すると（ＡＣＴ００１−Ｙｅｓ）、演算部３１は、ネットワーク接続部３４経由で受信した取引情報に、一意となる取引ＩＤを付与し（ＡＣＴ００２）、自身のレコメンド情報管理領域３９に記録する（ＡＣＴ００３）。このときのデータ状態は、図５の通りである。取引ＩＤはＰＯＳ端末２に送信されて、買い物客に渡すレシートに印字される。尚、ＰＯＳ端末２が取引ＩＤを付与し、レシートに印字するとともに中間サーバ３が取引ＩＤを受信する実装でもよい。

演算部３１は、ネットワーク接続部３４を動作させて、買い物客ＩＤ、購入した商品のＪＡＮコード一覧、取引ＩＤを含んだ取引情報を、商品推薦サーバ１に送信し（ＡＣＴ００４）、その返信を受信するまで待機する（ＡＣＴ００５−Ｎｏのループ）。

商品推薦サーバ１は、受信した取引情報をもとに買い物客ＩＤの客に対して、何を推薦すればよいのかを分析する。商品推薦サーバ１は、その買い物客にお勧めすべき各商品のＪＡＮコード一覧（レコメンド情報一覧）を生成し、中間サーバ３より得られた取引ＩＤをレコメンド情報一覧に付与して、中間サーバ３に送信する。尚、商品推薦サーバ１は、買い物客ＩＤが無い場合でもレコメンド情報一覧を生成し、取引ＩＤとともに中間サーバ３に送信する。

中間サーバ３の演算部３１は、レコメンド情報一覧を受信すると（ＡＣＴ００５−Ｙｅｓ）、レコメンド情報に対して一意となる発行レコメンドＩＤを付与する（ＡＣＴ００６）。中間サーバ３は、これら返信された情報、および発行レコメンドＩＤを、対応する取引ＩＤと関連付けられているレコードに追記する（ＡＣＴ００７）。

演算部３１は、さらにそのレコメンド情報一覧をもとに、たとえばチラシのように推薦商品を配列し、広告用の印刷ファイルを生成する（ＡＣＴ００８）。また演算部３１は、印刷ファイルを識別するためのファイル名を付与し、このファイル名をレコードに追記する。このときのデータ状態は図６の通りである。

ＡＣＴ００８の広告用の印刷ファイルの生成について説明する。演算部３１は、レコメンド情報に含まれるＪＡＮコードそれぞれを、商品マスタサーバ５に送信する。送信するＪＡＮコードの数は、紙面上に配置可能な数を上限とし、１つもしくは複数送信される。演算部３１は、商品マスタサーバ５からＪＡＮコードに対応した商品の名称、設定価格、当該商品の画像がある場合はその画像データを受信する。複数ある場合は各ＪＡＮコードに対応したデータを複数受信する。演算部３１は、事前に定義されるレイアウトデータに基づき、１つの商品についての商品名称、設定価格、商品画像を組み合わせた画像データを作成し、これを商品ごとに作成する。演算部３１は、事前に定義されるレイアウトデータに基づきこれらを結合して、複数の商品情報を配列した印刷ファイルを作成する。

演算部３１は、さらに、発行レコメンドＩＤをスキャン・デコードできる二次元バーコードなどの機械読み取り可能なマークにエンコードする（ＡＣＴ００９）。演算部３１は、ＡＣＴ００８で作成した広告用の印刷ファイルを取得し、機械読み取り可能なマークと合成して、印刷ファイルの上書き保存を実行する（ＡＣＴ０１０）。これにより、買い物客に提供する広告用の印刷ファイルが完成する。ここで生成されたファイルは、少なくとも印刷可能な形式のファイルである。尚、汎用の表示プログラムで表示可能な形式でもよい。

演算部３１は、生成した印刷ファイルを、取引ＩＤ、買い物客ＩＤ、印刷ファイルを生成した日時の各データとともにファイル保存サーバ６に送信する（ＡＣＴ０１１）。ファイル保存サーバ６は、印刷ファイル、取引ＩＤ、買い物客ＩＤを関連付けて、また印刷ファイルが生成された日時データも対応付けて、ファイル保存領域６９に保存する。尚、取引ＩＤ、買い物客ＩＤをファイル名に含めて対応付ける実装でもよい。

次に、図８を参照しつつファイル保存サーバ６のデータ削除時の動作例を説明する。

ファイル保存サーバ６の演算部６１は、前回実行から所定時間（例えば１日）経過するまで待機する（ＡＣＴ１０１−Ｎｏのループ）。ＡＣＴ１０１により、例えば１日１回朝７時に実行する、との制御を行うことができる。尚、上記所定時間や実行時刻などは、システム管理者などが指定することができる。

所定時間経過すると（ＡＣＴ１０１−Ｙｅｓ）、演算部６１は、当該ファイルが生成された（もしくは保存された）日付、時刻の情報と、ファイル期間保存領域６７内で定義される保存期間とを取得し、これらを合算する（ＡＣＴ１０２）。演算部６１は、この合算日時情報が、現在の日時を経過しているか、すなわち現在日時より過去の日時であるかを判定する（ＡＣＴ１０３）。経過している場合（ＡＣＴ１０３−Ｙｅｓ）、演算部６１は当該印刷ファイルを削除する（ＡＣＴ１０４）。経過していない場合、すなわち合算日時情報が現在日時より未来の日時である場合（ＡＣＴ１０３−Ｎｏ）、ＡＣＴ１０４はスキップされて、当該ファイルはそのまま残る。ＡＣＴ１０２〜ＡＣＴ１０４の動作は、ファイル保存領域６９内の全ての印刷ファイルに対して行われる（ＡＣＴ１０５−Ｎｏのループ）。

引き続き、図９を参照してプリンタ４から印刷指示を受けたときのファイル保存サーバ６の動作例を説明する。プリンタ４は、買い物客などによる表示操作部４１を介した操作により、取引ＩＤが入力されると、印刷指示としてその取引ＩＤをファイル保存サーバ６に送信する。尚、買い物客が会員カードをカードリーダ４２にかざし、これにより得られる買い物客ＩＤをプリンタ４が送信してもよい。

ファイル保存サーバ６の演算部６１は、印刷指示が到達するまで待機する（ＡＣＴ２０１−Ｎｏのループ）。印刷指示が到達すると（ＡＣＴ２０１−Ｙｅｓ）、演算部６１は、ファイル保存領域６９内から、受信した取引ＩＤ、もしくは買い物客ＩＤに対応する印刷ファイルを検索し、指定のファイルがあるか否かを判定する（ＡＣＴ２０２）。指定したファイルがある場合（ＡＣＴ２０２−Ｙｅｓ）、演算部６１は、当該ファイルをプリンタ４に送信する（ＡＣＴ２０３）。プリンタ４は、受信したファイルを印刷する。

一方、指定したファイルが無い場合（ＡＣＴ２０２−Ｎｏ）、演算部６１は、該当するファイルが無かったことを示す電文をプリンタ４に送信する（ＡＣＴ２０４）。当該電文を受信したプリンタ４は、ファイルが無い旨を示すメッセージをユーザに表示する。この際、プリンタ４は、単に該当データが無いことを示すメッセージを表示してもよく、データが古いため削除したことを示すメッセージを表示してもよい。

上記例では、一定期間経過した広告用の印刷ファイルを削除する実装例について説明したが、買い物客への広告の提供を不可とする実装例としては、これ以外にもある。例えば、提供不可とする印刷ファイルを、他の記憶領域に退避（移動）させる方法を採用してもよい。また例えば、印刷ファイル名と提供可／提供不可のフラグデータとを対応付けたテーブルをシステム内に持たせる。ファイル保存サーバ６は、陳腐化した広告についてはフラグデータを提供可から不可へ書き替える。プリンタ４から印刷指示がある際には、ファイル保存サーバ６は、このテーブルを参照して提供不可の場合は印刷不可となるように制御する。これらはあくまでも例示であり、これら以外でも様々な手法を用いて、提供／不提供を制御してもよい。

このように、古い広告画像は削除することで、出力内容が陳腐化することを防ぐ。

（第２実施形態）
第２実施形態では、上記の第１実施形態の態様に加え、印刷ファイル内にある推薦商品の在庫の有無を判定し、在庫が無い場合は当該ファイルを削除する実装例について説明する。

図１０は第２実施形態のシステム構成例を示す図である。第２実施形態の広告提供システム１００Ａでは、先の第１実施形態で示した構成に加え、その店舗内の各商品の在庫量を記録する在庫管理サーバ７が含まれる。在庫管理サーバ７の内部構成は、図２、図３に示す構成と同様であり、通常のコンピュータと同様な構成の装置となる。尚、在庫管理サーバ７は、演算部７１、メモリ７２、ストレージ７３、ネットワーク接続部７４、表示部７５、操作部７６を有するものとする。

在庫管理サーバ７は、商品マスタサーバ５と同様に、その店舗で扱う商品の名称と識別情報（ＪＡＮコード）を記録して管理するが、これに加えて、対応する在庫量も記録されている。この在庫量は、１日に１回以上更新される。更新の方法は、本実施形態では在庫管理サーバ７が持つ操作部７６によってその店舗の在庫管理者によって更新されるものとする。尚、ＲＦＩＤ（radio frequency identifier）などの商品個別についている識別情報を、店舗からの入出荷時にチェックすることでリアルタイムに更新する、などの方法でもよい。

第２実施形態の動作について説明する。ＰＯＳ端末２での決済後、その決済による印刷ファイルの生成、保存、および印刷時の動作は第１実施形態と共通動作となる（図７、図９参照）。第２実施形態のファイル保存サーバ６は、取引ＩＤとともに当該取引ＩＤに紐付けられたファイルの削除について、中間サーバ３に問い合わせを行う。ファイル保存サーバ６は、その返信内容に応じて削除する／しないの動作制御を行う。

問い合わせ電文を受信した中間サーバ３は、取引ＩＤに対応付けられた、レコメンド情報内のＪＡＮコードの在庫の有無を、在庫管理サーバ７に問い合わせる。中間サーバ３は、この結果に従いファイルを削除すべきか否かの返信電文をファイル保存サーバ６に送信する。これらの動作について、図１１、図１２を参照しつつ説明する。

図１１は、第２実施形態でのファイル保存サーバ６のデータ削除時の動作例である。ファイル保存サーバ６の演算部６１は、決められた時間ごと、たとえば１日１回朝７時といった決まった時間になったかを判定する（ＡＣＴ３０１）。この動作は図８のＡＣＴ１０１と同様である。所定時間経過後（ＡＣＴ３０１−Ｙｅｓ）、演算部６１は、登録されている１つの取引ＩＤを取得し、削除判定の要求電文とともに、取引ＩＤを中間サーバ３に送信する（ＡＣＴ３０２）。演算部６１は、中間サーバ３から返信電文を受信し、この電文がファイルを削除すべき旨の電文（以下、削除指示電文）であるかを判定する（ＡＣＴ３０３）。削除指示電文である場合（ＡＣＴ３０３−Ｙｅｓ）、演算部６１は、該当する印刷ファイルを削除する（ＡＣＴ３０４）。一方、削除指示電文ではなかった場合（ＡＣＴ３０３−Ｎｏ）、演算部６１は、ＡＣＴ３０４をスキップして当該ファイルを削除しない。演算部６１は、ＡＣＴ３０２〜ＡＣＴ３０４の動作を全ての取引ＩＤ（すなわち全ての印刷ファイル）に対し行う（ＡＣＴ３０５−Ｎｏのループ）。

図１２は、第２実施形態での中間サーバ３の動作例である。中間サーバ３の演算部３１は、削除判定の要求電文をファイル保存サーバ６から受信するまで待機する（ＡＣＴ４０１−Ｎｏのループ）。削除判定の要求電文を受信すると（ＡＣＴ４０１−Ｙｅｓ）、演算部３１は、削除判定の要求電文とともに受信した取引ＩＤで、レコメンド情報管理領域３９を検索する。これにより演算部３１は、その取引ＩＤと関連付けて記録されているレコメンド情報内のＪＡＮコード一覧を抽出する（ＡＣＴ４０２）。演算部３１は、抽出したＪＡＮコード一覧の商品それぞれについて、在庫管理サーバ７に対して在庫の有無を問い合わせ（ＡＣＴ４０３）、返信があるまで待機する（ＡＣＴ４０４−Ｎｏのループ）。

その後、演算部３１は、在庫管理サーバ７から返信電文を受信する（ＡＣＴ４０４−Ｙｅｓ）。ここで受信する返信電文は、商品情報と当該商品の在庫有無の情報とが対応付けられたデータである。演算部３１は、在庫が無い商品が一つでも存在した場合（ＡＣＴ４０５−Ｙｅｓ）、ファイル保存サーバ６に、削除指示電文を送信する（ＡＣＴ４０６）。一方、全ての商品につき在庫がある場合（ＡＣＴ４０５−Ｙｅｓ）、演算部３１は、ファイル保存サーバ６に、削除指示電文以外の電文を送信する（ＡＣＴ４０７）。

第１実施形態と同様に、本例においても、削除以外の態様を適用させてもよい。また、第１実施形態と同様に、フラグデータを用いて広告の提供可／提供不可を制御してもよい。この場合、前回の起動（図１１、図１２に示すフローチャートの起動）で提供不可となった印刷ファイルについて、今回の起動で在庫が復活していた場合、当該印刷ファイルのフラグ値を提供可のものに設定し直してもよい。このようにすることで、在庫の有無に応じて、より細かな情報提供の制御を行うことができる。

第２実施形態により、在庫の有無を考慮した広告をユーザに提供することができる。

（第３実施形態）
第２実施形態では、在庫が無い商品があった場合は印刷ファイルを削除する実装例を説明したが、第３実施形態では、在庫が無い商品があった場合、当該商品についての情報を削除した状態の印刷ファイルを新たに作成する。尚、システム構成については、第２実施形態と同様であるため説明を割愛する（図１０参照）。また、印刷ファイルの生成、保存、印刷ファイルの印刷時の動作は、第１および第２実施形態と同様であるため、説明を割愛する（図７、図９参照）。

第３実施形態のファイル保存サーバ６の動作例を図１３に示す。ＡＣＴ５０１、ＡＣＴ５０２の動作は、第２実施形態のＡＣＴ３０１、ＡＣＴ３０２と同様であるが、中間サーバ３に送信する電文は、削除判定の要求電文ではなく、更新するか否かの判定を要求する電文となる。

ファイル保存サーバ６の演算部６１は、更新する旨の規定電文とともに、更新後の印刷ファイルを受信すると（ＡＣＴ５０３−Ｙｅｓ）、該当する印刷ファイルを、受信したファイルで更新する（ＡＣＴ５０４）。更新しない旨の規定電文を受信すると（ＡＣＴ５０３−Ｎｏ）、ＡＣＴ５０４はスキップされる。ＡＣＴ５０２〜ＡＣＴ５０４につき、全ての印刷ファイルをチェックするまで繰り返すことは、第２実施形態と同様である（ＡＣＴ５０５−Ｎｏのループ）。

第３実施形態の中間サーバ３の動作例を図１４に示す。ＡＣＴ６０１〜ＡＣＴ６０５の動作は、図１２に示す第２実施形態のＡＣＴ４０１〜ＡＣＴ４０５の動作と同様である。尚、ＡＣＴ６０１での受信電文は、更新判定を要求する電文となる。また、全ての商品につき在庫がある場合の動作（ＡＣＴ６０５−Ｎｏの後のＡＣＴ６０７）も、図１２に示すＡＣＴ４０７の動作と同様である。

ＡＣＴ６０５において、在庫が無い商品がある場合（ＡＣＴ６０５−Ｙｅｓ）、中間サーバ３の演算部３１は、印刷ファイルの紙面からそのレコメンド商品を記述した部分を除外する（ＡＣＴ６１０）。演算部３１は、この除外した紙面上の領域に、当該のレコメンド情報一覧で、紙面レイアウトなどの都合で、印刷ファイルの紙面に反映されなかった商品であり、且つ、在庫の存在する商品の情報（画像）を結合する（ＡＣＴ６１１）。これにより、在庫の無い商品は、他の推薦商品に置き替わる。この際、演算部３１は、在庫管理サーバ７への在庫問い合わせ動作（ＡＣＴ６０３）、商品マスタサーバ５への問い合わせ動作（図７のＡＣＴ００８の動作説明参照）を行うことで、商品情報の画像置き換えを行う。

尚、上記の動作は、印刷ファイルを更新、編集する動作であるが、該当商品のデータを除外した状態、または置き換えた状態の印刷ファイルを新たに生成し直す動作でもよい。または、既存の印刷ファイルをファイル保存サーバ６から受信し、当該印刷ファイルに対して編集し直す動作でもよい。

演算部３１は、更新後の印刷ファイルを、ファイル保存サーバ６に返信する（ＡＣＴ６１２）。

第３実施形態により、在庫の有無を考慮し、且つ、広告提供も極力行うことができる。

（第４実施形態）
第３実施形態では、在庫が無い商品があった場合、当該商品についての情報を削除したり、他の推薦商品に置き換えたりすることで、印刷ファイルを新たに作成する実装例を説明した。第４実施形態では、在庫が無い商品があった場合、当該商品についての情報と共に、当該商品の在庫がある他店舗の情報を加えた状態の印刷ファイルを新たに作成する。尚、印刷ファイルの生成、保存、印刷ファイルの印刷時の動作は、第１〜第３実施形態と同様であるため、説明を割愛する（図７、図９参照）。また、印刷ファイルを更新する動作は第３実施形態と同様であるため、説明を割愛する（図１３参照）。

図１５に第４実施形態のシステム構成例を示す。第４実施形態の統合在庫管理システム３００は、統合在庫管理サーバ２００と、それぞれに異なる店舗で実装済みの広告提供システム１００Ａ〜１００Ｅを含む。広告提供システム１００Ａ〜１００Ｅは、先の第２実施形態で示した構成と同じである（図１０参照）。また、図１５に示す広告提供システム１００Ａ〜１００Ｅは、あくまでも例示であり、実際には１又は複数の広告提供システムが統合在庫管理システム３００に含まれてよい。また、統合在庫管理サーバ２００の以下に説明する機能を、図１５に図示する広告提供システム１００Ａ〜１００Ｅのいずれかの在庫管理サーバが提供してもよい。

以下、便宜的に広告提供システム１００Ａを用いて説明する場合があるが、各店舗の広告提供システムも同様の構成で同様の動作を行うことができるものとする。

広告提供システム１００Ａは、図２、図３と同様の内部構成である在庫管理サーバ７を含む。統合在庫管理サーバ２００は、広告提供システム１００Ａの在庫管理サーバ７と、何らかの電気通信回線で接続され、データの送受信を行う。

統合在庫管理サーバ２００の内部構成は、図２、図３に示す各サーバ構成と同様であるため、説明を省略する。尚、統合在庫管理サーバ２００は、演算部２０１、メモリ２０２、ストレージ２０３、ネットワーク接続部２０４、表示部２０５、操作部２０６を有するものとして説明する。

統合在庫管理サーバ２００は、各店舗の広告提供システム１００Ａ〜１００Ｅから送信される、商品の識別情報（ＪＡＮコードなど）、及びこれに対応する在庫量の情報を含むデータをストレージ２０３に記録し、店舗別に商品の在庫量を管理する。尚、ストレージ２０３の在庫情報は、１日に１回以上更新される。更新の方法は、各店舗の広告提供システムの在庫管理サーバと、何らかの電気通信回線を介した通信によって行われる。例えば、第２実施形態のように在庫管理サーバの在庫量が更新される際に、連動してストレージ２０３の在庫情報が更新されてもよい。

統合在庫管理サーバ２００は、各店舗の店舗情報を事前に設定し、ストレージ２０３に記憶する。ここでいう店舗情報は、店舗ＩＤ、店舗名、店舗の住所やＧＰＳ座標などの位置情報、地図の画像ファイル、及びこれらの情報をモバイル端末に表示するための二次元バーコードの画像ファイルを含めた情報である。これらは、サーバ管理者により別途作成されるものとする。尚、広告提供システムが、当該店舗の店舗情報を有し、さらに、他の店舗の店舗情報を記憶する構成であってもよい。このような構成をとることにより、統合在庫管理サーバ２００は、在庫量の情報を含むデータに店舗情報を対応付けて管理することができる。

第４実施形態の中間サーバ３の動作例を図１６に示す。上記の通り、当該中間サーバ３は、広告提供システム１００Ａの中間サーバとする。広告提供システム１００Ａは、１つの店舗（ここでは店舗Ａとする）を対象として機能する。また、店舗Ａには、買い物客などが操作、使用するプリンタ４が設置されている。

ＡＣＴ７０１〜ＡＣＴ７０５の動作は、図１２に示すＡＣＴ４０１〜ＡＣＴ４０５及び図１４に示すＡＣＴ６０１〜ＡＣＴ６０５の動作と同様である。また、全ての商品につき在庫がある場合の動作（ＡＣＴ７０５−Ｎｏの後のＡＣＴ７０７）も、図１２に示すＡＣＴ４０７及び図１４に示すＡＣＴ６０７の動作と同様である。よって、これらの説明を割愛する。

ＡＣＴ７０５において、在庫が無い商品がある場合（ＡＣＴ７０５−Ｙｅｓ）、中間サーバ３の演算部３１は、在庫が無い商品それぞれについて、統合在庫管理サーバ２００に対して、他店舗（店舗Ａ以外の店舗）に在庫があるか否かを問い合わせ（ＡＣＴ７０６）、返信があるまで待機する（ＡＣＴ７１０−Ｎｏのループ）。

その後、演算部３１は、統合在庫管理サーバ２００から返信電文を受信する（ＡＣＴ７１０−Ｙｅｓ）。ここで受信する返信電文は、商品の識別情報（ＪＡＮコードなど）と、当該商品の在庫がある他店舗の店舗情報とが対応付けられたデータである。演算部３１は、印刷ファイルの紙面上の領域に、他店舗に在庫がある商品の情報と共に、店舗情報を組み込み、結合する（ＡＣＴ７１１）。これにより、店舗内に在庫の無い商品がある場合、当該商品の在庫がある他店舗の情報を表示することができる。ただし、他店舗の情報は１店舗に限らず、複数の異なる店舗の情報であってもよい。

尚、いずれの店舗にも当該商品の在庫がない場合、演算部３１は、図１４のＡＣＴ６１０〜ＡＣＴ６１２に示す方法で、当該商品の情報を除外したり、他の推薦商品の情報へ置き換えたりしてもよい。また、店舗Ａ内に在庫がある商品についても、当該商品についての情報に、当該店舗Ａの店舗情報を加えて表示してもよい。

演算部３１は、更新後の印刷ファイルを、ファイル保存サーバ６に返信する（ＡＣＴ７１２）。

統合在庫管理サーバ２００は、ＡＣＴ７０６の問い合わせにより、他店舗の在庫情報を検索し、在庫のある他店舗について、当該店舗Ａから近い順で店舗情報を抽出する。その後、最も近い店舗の店舗情報を当該商品の情報に対応付けて返信する。あるいは、印刷ファイルの紙面上の領域に収まるように、近い順から複数の店舗情報を対応付けて返信してもよい。この動作について、図１７、図１８を参照して説明する。

統合在庫管理サーバ２００の動作例を図１７に示す。ＡＣＴ８０１において、演算部２０１は、問い合わせの電文を中間サーバ３から受信するまで待機する（ＡＣＴ８０１−Ｎｏのループ）。問い合わせの電文を受信すると（ＡＣＴ８０１−Ｙｅｓ）、演算部２０１は、当該商品について、他店舗の在庫情報をストレージ２０３から検索し（ＡＣＴ８０２）、在庫があるか否かを確認する（ＡＣＴ８０３）。演算部２０１は、他店舗に在庫がある場合（ＡＣＴ８０３−Ｙｅｓ）、当該店舗Ａに近い他店舗の店舗情報を、商品の情報に対応付け（ＡＣＴ８０４）、中間サーバ３に返信する（ＡＣＴ８０５）。

尚、ＡＣＴ８０４において、演算部２０１が店舗情報に含まれる位置情報を用いて店舗間の距離を比較して決められる。これにより、各店舗について、店舗に近い他店舗の順を決めることができる。また、前記店舗の近い順は、統合在庫管理サーバ２００で店舗ごとに事前に設定してもよい。

一方、他店舗に在庫がない場合（ＡＣＴ８０３−Ｎｏ）、演算部２０１は、他店舗に在庫がない旨を返信する（ＡＣＴ８０６）。

図１８は、ＡＣＴ８０３の動作により形成される在庫リストである。図１８の各店舗の在庫リスト８５０は、統合在庫管理サーバ２００内で構成される。

各店舗の在庫リスト８５０は、店舗欄８６０と、商品欄８７０を含む。店舗欄８６０の項目には、各店舗の識別情報が格納され、本例では前述した方法により、当該店舗からの近い順に例えば３店舗分抽出される。本例では、店舗Ａに近い順に店舗Ｂ〜Ｄが抽出されるものとする。店舗欄８６０の識別情報は、それぞれ店舗情報が紐付けられている。商品欄８７０の項目には、店舗で取り扱っている商品（本例では商品Ａ〜Ｃ）が格納され、それぞれに商品情報（ＪＡＮコードなど）が紐付けられている。

尚、在庫リスト８５０に格納された数字は、在庫数を示す。例えば、店舗Ｃにおける商品Ｂの在庫数は５８であり、また、店舗Ｂには商品Ｂの在庫が無いことを示している。

在庫リスト８５０において、例えば商品Ａの在庫がある最も近い店舗の店舗情報を抽出したい場合、店舗Ｂの店舗情報が抽出される。また、商品Ｂの在庫がある最も近い店舗の店舗情報を抽出したい場合、店舗Ｂには在庫がないため、演算部２０１は、店舗Ｂの次に近い店舗Ｃに在庫があることを確認して、店舗Ｃの店舗情報を抽出する。以上の要領により、ＡＣＴ８０４では、在庫がある店舗の中から、店舗Ａから近い順に店舗情報を抽出して商品情報に対応付ける。

尚、本例では当該店舗から近い店舗順に店舗情報を抽出したが、在庫数が多い店舗順に店舗情報を抽出してもよい。例えば、商品Ｃの在庫がある店舗のうち、最も商品Ｃの在庫が多い店舗の店舗情報を抽出したい場合、店舗Ｄの方が店舗Ｂよりも在庫が多いため、店舗Ｄの店舗情報を抽出し、商品情報に対応付ける。これにより、買い物客を在庫過多となっている店舗に案内し、当該店舗での在庫量の削減を図ることを期待することができる。

上記では、近い店舗をまずは抽出し、その抽出結果のリストから在庫の有無をさらに抽出する実装としているが、まずは該当商品の在庫のある店舗を抽出し、その後に近い順となるように店舗をソートする実装でも構わない。

抽出される店舗情報の数は複数であってもよい。例えば商品Ａの在庫がある店舗のうち近い順に２つの店舗の店舗情報を抽出したい場合、店舗Ｂ及び店舗Ｃの店舗情報を抽出する。

第４実施形態により、店舗内に在庫のない商品について、他店舗の在庫の有無を考慮し、広告提供を極力行うことができる。

ここで、実施形態により生成される印刷ファイルの一例を図１９に示す。図１９は、第１〜４の実施形態で作成される広告の表示例であり、具体的には、図１９は、ＡＣＴ００８などで作成される広告用の印刷ファイルである。尚、広告のレイアウトデータは事前に定義されるものとし、適宜、表示される商品の数の変更、表示情報の配置変更、表示情報の追加及び削除等が行われてもよい。

図１９の広告９００が含む各項目について説明する。広告９００は、発行レコメンドＩＤ、発行レコメンドＩＤをスキャン・デコードできる二次元バーコード（図１９の発行レコメンドＩＤの右側）を含む。発行レコメンドＩＤは、ＡＣＴ００６にてレコメンド情報に付与されるＩＤであり、広告９００に表示される商品の一覧と紐付けられている。また、上記二次元バーコードは、ＡＣＴ００９で形成される、機械読み取り可能なマークである。機械や端末等がこれを読み取ることにより、印刷ファイルを取得したり、広告９００内の各情報にアクセスしたりすることが可能となる。

広告９００は、商品名、価格、商品画像を含む。これらの商品情報は、ＡＣＴ００８で中間サーバ３が商品マスタサーバ５から受信する情報である。尚、図１９に示すように、広告９００は、商品に関する説明文を含める構成でもよい。

広告９００は、商品情報に対応する、当該商品の在庫がある店舗情報を含む。また、この店舗情報は、第４実施形態で説明したように、店舗名、店舗の住所やＧＰＳ座標などの位置情報、地図の画像ファイル、及びこれらの情報をモバイル端末に表示するための二次元バーコードの画像ファイルを含む情報である。広告９００は、必要に応じてこれらの情報のうち一部のみを表示／非表示にしてもよい。例えば本例では、店舗ＩＤを表示していないが、店舗ＩＤを表示してもよい。

以降、印刷ファイルが広告９００のデータを有するものとして各実施形態を説明する。

第１実施形態は、保存期間の経過後、印刷ファイルを削除する実装である。すなわち、広告９００の全体が削除される。このようにして第１実施形態では、古い広告データを削除する。

第２実施形態は、広告９００に示す商品のうち１つでも在庫が無い商品が存在した場合に、印刷ファイルを削除する実装である。すなわち、広告９００の全体が削除される。このようにして第２実施形態では、在庫の有無考慮した広告を提供する。

第３実施形態は、広告９００に示す商品のうち在庫が無い商品が存在した場合に、その商品を記述した部分を除外し、代わりに在庫の存在する他の商品の情報を結合した印刷ファイルを作成する実装である。すなわち、広告９００のうち在庫のない商品についてのみ、別の推薦商品に情報が置き換わる実装である。このようにして第３実施形態では、在庫の有無を考慮しつつ広告提供も極力行う。

第４実施形態は、広告９００に示す商品のうち店舗内に在庫がない商品が存在する場合、その商品の在庫が存在する店舗の情報を商品の情報に添えた印刷ファイルを作成する実装である。すなわち、広告９００のうち店舗内に在庫のない商品の情報を維持し、その商品の在庫がある店舗の情報を結合する実装である。このようにして第４実施形態では、店舗内のみならず他店舗の在庫の有無も考慮し、広告提供を極力行うことができる。

尚、図１９では全ての商品について店舗情報を表示したが、第４実施形態で説明したように店舗内に在庫がない商品のみについて店舗情報を表示してよい。あるいは、店舗内に在庫がある商品についても、店舗情報を表示してもよい。

上記各実施形態では、シート上に広告情報を出力し、この広告シートを買い物客に提供するものとして説明したが、広告用の画像データで買い物客に提供してもよい。この場合、規定の近距離無線通信や、ＬＡＮ、インターネットを介して、買い物客が所持している携帯用端末に送信してもよい。また事前登録してあるＥメールアドレスやＳＮＳ（social networking service）を介して、広告用の画像データを送信してもよい。

上記実施形態の態様を、それぞれ組み合わせてもよい。第１実施形態と第２実施形態とを組み合わせる態様では、一定期間経過した印刷ファイルを削除するとともに、現在在庫の無い推薦商品を含む印刷ファイルも削除する。第１実施形態と第３実施形態とを組み合わせる態様では、一定期間経過した印刷ファイルを削除するとともに、現在在庫の無い推薦商品を含む印刷ファイルについては、差し替える。第２実施形態と第３実施形態とを組み合わせる態様では、例えばモードにより動作を切り替える、などが考えられる。第１、第２、第３実施形態の態様を全て組み合わせてもよい。

また、上記実施形態では、複数のサーバを構成に含んだ広告提供システムについて説明したが、態様はこれに限定されない。１台のコンピュータもしくは複数のコンピュータで広告提供システムが構成されていてもよい。また上記で説明した各機能とサーバとの対応関係も、上記実施形態の態様に限定されない。

第１情報は、商品推薦サーバ１から送信されるレコメンド情報一覧（推薦商品のＪＡＮコードの一覧）でもよく、商品マスタサーバ５から送信される、ＪＡＮコードに対応した商品の名称、設定価格、当該商品の画像のいずれか、もしくは全てでもよい。生成部は中間サーバ３に相当し、データ制御部はファイル保存サーバ６に相当する。データ置換部は、中間サーバ３およびファイル保存サーバ６の組み合わせに相当する。

また第１システムは、広告提供システムに相当する。また、商品に関する在庫情報を、複数の店舗ごとに記憶するサーバとして、上記では、在庫管理サーバの一つの形態として、統合在庫管理サーバ２００を例示した。

第１実施形態において、事前に定義される第１の状態は、記憶部に広告画像データが削除された状態に相当し、データ制御部が一定期間経過した広告画像データを記憶部から削除することでこの状態となる。またデータ制御部は、広告画像データを買い物客に提供不可となるようにするため、記憶部に記憶された広告画像データを削除する。画像形成装置（プリンタ４）から広告画像データの印刷指示を受けたときには、既にこの削除状態となっている。

第２実施形態において、事前に定義される第１の状態は、買い物客に推薦する商品の在庫が店舗内に無くなった状態に相当する。画像形成装置から広告画像データの印刷指示を受けたときには、既にこの在庫が無くなった状態となっている。またデータ制御部は、買い物客に推薦する商品の在庫が店舗内に無い場合、広告画像データを買い物客に提供不可となるようにするため、記憶部に記憶された広告画像データを削除する。

以上に詳説したように、実施形態の構成により、広告内容が陳腐化することを抑制することができる。

本実施形態では装置内部に発明を実施する機能が予め記録されている場合で説明をしたが、これに限らず同様の機能をネットワークから装置にダウンロードしても良いし、同様の機能を記録媒体に記憶させたものを装置にインストールしてもよい。記録媒体としては、ＣＤ−ＲＯＭ等プログラムを記憶でき、かつ装置が読み取り可能な記録媒体であれば、その形態は何れの形態であっても良い。またこのように予めインストールやダウンロードにより得る機能は装置内部のＯＳ（オペレーティング・システム）等と協働してその機能を実現させるものであってもよい。

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

１００、１００Ａ〜Ｅ 広告提供システム、２００ 統合在庫管理サーバ、
１ 商品推薦サーバ、２ ＰＯＳ端末、３ 中間サーバ、４ プリンタ、
５ 商品マスタサーバ、６ ファイル保存サーバ、７ 在庫管理サーバ。

Claims (1)

1. 商品に関する在庫情報を、複数の店舗ごとに記憶する在庫管理サーバと、
   第１店舗における買い物客に広告画像データを提供する第１システムであって、
   買い物客に推薦する商品の識別情報を取得し、前記識別情報に基づき、前記買い物客に推薦する商品の広告画像データを生成する生成部と、
   前記第１店舗にあり、前記買い物客の操作により前記買い物客に対する広告画像データを印刷する画像形成装置と、
   前記生成部で生成される広告画像データを１つまたは複数記憶部に蓄積しておき、前記買い物客に推薦する商品の在庫が、前記画像形成装置が設置される前記第１店舗内に無い場合、前記在庫管理サーバに記憶される在庫情報に基づき、前記買い物客に推薦する商品の在庫がある前記第１店舗と異なる第２店舗に関する情報を、前記広告画像データに組み入れて新たな広告画像データを作成するデータ制御部と、
   を有する第１システムと、
   を含む広告提供システム。
   

Images