JP2013109502A - Ｐｏｓインターフェース（ｉｆ）エミュレータ - Google Patents

Abstract

【課題】
（ＰＯＳ ＩＦ）
商品タグから取得される商品情報は、その店舗のストアシステムから来るため、精算はその店のＰＯＳシステムで行う必要がある。そのためには、小売店舗が従来のＰＯＳシステムに何ら変更を加えることなく、モバイル・ショッピング・システムを接続できることが望ましい。
【解決手段】
（ＰＯＳ ＩＦ）
小売店舗が、この精算を受け付けるために、ストアシステムの変更を望まない場合（通常はシステムのインテグレーションが発生し改修費用が発生する）は、機能に制限はあるが、買物・精算システムが、直接店舗のＰＯＳシステムのキーボードやディスプレーのＨＷインターフェースを利用して、エミュレーション入力を行い、精算を完了する事も出来る。
【選択図】 図２

Description

本発明は、携帯電話やスマートフォンのような携帯デバイスが、購入する商品に対応する商品タグのバーコードやＩＣチップをスキャンして商品情報の取得を繰り返し、買物情報を作成して、買物・精算システムに買物情報を送信して精算を完了するモバイル・ショッピング・システムの方法、プログラム及びシステム並びに

店舗のＰＯＳシステムに変更を加えることなく、モバイル・ショッピング・システムを既存のＰＯＳシステムに接続して精算する方法、プログラム及びシステム、

顧客に自身の携帯電話やスマートフォンで商品タグを積極的にスキャンしてもらうための機能を提供する方法、プログラム及びシステム、

顧客が、将来購入の可能性がある商品をブックマークし、後日購入を決定した時に、ブックマークした時と同じ条件で購入できる機能を提供する方法、プログラム及びシステム、

顧客が自身の携帯電話やスマートフォンで商品タグをスキャンすることで得られる情報量を増やすことで、顧客が積極的に商品タグをスキャンすることを促すとともに、店舗にとっても商品際での販売促進情報の効果的・効率的な提供を可能とするために、２次元バーコードやＩＣチップには情報量の制限を越えて多くの追加情報を提供する方法、プログラム及びシステム、

に関する。

従来の小売業界は実店舗とＥＣ（E-Commerce）サイトに大きく二分され、その発展の過程から同じ企業にあってもそれぞれが完全に別のシステムで運営されている場合が一般的である。

実店舗では伝統的に販売・在庫・発注管理にＰＯＳ(Pointof Sales)システムが使われており、商品の精算は、顧客が選んだ買い物カゴ中の商品のバーコードを、精算レジで、バーコードリーダを使って、ひとつひとつスキャンすることを基本とするため、同じチェーン店でも各店舗で価格が異なる場合も多い。

一方、インターネットの普及とともに急速に発展してきたＥＣサイトは、通常そのチェーン店にひとつしかなく、店舗や在庫を持たないため、一般的に実店舗よりも安い価格で同じ商品が販売されている。

そのため、顧客が、実店舗で実際に手に触れて確かめて購入を決めた商品をＥＣサイトで精算したり、ＥＣサイトで購入した商品を実店舗で受取ったりするようなサービスの実現は現状のままでは難しい。

ＥＣサイトでは、全ての買物行動がコンピュータ上で行われるため顧客の購買行動は簡単に把握可能で、どの商品を見てどの順番で購入したか、商品を見たが買わなかった等を簡単に分析することができ、購買行動分析をベースとした積極的なマーケティングやプロモーションを行なうＥＣサイトも多い。

しかし、売上げの大多数を占める実店舗では、レジでの精算時にスキャンされた商品とそのスキャンをした順番の情報が残るだけで、顧客がどの商品をどのように購入したのかを調べる術はないため、ＥＣサイトのように顧客の購買行動の分析をするには十分なデータが取れず、有効なマーケティングやプロモーションを行うことが出来ていない。

そのため、ちらし広告や一律のバーゲンのような、店舗にとって効果の上がらない不必要な値引きや、顧客にとってうんざりするような過剰な情報の提供になりがちであり、顧客に十分に浸透できない。 プロモーションの対象顧客絞込みと、プロモーション情報のタイムリーな配布が重要である。

近年のスマートフォンに代表されるモバイルシステムの活用で、実店舗、ＥＣサイトのシステムを統合し、顧客の欲しいものを届けたり、マーケティングやプロモーションを行ったりする、マルチチャネルやオムニチャネルの仕組みも検討され始めている。

モバイルシステムの活用の一例としては、ヨーロッパ系の大手スーパーのCarrefourやAuchan、Delhaizeなどや米国の大手スーパーのStop & Shopなどは、店内にＷｉＦｉ無線ＬＡＮを導入し、専用の無線携帯デバイスを顧客に貸し出し、商品のバーコードを顧客自身に携帯デバイスでスキャンしてもらい、携帯デバイスを店舗のＰＯＳシステムと通信させて精算するセルフスキャンを広く導入・展開している。

一方、米国ボストンのベンチャーのAisleBuyerは顧客の持つスマートフォンを利用したセルフスキャンのソリューションを展開している

また、英国系大手スーパーのTesco（あるいは、韓国においてはＨｏｍｅＰｌｕｓ）は、韓国の地下鉄のホームや地下街に商品イメージにバーコードを付けたポスターを貼り、顧客がスマートフォンのバーコードリーダでこれを読んでＥＣサイトで商品購入すると商品が宅配されるバーチャルストアのパイロットを行っている。（非特許文献２および３）また、中国ではこれに類するパイロットを行おうとしている。（非特許文献４）

これらスマートフォンのソリューションでは、各店舗が独自の買物アプリを作成し、顧客はこれをスマートフォンにダウンロードして、商品についている１次元バーコードか、棚札に表示されている２次元バーコード（ＥＣサイトのＵＲＬや商品バーコード情報を含む）を読み取り、携帯電話網やＷｉＦｉ無線ＬＡＮを経由して、その店舗のＰＯＳシステムやＥＣサイトのサーバに接続し、バーコードに対応する商品情報をリアルタイムに検索・取得して買物を行うものである。

米国系大手スーパーのKrogerは、自社の店舗でスマートフォンを利用したモバイル・ショッピングのトライアルを行っているが、スマートフォンのカメラでの１次元バーコードの低い読取速度や読取率（一般に、１次元バーコードはエラー訂正機能を持たず、カメラでの読み取りには向いていない）、店内全域で途切れる事無くＷｉＦｉ無線ＬＡＮを利用することの難しさ、スマートフォンで店舗のＰＯＳシステムに接続するための複雑な手順、顧客に商品や価格情報を開放してしまうリスク等を課題として指摘している（非特許文献１）。
また、携帯電話網を利用して通信する場合は、利用できるエリアとその通信コストも問題となる。

このような問題を解決する方法として、特許文献１では電子棚札（ＥＳＬ）からコンテンツを取得していく買物支援が提案されている。

これは、実店舗が表示価格と精算価格のくいちがいを避けるために導入をすすめている電子棚札システムを利用したもので、ＰＯＳが参照するストアシステムの商品情報データベースを共有して商品の価格を表示する電子棚札に、商品情報の２次元バーコード（ＱＲコード）を表示し、携帯電話やスマートフォンでこれを読み取ることでモバイル・ショッピングを可能にするもので、非特許文献１においてKrogerの指摘する課題を解決するものである。

Tescoの例のようなバーチャル店舗や、サンプルだけが置かれたショールーム店舗だけでなく、実店舗でも実際に商品に触れて確かめながら買物ができるとともに、従来ＰＯＳシステムでは取れなかった実店舗での顧客の購買行動の把握や、実店舗とＥＣサイトのデータを統合した新たなマーケティングやプロモーションが可能となるものである。

これにより、店舗内で、顧客に、商品の追加情報や関連プロモーションを、買物の文脈にそって顧客ごとにパーソナライズして提供するとともに、それぞれの提供情報に対する顧客の関心度を測定することも出来る。

また、電子棚札のコンテンツの中には店舗情報を持つため、ひとつの買物アプリでどこの店舗でも買物をすることも可能となる。

しかし、実店舗での精算はＰＯＳシステムで行われるため、これを実現するためには実店舗とＥＣサイトでシステムを共通化したり、ＰＯＳシステムへのインテグレーションをしたりする必要があり、小売業にとって導入への敷居は低いものではない。

(特許文献1) （日本国）特許 第4620807号電子棚札(ESL)からコンテンツを取得していくセルフ買物支援

(非特許文献1)Krogger、"Technological hurdles found by Brett Bonner, senior director atKroger ",http://supermarketnews.com/technology/kroger_mobile_0613/ (非特許文献2)TESCO OPENS WORLD'S FIRST VIRTUAL STOREhttp://www.tescoplc.com/news/news-releases/2011/tesco-opens-world's-first-virtual-store/,http://www.youtube.com/watch? v=nJVoYsBym88 (非特許文献3)Homeplus Smart Virtual Store ? Shop withYour Phone While Commuting (video)http://www.technobuffalo.com/companies/samsung/homeplus-smart-virtual-store-shop-with-your-phone-while-commuting-video/http://www.youtube.com/watch?v=3W3KkYgsFs0 (非特許文献4)http://www.youtube.com/watch?v=GaIpb6Cpd1M

（共通）
Krogerが非特許文献１において指摘するような、小売店舗でのモバイル・ショッピング・システムの課題を解決するためには、ＩＢＭ（IBM Corporationの商標）が特許文献１で提案するような、携帯電話やスマートフォンのような携帯デバイスが、購入する商品に対応する商品タグの２次元バーコードやＩＣチップをローカルで（外部サーバとの通信なしで）スキャンして、商品情報の取得を繰り返し、買物情報を作成して、精算時にのみ携帯電話網を利用して精算システムに買物情報を送信することは有効な手段である。

２次元バーコードやＩＣチップをローカルでスキャンすることで１次元バーコードの低い読取速度や読取率の課題、ＷｉＦｉ無線ＬＡＮの課題、店舗のＰＯＳシステムに接続する手順の課題、顧客に商品や価格情報を開放する課題が解決できる。

また、精算時の携帯電話網の利用は、ＷｉＦｉ無線ＬＡＮの課題や店舗のＰＯＳシステムに接続する手順の課題を解決するものである。

小売店舗がこのようなモバイル・ショッピング・システムを導入する場合、

（ＰＯＳ ＩＦ）
商品タグから取得される商品情報は、その店舗のストアシステムから来るため、精算はその店のＰＯＳシステムで行う必要がある。

そのためには、小売店舗が、従来のＰＯＳシステムに何ら変更を加えることなく、モバイル・ショッピング・システムを従来のＰＯＳシステムに接続できることが望ましい。

（懸賞）
また、顧客に自身の携帯電話やスマートフォンで商品タグを積極的にスキャンしてもらう必要があるため、顧客にスキャンするメリットを感じさせる何らかの新しい機能の提供が必要である。

顧客がこのシステムを利用すると、メーカや小売店舗の懸賞が自動的に当たるようにしてモバイル・ショッピング・システムの利用を促進することが望ましい。

（ブックマーク）
また、このシステムは実店舗で利用されるため、ＥＣサイトのように何時でも好きな時に商品を購入できるわけではない。

そのため、顧客が将来購入の可能性がある商品をブックマークし、後日購入を決定した時に、ブックマークした時と同じ条件での購入できることが望ましい。

例えば、顧客が海外旅行等に出かけた場合、多くの店が入っている大規模なショッピング・モールでは、気になった商品を売っていた店の場所が分からなくなってしまったり、スケジュールの都合でその店に戻ることが出来なくなってしまったりする場合が多々あり、そのような場合でも事前にブックマークしておくことでその商品の購入が可能となる。

（追加情報）
また、顧客は商品についての詳細情報やパーソナライズされた情報を取得し、よく商品を吟味して買いたいと考えているが、２次元バーコードやＩＣチップには情報量に制限があるため、何らかの方法でより多くの追加情報を提供する必要がある。

例えば、ある商品に注目している顧客に、おすすめの別の関連商品(クロスセル、アップセル)やバリエーション情報（色やサイズのちがいの品揃え）やボリューム割引・組み合わせ割引などのプロモーション・キャンペーン情報を、その着目している商品の特性と顧客の特性を考慮して、絞り込みかつパーソナライズして提供して、顧客の満足度向上と売り上げ増を実現することが望ましい。簡単なところでは、商品の色やサイズのバリエーションの数だけ商品タグを用意することを避けることが望ましい（３色、４サイズの衣料品では１２個の商品タグが必要となるが、これを２つにする）。

（共通）
顧客が小売店舗でこのモバイル・ショッピング・システムを利用して買物をする場合、顧客の所持する携帯電話やスマートフォンのような携帯デバイスに、予め買物アプリをダウンロードしておく。

これは店頭に表示された２次元バーコードやＩＣタグをスキャンして指定されたダウンロードサイトからダウンロードできる。この時各種情報登録（利用者情報、精算口座、宅配住所等）も行われる。

この買物アプリがスキャンする商品タグには店舗の情報も含まれるため、買物アプリを一度ダウンロードすると、システムの構成次第では、他の小売店舗でも利用することも可能となる。

買物を行うには、携帯デバイスが、購入する商品に対応する商品タグのバーコードやＩＣチップをローカルでスキャンして価格を含む商品情報を取得する。この情報はこの店舗のストアシステムが生成したものであるため、精算はこの店舗のストアシステム(ＰＯＳシステムを含む）で行う必要がある。

携帯デバイスは、商品情報の取得を繰り返して一連の買物を行い、顧客の買物アプリ操作情報（すなわち顧客の買物行動、あるいは、顧客の購買行動）を含む買物情報を作成して、３ＧやＧＳＭの携帯電話網とインターネット経由して買物・精算システムに送信する。

買物・精算システムはこの買物情報を保存するとともに、店舗での精算に必要な精算情報を作成してストアシステムに送信して精算を終了し、携帯デバイスに精算結果を返す。

（ＰＯＳ ＩＦ）
小売店舗が、この精算を受け付けるために、ストアシステムの変更を望まない場合（通常はシステムのインテグレーションが発生し改修費用が発生する）は、機能に制限はあるが、買物・精算システムが、直接店舗のＰＯＳシステムのキーボードやディスプレーのＨＷインターフェースを利用して、エミュレーション入力を行い、精算を完了する事も出来る。

（懸賞）
顧客にこのシステムを積極的に利用してもらう為に、買物・精算システムが、ある商品が買物情報にあることを条件として、予め登録されたメーカや小売店舗の懸賞データを精算情報に適用して精算を完了し、携帯デバイスに通知する事も可能である。

（ブックマーク）
実店舗では、一度商品の購入の機会を逃してしまうと、再度その店を訪れて商品を購入する必要があるが、このシステムでは、携帯デバイスが、ブックマークとして、将来購入する可能性のある商品の買物情報を作成することで、このブックマークを呼び出して、店舗を訪れる事無く、後日、買物情報の作成時の条件で精算をする事も可能である。

（追加情報）
このシステムでは、商品タグは商品に対応しているため、商品に色やサイズのバリエーション情報がある場合、それぞれの商品に商品タグをつける必要がある。携帯デバイスが、買物情報の作成時に商品の色やサイズのバリエーション情報等の追加情報を追加情報タグより取得し買物情報に反映することで、商品タグ数を減らすことも出来る。

また、このシステムでは、商品タグに、関連する商品情報（プロモーションやキャンペーン等）に対応するコードを追加情報として含ませることで、携帯デバイスが、商品情報の取得時に、関連する商品情報をもあわせて取得し、顧客に提示できる。ある商品群に対応する商品タグに、共通のキャンペーンコードを含ませることにより、共通のキャンペーン（冬物一掃セール）の対象とすることができる。また、キャンペーンコードの意味を、顧客により20％引き、30％引き、40％引きなどとパーソナライズすることもできる。さらに、関連商品の提案・組み合わせ販売などさまざまなキャンペーンやプロモーションを実現できる。

本発明を用いることによって、以下の効果を期待することが出来る。

（共通）
小売店舗は、Krogerが指摘するような、顧客の携帯デバイスを使ったモバイル・ショッピング・システムの技術的課題を解くことが出来、容易にモバイル・ショッピング・システムを店舗に導入出来る。

小売店舗は、顧客に自身の携帯デバイスを用いた新しい買物体験を提供して顧客満足度を向上できるだけでなく、顧客の購買行動や動向をベースとした新しいプロモーションやマーケティングが可能となる。

電子棚札メーカは、紙棚札の置き換えとしての電子棚札に、モバイル・ショッピング機能を持たせることが出来、コスト削減（値段変更に伴う紙棚札の交換、紙棚札表示価格とＰＯＳ価格との不一致によるトラブル防止など）の提案から新たに収益（買物分析、キャンペーン・プロモーションなど）を産むビジネスの提案が可能となり、より積極的なビジネス展開が可能になる。

電子棚札メーカ、あるいは、電子棚札を活用するサービス提供会社は、小売店舗に電子棚札と買物アプリを無料で提供する代わりに、買物・精算管理システムの運営を行い、小売業界全ての店舗の買物情報を集めて、商品メーカやマーケティング会社に提供して収益を得たり、自らプロモーションやマーケティングを行ったりすることも可能となる。

買物・精算管理システムをクラウド化することも可能である。

（ＰＯＳ ＩＦ）
電子棚札メーカ、あるいは、電子棚札活用サービス提供会社は、小売店舗の現行のストアシステム（ＰＯＳシステムを含む）に影響を与えることなくモバイル・ショッピングの精算を可能にする方法が提案でき、システムインテグレーションの必要性から、モバイル・ショッピングの導入に消極的な小売店舗の導入意欲を向上させることが出来る。

電子棚札メーカ、あるいは、電子棚札活用サービス提供会社は、この方法を電子棚札コントローラに搭載することで、ほとんど追加のコストをかけることなく、電子棚札システムにモバイル・ショッピング機能を追加することが出来る。途中に印刷プロセスは入るが、紙棚札を使ったモバイル・ショッピングにも対応可能である。

（懸賞）
自身の携帯デバイスを使って買物をするだけで、顧客は懸賞が当たる権利を獲得出来るため積極的にこのシステムを利用するようになる。
また、メーカや小売はこの懸賞を打つことで、その製品の購入を促進するとともに、購買行動情報を入手して新製品の開発や価格設定に利用することが出来る。

小売店舗は、アフィリエートモデル（後述）を懸賞のひとつとして提供することで、店頭で商品のバーコードをスキャンしてより安いＥＣサイトから商品の購入を可能にするソフトウェアを利用している顧客に対して、同様のサービスをより簡単に提供できる。このことにより、店舗は直接販売して利益を得るだけでなく、直接販売しないでも、他店舗に顧客を紹介して（その店舗が販売したことによる）手数料による利益を得ることもできるようになる。

（ブックマーク）
顧客は自身の携帯デバイスで、通常の買物に加えて、気に入った商品をブックマークして、いつでも好きな時にブックマークした時の条件で商品を購入することが可能となる。
また、小売店舗は、買い忘れたり買い損ねたりして後悔しているなど、従来失っていた顧客に対しても新たなビジネスチャンスを得ることができ、特に海外ツアー等で訪れる顧客への新しいサービス（観光客が、観光地などで購入を迷った商品をブックマークしておき、帰国までの間に決断して購入すれば、出国する空港や宿泊しているホテルに届けて、観光土産がととのうようなサービスを提供する旅行ツアー会社向けのサービスなど）を提供することが可能となる。

（追加情報）
小売店舗内で、顧客に、商品の追加情報や関連プロモーションを、買物の文脈にそって顧客にパーソナライズして提供することが可能となり、さらに、それぞれの提供情報に対する顧客の関心度の測定が可能になる。顧客にとってタイムリーで有効な情報となるだけでなく、小売店にとっても顧客に対する効果的なone-to-oneマーケティングが可能となる。

ある商品に注目している顧客に、おすすめの別の関連商品(クロスセル、アップセル)やバリエーション情報（色やサイズのちがいの品揃え）やボリューム割引・組み合わせ割引などの情報を、その着目している商品の特性と顧客の特性を考慮して、絞り込みかつパーソナライズして提供することが出来、顧客の満足度向上と売り上げ増を実現できる。このことにより、一律に定期的に送信するような顧客がうんざりしてしまい読んでもらえないような非効果的な宣伝メールとは異なり、配信の対象顧客と配信のタイミングとを最適化して、効果的な宣伝ができるようになる。また、街頭や新聞折い込みで配布する一律の割り引きちらし広告など多くの顧客には読んでもらえない一方、キャンペーン効果の見込めないような人にまで割引販売をしてしまうような広告とは異なり、配布ターゲットしぼり、割引内容をパーソナライズ化するなどにより、効果の期待できるキャンペーンを実施できるようになる。」

ちらし広告や一律のバーゲンのような、小売店舗にとって効果の上がらない不必要な値引や、顧客がうんざりするような過剰な情報提供を止め、情報のフィルタリングとタイムリーな配布が実現できる。また、小売店にとって、さまざま、クロスセルやアップセルを行うツールとして活用できる。

本発明が適用され連係するモバイル・ショッピング・システムの構成（図１）する機器の接続イメージ図である（図１） 本発明が適用され連係するモバイル・ショッピング・システム全体の各機能のブロック・ダイアグラム(図２）を示す(図２） POS IFエミュレータを用いたモバイル・ショッピング・システムで機能するブロックをハッチングしたもの(図３）である(図３） 懸賞処理システムを適用した場合のモバイル・ショッピング・システムで機能するブロックをハッチングしたもの(図４）である(図４） ブックマークシステムを適用した場合のモバイル・ショッピング・システムで機能するブロックをハッチングしたもの(図５）である(図５） 商品バリエーション管理システムを適用した場合のモバイル・ショッピング・システムで機能するブロックをハッチングしたもの(図６）である(図６） キャンペーン情報システムを適用した場合のモバイル・ショッピング・システムで機能するブロックをハッチングしたもの(図７）である(図７） 商品タグから取得される商品情報の例である（図８） 携帯電話が商品タグから商品情報を取得し作成した買物情報の例である（図９） 携帯電話が精算時に買物・精算管理システムに送信する買物情報の例である（図１０） 携帯電話がブックマークから作成した買物情報の例である（図１１） 携帯電話がブックマーク精算時に買物・精算管理システムに送信する買物情報の例である（図１２） 買物情報データベースが持つ買物情報の例である（図１３） 買物・精算管理システムがストアシステム又はPOSIFエミュレータに送信する精算情報の例である（図１４） 順序・組合せ懸賞に当選した買物情報の例である（図１５） 順序・組合せ懸賞データの例である（図１６） 数量限定懸賞に当選した買物情報の例である（図１７） 数量限定懸賞データの例である（図１８） ランダム懸賞に当選した買物情報の例である（図１９） ランダム懸賞データの例である（図２０） キーボード入力用データの例である（図２１) 追加情報データベースの情報の例である（図２２）。 商品バリエーション情報管理データベースの情報の例である（図２３） キャンペーン情報管理データベースの情報の例である（図２４） 商品タグコントローラの動作例を示すフローチャートである（図２５） 携帯電話の動作例を示すフローチャートである（図２６） 買物・精算管理システムの動作例を示すフローチャートである（図２７） POS IFエミュレータの動作例を示すフローチャートである（図２８） ブックマークシステムの動作例を示すフローチャートである（図２９） 懸賞処理システムの動作例を示すフローチャートである（図３０） 懸賞処理システムの懸賞当選処理の動作例を示すフローチャートである（図３１） 携帯電話の追加情報DB更新の動作例を示すフローチャートである（図３２） キャンペーン管理システムが携帯電話の追加情報DBを更新する動作例を示すフローチャートである（図３３） 商品バリエーションシステムの動作例を示すフローチャートである（図３４） キャンペーン情報システムシステムの動作例を示すフローチャートである（図３５） Mobile Shopping Assistantの概要と操作のイメージである（図３６） ＰＯＳ機器情報の例である（図３７）

（共通）
図 １は、本発明が適用され連係するモバイル・ショッピング・システム全体（複数のデータ処理システム）を構成する機器の接続イメージ図である。電子棚札と呼ばれるＥＳＬ１２０（Ｅｌｅｃｔｒｏｎｉｃ Ｓｈｅｌｆ Ｌａｂｅｌ）や紙棚札１４０等を含む商品タグ１００、携帯電話やスマートフォンを含むモバイルデバイス３００、インターネット１０、買物・精算管理システム５００、ＰＯＳ７１０を含むストアシステム７５０を基本の構成として、機能の追加に応じて、さらに、ＰＯＳ ＩＦエミュレータ１２００、拡張買物管理システム１４００（例えば、懸賞システム１６００、ブックマークシステム１８００、バリエーション管理システム２０００、キャンペーン情報システム２２００など）から構成される。

モバイルデバイス３００は、以下の実施例においては、代表的な実施形態である携帯電話３００について説明するが、携帯電話のみに限定するものではない。すでに欧米諸国のセルフスキャン買物で用いられているような専用の買物デバイスでもよい。

商品タグ１００は、以下の実施例においては、代表的な実施形態であるＥＳＬ１２０または紙棚札１４０について説明するが、これらに限定するものではない。

ここで商品タグ１００は、商品に直接貼り付けられるラベル、糸などを用いて商品に直接添付される小型の紙のタグ(商品札、値札)など、あるいは、商品棚やショーウィンドゥに商品に対応付けられて設置される棚札やデジタルサイネージなどを指す。

ここで、商品タグ１００とは、さらに、通信販売用などの商品カタログやレストランのメニューなどに、商品に対応付けられた又は関連付けられた商品情報（商品名や価格に添えられた２次元バーコードや紙にすきこまれたＩＣチップなど）を指す。

ここで商品タグ１００は、ラベルや棚札が通常の表示している商品名や価格などの基本的な商品情報に加えて、より多くの情報量をコード情報として含んでいる。
そのため、買物客によって、モバイルデバイス３００が、商品タグ１００をスキャンする（あるいは、商品タグ１００にかざされる）ことで、モバイルデバイス３００は、商品タグ１００が提供するコード情報を容易に取得できる。

ここで商品タグ１００が商品情報として取得するコード情報は、2次元バーコード読み取り、
NFC通信、Bluetooth通信などによって、デジタル化されて情報として、商品タグ１００からモバイルデバイス３００が取得する。

以下の実施例においては、ほとんどの場合、商品タグ１００は、代表的な実施形態である
2次元バーコード表示可能なＥＳＬ１２０について説明するが、2次元バーコード表示可能なＥＳＬ１２０のみに限定するものではない。

また、携帯電話３００には買物アプリケーション（以降、買物アプリ）が導入されており、これらの殆どの機能は、かかるソフトウェアをインストールするだけで、既にあるハードウエアを生かして実現することができ、機能を実現するための手段にもなり得る。

図 ２は、これらの各機能をブロック・ダイアグラムとしてあらわしたものである。

商品タグ１００は、ストアシステム７５０から商品情報７６０を取得して格納し、表示、印刷などの方法で、商品情報を提供するものである。携帯電話３００は、商品タグ１００から、２次元バーコード（ＱＲコードやＤａｔａＭｅｔｒｉｃｓ）やＮＦＣ（Ｎｅａｒ Ｆｅｉｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）技術やＢｌｕｅｔｏｏｔｈ技術を利用して商品情報７６０を取得する。

携帯電話３００は、取得した商品情報７６０に、購入日時４３８、数量４４０、金額（小計）４４１、ブックマーク日時４４２（後述）、（内容の）有効条件４４３等の買物行動情報を追加し、買物情報４３０Ａを作成する。この情報には、この他に顧客の買物行動を分析するために必要な携帯電話３００の操作情報等を含めても構わない。

携帯電話３００は、この動作を繰り返して買物を行い、精算時に精算日時４３９を追加して買物情報４３０Ｂを作成し、買物・精算管理システム５００へ転送する。
具体的には、携帯電話３００は３ＧやＧＳＭの携帯電話網を利用してインターネット１０に接続して買物・精算管理システム５００へ買物情報４３０Ｂを送信する。

これらの携帯電話網は、新興国でも急速に普及しており、通信エリアもＷｉＦｉ無線ＬＡＮに比べて広く、盗聴、改竄等のセキュリティーのレベルも高い。携帯電話網を抜けてインターネットで通信される場合は情報に暗号化技術を用いることが望ましい。

買物・精算管理システム５００の買物情報取得機能５２０は、通信機能５１０を経由して携帯電話３００からの買物情報４３０Ｂを取得する。精算情報抽出機能５３０は買物情報４３０Ｂの利用者ＩＤ４３１に対応する精算登録情報５８６を利用者登録情報データベース９００から取得して、買物情報４３０Ｂから抽出した精算情報（５８１〜５８５）と組合せ精算情報５８０を作成し、通信機能５５０がストアシステム７００へ直接、または、ＰＯＳ ＩＦ（インタフェース）エミュレータ１２００とＰＯＳ７１０を経由して精算情報５８０を送信し精算処理を行う。

ここで、図 １４の精算情報５８０の例では、利用者ＩＤ５８１が同じものは、同一の精算処理を意味しており、この例の場合では、利用者ＩＤ５８１が０３５０６３である最初の３つ、０６００８７である次の３つ、２７７４４３１である次の３つ、０３５０６３である最後の２つがそれにあたり、４つの精算処理が連続して買物・精算管理システム５００に送られていることを意味する。

精算結果は、買物・精算管理システムの通信機能５５０を介し精算確認機能５４０で確認されたあと、精算処理要求を出した携帯電話３００に送られる。携帯電話３００は画面に精算結果を表示して買物を終了する。

商品タグ管理システム２００では、電子棚札コントローラ２２０が、ストアシステム７００の商品情報データベース７６０より商品情報を取得して、店舗内で販売するそれぞれの商品について、商品タグ１００を作成する。ここで商品情報データベース７６０から取得する商品情報とは、図８に示すように、メーカ７６１、商品名７６２、商品コード７６３、価格７６４、追加情報７６５、店舗７６６、有効条件７６７などを含む。

対応する商品の商品タグ１００がＥＳＬ１２０である場合は、電子棚札コントローラは、ＩＲまたは電波などの無線通信の手段によって、ＥＳＬ１２０の情報を適宜変更する。

対応商品の商品タグ１００が紙棚札１４０である場合は、電子棚札コントローラは、対応する商品の商品情報を、紙棚札印刷２４０に送信し、紙棚札印刷２４０は、商品情報を紙棚札１４０に印刷する。紙棚札１４０に印刷する際には、商品名７６２や価格７６４などの通常の表示に加えて、商品情報データベース７６０から取得したより詳細な商品情報（７６１〜７６７）を2次元バーコードのようなコード情報として印刷をする。

図 ２５は商品タグ管理システム２００の動作例を示すフローチャートである。商品タグ管理システム２００は、ステップ２５４でストアシステム７００の商品情報データベース７６０の変更を検出すると、ステップ２５６で変更された商品の商品情報７６０を取得し、ステップ２５８で商品タグ情報作成し、ステップ２６０でこれらからＱＲコードを作成して、ステップ２６２で電子棚札（ＥＳＬ１２０）、あるいは、紙棚札印刷２４０に送信する。他の商品に変更があった場合は同様の処理を繰り返す。

図 ２６は、携帯電話３００の動作例を示すフローチャートである。携帯電話３００の買物アプリは、各種機能をサポートするため、ステップ３５４で機能選択が行われ、買物機能が選ばれるとステップ３５６で通常の買物か、ブックマークされた商品の買物かが選択される。

ステップ３５６で通常の買物の場合は、ステップ３５８で買物画面が表示され、商品タグ１００をスキャンして商品情報７６０を取得する。ステップ３６０で通常の購入なのか、それとも後日商品の購入を考えるブックマークなのかを判断する。ステップ３６０で通常の購入の場合は、ステップ３６４で買物情報４３０Ａを作成する。ステップ３６０でブックマークの場合にはステップ３６２で買物情報４３０Ａの行４４９の情報（ブックマークに関する買物情報）を保存し、ステップ３６４で買物情報４３０Ａを作成する。引き続き、ステップ３６６で精算が選択されると、ステップ３６８で買物情報４３０Ａに精算日時４３９を追加して買物情報４３０Ｂを作成し、買物・精算管理システム５００に送信して、ステップ３７０でその精算結果を買物・精算管理システム５００より取得して表示する。
ステップ３５６でブックマーク購入が選択されると、ステップ３８０で以前に買物時にステップ３６２で保存した買物情報４３０Ａの行４４９を読出し、
ステップ３８２で購入日時４３８、数量４４０、金額４４１を埋めて買物情報４３０Ｃを作成し、ステップ３６８で精算日時４３９を追加し４３０Ｄを作成して、上記の通常の購入と同様の処理を行う。

図 ２７は、買物・精算管理システム５００の動作例を示すフローチャートである。買物・精算管理システム５００は、携帯電話３００から精算要求を受けると、ステップ６５４で買物情報４３０Ｂ、４３０Ｄを取得し、ステップ６５６で買物情報４３０Ｂ、４３０Ｄより抽出した利用者ＩＤ４３１を利用して、利用者登録情報９００から、この携帯電話３００を持つ顧客（利用者）の登録情報を取得する。この情報には精算情報５８０に含める精算登録情報５８６（クレジットカード番号や現金決済、精算口座番号等）が含まれる。ここで、精算登録情報５８６は、この顧客（利用者）が、モバイル・ショッピング・システムの利用をはじめる時に、このシステムで取得される購買行動・動向等の個人情報の利用許諾とともに、店舗のＰＣや携帯電話で利用者登録情報９００に登録したものである。

懸賞やブックマーク、キャンペーン、商品バリエーション等の追加機能（後述）がある場合は、それぞれ次のステップ１７５０、ステップ１９５０、ステップ２０５０、ステップ２２５０において、対応するシステムが処理を行う。

ステップ６６０で買物情報４３０Ｂ、４３０Ｄから精算に必要な利用者ＩＤ４３１、商品コード４３４、価格４３５、数量４４０、を抽出し、ステップ６５６で取得した精算登録情報５８６を追加して精算情報５８０を作成し、ストアシステム７００へ送信する。ＰＯＳ ＩＦエミュレータ１２００を経由する場合はステップ１３５０でＰＯＳ精算処理（後述）を行ってから、ストアシステム７００へ送信する。
ステップ６６４で精算確認を行い、ステップ６６６で携帯電話３００へ通知を行って一連の精算処理を終了する。

（ＰＯＳ ＩＦエミュレータ）
図 ３はＰＯＳ ＩＦエミュレータ１２００を用いたモバイル・ショッピング・システムで機能するブロックをハッチングしたものである。精算がＰＯＳ ＩＦエミュレータ１２００を経由して行われる場合、通信機能１２１０で受信した精算情報５８０を、精算データ加工検証機能１２２０が、ＰＯＳ機器情報データベース３２００に保存された、キーボード／スキャナーインターフェース情報、ＰＯＳアプリケーションの操作順序、等に従って加工してキーボード入力用データ１３１０を作成し、ＰＯＳ精算データ入力機能１２３０でＰＯＳの入力操作をエミュレーションして、キーボード・インターフェース１２６０から、作成したキーボード入力用データ１３１０をＰＯＳ７１０に入力する。

図 ３７はＰＯＳ機器情報３２００に保存されている情報の例である。ここには各種ＰＯＳのキーボード・インターフェース（通常スキャナーはキーボード・インターフェースに接続される）の種類やデータ入力間隔の最低条件、キーボードバッファの数（何文字まで連続して送れるか）等の入力に必要な情報や、カスタマーディスプレーインターフェース（通常はＲＳ２３２等が使われる）の出力情報の通信パラメータ等、ＰＯＳアプリケーションの操作順序等の情報が保存されており、通信する相手のＰＯＳに対応する情報がＰＯＳＩＦ エミュレータから読み取られて利用される。

ＰＯＳ７１０には、入力用データ１３１０が、ＫＢＤ ＩＦ（キーボード・インタフェース）（７３０）から通常のレジでの商品精算と同様に入力される。ＰＯＳ ＩＦエミュレータ１２００の精算データ加工検証機能１２２０は、データが入力されるたび、ＰＯＳ７１０のカスタマー・ディスプレー（精算されている商品名や価格の確認のため顧客側に向いた小型表示装置）のインターフェースのＤＩＳＰ ＩＦ（ディスプレイ・インタフェース）７４０からの出力をＰＯＳ機器情報データベース３２００のカスタマー・ディスプレー・インターフェース情報に従って取得する。

図 ２１は、精算データ加工検証機能１２２０が、精算情報５８０から、ＰＯＳ機器情報３２００に保存された、ＰＯＳアプリケーションの操作順序に従って加工したキーボード入力用データ１３１０の例である。

入力の対象となるＰＯＳの通常操作は以下のように行われる。はじめにＨＯＭＥキーが押され、レジ担当のＩＤカードのバーコードをスキャンする（９９９９９に相当）、スキャナーはデータを送った後にＥＮＴＥＲキーを自動的に挿入するため次にＥＮＴＥＲキーが入る。次に顧客カードのバーコード（０３５０６３に相当）をスキャンしＥＮＴＥＲキーが入る。ここから商品のバーコードのスキャンが行なわれる。

最初の商品は、数量が２なのでまず２キー(通常は１キーがデフォルトで入っているものを上書きする)が押され、次に商品のバーコード（４９０８２２００７８０２３に相当）をスキャンし、ＥＮＴＥＲキーが入る。次の商品は数量が１なので（デフォルトのまま）商品のバーコード（４９０２７２００７８０５０に相当）をスキャンし、ＥＮＴＥＲキーが入る。次の商品は数量が１なので（デフォルトのまま）商品のバーコード（４９００４１１０４５６３０に相当）をスキャンし、ＥＮＴＥＲキーが入る。

小計を出すためにＦ１キーが押され、次に預かり金６１６８が入力される。クレジット精算のため顧客カードで登録されているクレジットｘｘｘｘｘｘｘｘが選ばれ、Ｆ１が押され精算を終了する。この順序に従い入力用データ１３１０は加工される。

ＰＯＳ ＩＦエミュレータ１２００の精算データ加工検証機能１２２０は、ディスプレイ・データモニター１２７０経由で取得したＰＯＳ７１０が出力したディスプレイ出力と、ＰＯＳ７１０に入力した精算情報５８０の価格５８３、および、数量５８４とを比較し、これらが一致しなかった場合には、ＰＯＳ精算データ入力機能１２３０でＰＯＳの操作をエミュレーションして、キーボード・インターフェース１２６０から、取り消し操作（具体的には取り消しキー）をＰＯＳ７１０に入力する。

これらが一致しなかった場合であっても、ＰＯＳ７１０に入力した精算情報５８０の価格５８３の方が安い場合にのみ、取り消し操作をＰＯＳ７１０に入力しても良い。

また、これらが一致しなかった場合には、ストアシステム７００にその情報を通知しても良い。

これまでは、買物・精算管理システム５００とＰＯＳ ＩＦエミュレータ１２００がそれぞれ別の機器として店舗に持ち、通信により機能することを想定していたが、ＰＯＳ ＩＦエミュレータ１２００に買物・精算管理システム５００の機能を包含するＰＯＳ ＩＦエミュレータ・システム６０を構築することもできる。

また、ＰＯＳ ＩＦ エミュレータ１２００の機能またはＰＯＳ ＩＦエミュレータ・システム６０を、商品タグ管理システム２００に統合することも出来る。

ＰＯＳ ＩＦ エミュレータ１２００が店舗情報４３７に対応することで（具体的には店舗情報をＩＤとして持つ）、買物情報４３０Ｂに含まれる店舗情報４３７を利用して、買物・精算管理システム５００が、店舗ごとの精算情報５８０を抽出して、このＰＯＳ ＩＦ エミュレータ１２００を介してそれぞれの店舗のＰＯＳ７１０において精算することも可能である。

ここまでは、買物・精算管理システム５００とＰＯＳ ＩＦエミュレータ１２００が同一店舗にあることを想定していたが、例えば大手スーパーのように、多くの店舗を持つ小売では、買物・精算管理システム５００をそれぞれで持つことは合理的ではなく、買物情報データベース１４３０を有効に分析するにあたっても、統合することが望ましい。
この場合、店舗情報４３７をＩＤとして持つＰＯＳ ＩＦ エミュレータ１２００を複数利用することによって、買物・精算管理システム５００が買物情報４３０Ｂに含まれている店舗情報４３７を使って、店舗ごとの精算情報５８０を抽出し、対応する複数の店舗のそれぞれのＰＯＳにおいて精算できるようにすることが可能となる。

この他に、ショッピング・モールのように、多くの小売が同一の商業施設に入っている店舗運営システムに買物・精算管理システム５００を導入し、それぞれの小売店舗に、このＰＯＳ ＩＦ エミュレータ１２００を適用すると、ショッピング・モールのどこの店舗でも、ひとつの買物アプリで買物が出来、精算はそれぞれの店舗のＰＯＳにおいて自動的に精算できるサービスを提供することが出来る。

図 ２１はキーボード入力用のデータの例である。
通常のＰＯＳシステムにおいては、買物精算時に、ＰＯＳオペレータが、顧客が買物かごにいれた商品を順番にスキャンしたり、キーボードを操作して、買物登録や精算を行うことで生成する、入力キーデータに対応している。

図 ２８は、ＰＯＳ ＩＦエミュレータ１２００の動作例を示すフローチャートである。この機能は図２７の買物・精算管理システムの動作例を示すフローチャートのステップ１３５０ＰＯＳ精算処理で呼び出される。ステップ１３５４でＰＯＳ ＩＦエミュレータ経由の精算が選ばれると、ステップ１３５６で買物・精算管理システム５００を経由しＰＯＳ機器情報３２００に登録されている、ＰＯＳ ＩＦエミュレータ１２００が接続されているＰＯＳ７１０のキーボード／スキャナーインターフェース情報、ＰＯＳアプリケーションの操作順序、等を読み出し、ステップ１３５８でこれに従って精算情報５８０を加工して、図２１に示すようなキーボード入力用データ１３１０を作成する。ステップ１３６０でキーボード入力用データ１３１０を一行ずつ、ＰＯＳ精算データとして入力し、ステップ１３６２でそれに対応するＰＯＳからの出力を、ステップ１３６４で比較検証し、一致しない場合はステップ１３６６でエラー処理を行う。一致する場合はステップ１３６０に戻って次のデータを入力し、全てのデータの入力を終えると、ステップ１３７０で買物・精算管理システム５００に精算終了を送信し処理を終了する。
（ブックマーク）

ブックマーク購入の例としては、例えば大型ショッピングモールでの利用が考えられる。 顧客はまず携帯電話３００の買物アプリを立上げてウインドショッピングしながら各店舗で購入したい商品タグ１００のＱＲコードをスキャンする。買うか迷うものはとりあえずブックマークしておく。買物を終えて精算すると、買物情報４３０Ｂは各店舗の精算システム（ストアシステム７００）に送られて処理される。料金は予め登録（利用者登録ＤＢ９００）したクレジットカードにチャージされ、商品はモール入り口の商品受取カウンターか、裏のドライブスルーでまとめて受取ることが出来る。指定すれば予め登録（利用者登録ＤＢ９００）した住所に宅配もされる。

顧客は、ショッピングモールでの買物を終えたが、やはり気になった商品を買いたくなったが、その店舗はモールの反対側にあり１０分以上歩かなければならない。そこで、顧客は、携帯電話３００の買物アプリを立上げブックマーク機能を呼び出すと、その商品の情報が表示され個数を指定して購入ボタンを押すことで、買物情報４３０Ｄが、その店舗の精算システム（ストアシステム７００）に送られて処理される。しばらくして、受取カウンターでその商品も受取って帰る。

１週間後、この顧客は、もうひとつ気になっていた商品を買いたくなる。だが、ショッピングモールは１００Ｋｍ離れておりすぐには行けない。顧客は、携帯電話３００の買物アプリを立上げブックマーク機能を呼び出すとその商品の情報が表示され、数量を入れて、宅配を指示し、購入ボタンを押とその店舗の精算システム（ストアシステム７００）に買物情報４３０Ｄが送られて処理され、商品は翌日宅配されて来た。一緒に入っていたチラシを見ると通常値段に上がっていたがブックマークした時の値段で購入が出来た。

２週間後、この顧客は、もうひとつ同じ商品を買いたくなり、ブックマーク機能を使うと、何故かブックマークした値段よりも安く購入することができた。翌日、もうひとつ買おうとしたら、有効期限切れの表示が出て買えなかった。

このように追加機能としてブックマーク機能を提供する場合、ブックマークシステム１８００が拡張買物処理システム１４００のひとつとして追加される。図５はブックマークシステムを適用した場合のモバイル・ショッピング・システムで機能するブロックをハッチングしたものである。

ブックマーク機能は、買い物中に商品をブックマークして保存する機能と、この保存されたブックマークを呼び出して購入する二つの機能を持つ。

取得した商品情報７６０を表示する携帯電話３００の画面には図 ３６のように、通常の購入の操作を指示するボタン２０３６に加えて、ブックマーク操作を指示するボタン２０３８が表示される。

携帯電話３００が商品タグ１００から商品情報７６０を取得して、このブックマーク操作を選択すると、買物情報４３０Ａの行４４９が作成され保存される。
一般にブックマークは通常の買物の中で行なわれるため、携帯電話３００の中での精算前の買物情報は買物情報４３０Ａのように、通常の買物とブックマークが混在する。
精算時に携帯電話３００は、作成した買物情報４３０Ａの精算日時４３９にそのときの時刻情報を記録した買物情報４３０Ｂを買物・精算管理システム５００に送信する。

買物・精算管理システム５００の買物情報取得機能５２０は、受信した買物情報４３０Ｂをブックマークシステム１８００の買物情報管理機能１４１０に渡し、買物情報管理機能１４１０はブックマーク情報４４９を抽出し、買物情報データベース１４８０に保存する。

ブックマークした商品を購入する場合は、携帯電話３００は、保存されているブックマーク情報４４９（買物情報４３０Ａの行４４９）を読み出して、購入日時４３８、数量４４０、金額４４１のデータを追加した買物情報４３０Ｃを作成する。携帯電話３００は、精算処理を開始すると、精算日時４３９に時刻を追加した買物情報４３０Ｄを買物・精算管理システム５００に送信する。

精算管理システム５００は、ブックマークシステム１８００の買物情報管理機能１４１０に、買物情報４３０Ｄを渡し、買物情報データベース１４８０に保存されているブックマーク情報４４９を読み出して、読み出したブックマーク情報４４９が有効であるかを検証する。

ブックマーク情報４４９には、何時まで有効であるとか、何個まで購入できる、何回まで購入できるといった有効条件があるため、ここで検証がおこなわれる。
検証できない商品は、ブックマークシステム１８００の買物情報管理機能１４１０が、買物情報４３０Ｄのうちから削除する。有効条件から外れた買物は精算結果とともに後ほど携帯電話３００に通知される。

ここで検証できずに買物情報４３０Ｄから削除した場合は、精算結果を携帯電話３００に送る時に、キャンペーン管理システム４２２０から取得した代替のキャンペーンやプロモーションに関する情報を追加して送り、携帯電話３００は画面に精算結果を表示する時に、代替のキャンペーンやプロモーションを合わせて表示することもできる。

買物・精算管理システム５００の買物情報取得機能５２０は、買物情報管理機能１４１０から買物情報４３０Ｄを受取り、精算情報抽出機能５３０で精算情報５８８を作成して、通信機能５５０を経由してストアシステム７００に送信する。

ストアシステム７００は、商品情報履歴データベース７６０を有していて、精算情報５８０のブックマーク日時（５８５）に一致する商品情報に基づいて精算を行う。
精算結果は買物・精算管理システム５００を経由して携帯電話３００に戻されて一連の動作が終了する。

ここでは、ストアシステム７００は、商品情報履歴データベース７６０を持つことを前提としているが、ブックマーク機能を第三者がサービスとして提供する場合、ブックマークされた価格と現状の価格の差額をこの第三者が負担又は取得し、店舗が商品情報履歴データベース７６０を持たないオプションも考えられる。例えば、ブックマーク価格より精算価格が高い場合は第三者がその差分を負担し、安い場合はその差分を取得するわけである。この第三者は顧客のブックマーク情報をベースにマーケティングやプロモーションを行なって利益をあげるため、このようリスクをとることも可能である。

ブックマーク情報４９９には、携帯電話３００が商品タグ１００から商品情報７６０を取得してブックマークした時点での価格４３５とブックマーク日時４４２が保存されるため、後からでもブックマークした時の価格で商品を購入することが可能となる。

また、商品情報７６０には、有効条件７６７が含まれており、この情報はブックマーク情報４４９の有効条件４４３にコピーして保存されているため、ブックマーク購入に制限をかけることも可能である。

精算管理システム５００は、ブックマーク購入に制限に引っかかり、検証できなかった商品を見つけた場合に、キュンペーン管理システム４２００に照会して、携帯電話３００に適用可能なキャンペーン情報を取得し、携帯電話３００に送信することもできる。

例えばこのキャンペーン情報が、割引クーポンや代替商品であっても良い。

例えば大手スーパーのように、多くの店舗を持つ小売では、買物・精算管理システム５００とブックマークシステム１８００をそれぞれの店舗で持つことは合理的ではなく統合することが望ましい。買物・精算管理システム５００は、買物情報４３０に含まれる店舗情報４３７を使って、店舗ごとの精算情報５８０を抽出できるため、買物・精算管理システム５００とブックマークシステム１８００をクラウド化して、対応する複数の店舗においてブックマーク精算できるようにすることもできる。

この他に、ショッピング・モールのように、多くの小売が同一の商業施設に入っている店舗運営システムに買物・精算管理システム５００とブックマークシステム１８００を導入し、ショッピング・モールのどこの店舗でも、ブックマーク精算できるサービスを提供することが出来る。このことにより、購入を迷った商品、他店舗との比較検討の結果で再び買いたくなった商品などを、その店舗に訪れた時にブックマークしておけば、店舗に再度戻らずにブックマーク購入の手段で購入できるため、特に、米国などでみられるような広大な敷地に展開される巨大ショッピングモールなどでは、顧客に利便性の高いサービスを提供できる。

図２９はブックマークシステム１８００の動作例を示すフローチャートである。
図 ２７の買物・精算管理システム５００のフローチャートのステップ１９５０でブックマーク処理が呼ばれると、ステップ１９５４で買物・精算管理システム５００から取得した買物情報４３０Ｂから、ステップ１９５６、および、ステップ１９５８で、ブックマーク情報４４９を抽出し、処理すべき買物情報４３０Ｂの買物情報が、ブックマーク処理かブックマーク購入か通常購入であるかを判断する。
ステップ１９５６でブックマーク処理であった場合は、ステップ１９６２で買物情報データベース１４８０に保存し、ステップ１９６６でさらに処理すべき商品が存在すれば次の商品について、ステップ１９５４以下の処理を繰り返す。

ステップ１９５８でブックマークした商品の購入の場合は、取得した買物情報４３０Ｄと、買物情報データベース１４８０に保存されているブックマーク情報４４９を読出し検証する。１９６４で検証できなかった商品は削除して新たな買物情報４３０Ｄを作成し、１９６６で次の商品の処理に進む。

ステップ１９５８で通常の購入の場合は、買物情報４３０Ｄはそのままで、ステップ１９６６で次の商品の処理に進む

全ての商品の処理が終わったところで、買物・精算管理システム５００に買物情報４３０Ｄを渡して一連の処理を終了する。

(懸賞)
追加機能として懸賞機能を提供する場合、拡張買物処理システム１４００のひとつとして懸賞処理システム１６００が追加される。図４は懸賞システムを適用した場合のモバイル・ショッピング・システムで機能するブロックをハッチングしたものである。

携帯電話３００が商品タグ１００から商品情報７６０を取得して、購入を選択すると、買物情報４３０Ａが作成され、一連の買物が終了して精算処理を行うと、買物情報４３０Ｂが作成され買物・精算管理システム５００に送られる。

買物・精算管理システム５００の買物情報取得機能５２０は、受信した買物情報４３０Ｂを懸賞システム１６００の買物情報管理機能１４１０に渡し、買物情報管理機能１４１０は買物情報データベース１４３０を更新する。
懸賞システム１６００の検索・処理機能１４２０は、取得した精算中の買物情報４３０Ｂの中に、メーカ２０や小売３０により、通信機能１４７０を経由して懸賞情報データベース１４６０に予め登録されてある懸賞対象の商品があるかを検索する。

懸賞対象商品がある場合は、懸賞データが示す条件（図 １６の１６２０、図 １８の１６４０、図 ２０の１６６０など）が、買物情報４３０Ｂのうちの、その利用者ＩＤの買物情報１６１０と合致した場合、その懸賞データの懸賞処理をおこなう。一連の懸賞の処理が終わると、携帯電話３００および買物・精算管理システム５００に対して懸賞当選の通知を行なうとともに、買物・精算管理システム５００に当選した懸賞の割引を反映した買物情報４３０Ｂを送り、買物・精算管理システム５００は精算処理を行う。

懸賞には割引と金品等があるため、検索・処理機能１４２０は、割引の場合は懸賞データが示す条件（１６２０、１６４０、１６６０など）から割引データを取得して買物情報４３０Ｂを修正し、金品の場合にはそれに対応する処理を行ない、携帯電話３００への通知を行う。この通知は画面だけでなく音声などであっても構わない。

携帯電話３００には、精算処理を要求したとたんに懸賞当選情報が画面や音で通知され、その後に懸賞が反映された精算結果が送られてくるイメージである。

懸賞情報データベース１４６０には、メーカ２０や小売３０がスポンサーとなる様々な懸賞が登録されており、図１５はメーカの順序・組合せ懸賞に当選した買物情報の例である。順序・組合せ懸賞とは、例えば、あるメーカの商品を１年以内にそのメーカが予め決めた購入順序（組合せ）で購入した場合＄１０００（＄１００）の賞金がそのメーカよりもらえる、といったものである。

図 １５では、利用者ＩＤ１６１１が０３５０６３の顧客がＮスポーツのジャケット（商品コード１６１２が４９０２７４０９７６５７８）の精算をした時に、指定された４種の商品コード１６１２（シューズ、シャツ、バック）が一年以内に購入されたことが買物情報データベース１４３０に登録されおり、その順序が図１６の懸賞データの例と合致したため、＄１０００を獲得した例である。ここでは順序が指定されているが、組合せを指定し、＄１００の提供を追加してもよい。

図 １７はメーカの数量限定懸賞に当選した買物情報の例である。数量限定懸賞とは、例えば、ある小売店での買物は精算１００人に１人＄１００まで無料、１０００人に１人は完全無料、といったものである。

図 １７では利用者ＩＤ１６１１の顧客たちが、Ｎスポーツのシューズ（メーカ１６３１がＮスポーツで商品名１６３２がシューズ）の精算をした時に、買物情報データベース１４３０に登録さている精算の総数が１００個以内で、図１８の懸賞データの例と合致したため、３割の割引を獲得した例である。ここでは数量が指定されているが、期間を指定してもよい。

図 １９は小売のランダム懸賞に当選した買物情報の例である。ランダム懸賞とは、例えば、ある商品は最初の１００個の精算まで３割引、といったものである。図２０では利用者ＩＤ１６１１が２１１１６５の顧客が、小売１６５１がＤ１２３の店舗で商品精算をした時に、買物情報データベース１４３０に登録さている精算が１００回目であり、図２０の懸賞データの例と合致したため、１００％の割引を獲得した例である。

そのほかにも、懸賞データが示す条件（１６２０、１６４０、１６６０など）が、異なる複数の商品の購入、商品の購入日時４３８の順序、異なる複数の店舗における購入、異なる複数のメーカの商品の購入、購入日時４３８が、所定の範囲内に収まる、ランダムな当選、当選の数が限定、であったり、それらの組合せであったりしてもよい。

また、ショッピング・モールのような複数の店舗が展開されている商業施設の店舗運営システムは、この懸賞処理システム１６００を持つモバイル・ショッピング・システムを展開してもよい。このことにより、歳末の抽選会や、複数店舗での購入によるスタンプラリーのような、懸賞イベントを、抽選券や応募券などを事前に印刷したり配布することなく、電子的に実施できる。

図 ３０は懸賞処理システム１６００の動作例を示すフローチャートである。
図 ２７の買物・精算管理システム５００のフローチャートのステップ１７５０で懸賞処理が呼ばれると、買物情報管理機能１４１０は、ステップ１７５４で取得した買物情報４３０Ｂを保存して買物情報データベース１４３０を更新する。ステップ１７５６で検索・処理機能１４２０が懸賞情報データベース１４６０から懸賞データが示す条件（１６２０、１６４０、１６６０など）を読込み、ステップ１７５８で買物情報データベース１４３０を検索する。

ステップ１７６０で当選した場合は、図 ３１のステップ１７８２で懸賞当選処理が行われる。ステップ１７８４で懸賞が割引であれば、ステップ１７８６で懸賞データが示す条件（１６２０、１６４０、１６６０など）から割引データを取得し、ステップ１７９０で買物情報４３０Ｂを修正してその割引を適用し、ステップ１７９２で携帯電話３００に通知する懸賞当選情報を作成する。
ステップ１７８４で懸賞が金品であった場合は、ステップ１７８８で金品懸賞処理（発送処理等）を行い１７９２に戻る。

ステップ１７６０で当選しなかった場合や、懸賞当選処理が終了すると、ステップ１７６４で次の商品の懸賞確認がおこなわれる。全ての商品の確認が終わると、ステップ１７６６で当選があった場合は、ステップ１７９２で作成された懸賞当選情報を携帯電話３００に送信し、ステップ１７７０で買物情報データベース１４３０を更新して、買物・精算管理システム５００に買物情報４３０Ｂを渡す。

懸賞機能の例として、アフィリエートモデルによる安い値段による商品の提供も考えられる。これは、顧客が、ある店舗で商品タグ１００をスキャンするが、懸賞システムが他の安い店舗を検索して、そこから商品を購入するもので、この店舗が、購入した店舗より紹介料として手数料をもらうものである。

商品情報３００には商品コード７６３と店舗７６６があるため、懸賞システム１６００は、携帯電話３００がどこの店舗で何の商品をスキャンしたか分かる。
例えば、買物アプリで商品をスキャンして宅配を選んで精算すると、買物情報４３０Ｂが懸賞システム１６００に送られ、懸賞情報ＤＢ１４６０に予めアフィリエート登録された他の小売店舗が検索されて、図１４の買物情報ＤＢ１４３０Ｂの行１６７０の例ように、価格が一番安い店舗とそこの価格が買物情報４３０Ｂの価格４３５と店舗４３７のデータの後ろにそれぞれ追加される。この例では、店舗情報Ｉ２５１０と価格３５０円が追加されている。

買物・精算管理システム５００は、買物情報４３０Ｂから精算情報５８０を抽出する時、利用者登録情報９００から取得した、通常の精算登録情報５８６の情報の後に、アフィリエートの印（例えば“Ａ”）を付加した精算情報５８０の行５９０を作成し、加えて、精算情報５８０のコピーの、利用者ＩＤ５８１を商品がスキャンされた店舗ＩＤ（この例ではＡ５５０）、価格８５３が追加された価格データ（この例では３５０円）、精算登録情報５８６が懸賞情報ＤＢ１４６０にアフィリエート登録している精算口座番号（この例では精算口座aaaaaaaa）と顧客の宅配住所（この例では表示していない）とに変更された精算情報５８０を作成する（通常ひとつの買物情報５８０を二つに分割）。携帯電話３００には、より安い価格で商品を提供する旨を通知し、これらの精算情報５８０を、それぞれの店舗（精算情報５８０の行５９０は商品がスキャンされた店舗Ａ５５０，行５９１はアフィリエート登録された店舗Ｉ２５１０）のストアシステム７００に送信して精算する。

商品をスキャンした店舗は、予め顧客に利用者登録情報９００で指定された方法で精算し、商品を販売した店舗は商品をスキャンした店舗の精算口座番号に予め決められ手数料を引いた分の金額を請求する。

これにより、顧客はより安い値段で同じ商品を購入することが出来る。
小売店舗は、最近流行の兆しがあり頭痛の種である、店舗で商品のバーコードをスキャンして最安値のＥＣサイトで商品を購入する顧客に、同様のサービスをＥＣサイトでの面倒な購入手続きなしに提供し、且つ手数料を得ることが出来る。また、このような傾向の多い商品は在庫を減らして対応することも可能である。

（追加情報）
追加機能として、購入を検討している商品に対する追加情報サービスを提供する場合は、
拡張買物処理システム１４００として追加情報サービス処理システムが追加される。

ここでは第１の追加情報サービス処理システムとして、商品バリエーション管理システム２０００について、第２の追加情報サービス処理システムとして、キャンペーン情報システム２２００について説明する。

図６及び図７は、それぞれ商品バリエーション管理システム２０００およびキャンペー情報システム２２００を適用した場合に、図２のモバイル・ショッピング・システムが機能するブロックをハッチングしたものである。

ここで、商品バリエーション管理システム２０００（第１の追加情報サービス）においては、追加情報７６５は、商品バリエーション情報である。商品バリエーション情報とは、商品情報７６０を取得した商品（買物対象商品）のバリエーション（選択肢、カストマイズ、オプションの単一選択、複数選択）に関する情報の識別子である。取得した商品バリエーション情報から、商品のバリエーションを追加指定することで、取得した商品の商品情報７６０の基本情報の一部を変更（例えば、買物対象商品が青いシャツである場合、シャツの色を赤に変更）を指定したり、商品にオプションを追加（例えば、買物対象商品がアイスクリームである場合、ナッツやチョコチップのトッピングを追加）を指定したりした買物情報４３０を作成できるようになる。

ここで、例えば、商品バリエーション情報は以下のものである。

買物対象商品が衣類で、携帯電話３００で商品情報７６０を取得した買物対象商品（例えば、青色でＭサイズ）とは異なるサイズ（ＳサイズやＬサイズなど）や異なる色・柄（赤色や白黒のストライプなど）の商品が存在する場合は、サイズ違いの商品バリエーションの種類を示すサイズコードテーブル識別子であったり、色・柄などの違いの商品バリエーションの種類を示すカラーコートテーブル識別子であったりする。

また、買物対象商品が料理（例えばステーキ）である場合は、つけ合わせ料理の選択リスト（ベイクドポテト、バターライス、温野菜、マッシュポテトなど）の識別子であったり、サラダのドレッシングの選択リスト（ヴィネグレット、ブルーチーズ、ハニーマスタード、ランチ、サウザンアイランドなどから一つ選択）の識別子であったりする。

また、買物対象商品がアイスクリームである場合は、ゼロ個以上複数個選択可能なフレーバーのチェックリスト（アーモンド、カシューナッツ、フルーツ、マシュマロ、チョコなどからゼロ個以上選択可能）の識別子であったりする。

このような商品バリエーションの識別子（追加情報７６０）は、特定の商品1個に限られることは少なく、その店舗で扱っている、同様の商品すべてに適用できる場合があり、複数の商品情報７６０で、同じ識別子（追加情報７６０）を利用できるという特徴がある。

例えば、店舗の商品が衣類である場合、サイズコードテーブル識別子は、セーターやコートやシャツなどで共通に適用できる。また、例えば、店舗の商品が料理である場合は、つけあわせ料理の選択リストの識別子は、多くのメイン料理（各種ステーキや各種フライなど）で共通に適用できる。

追加情報を利用して指定できる商品によっては、価格が割り増しになったり、割引になったりする場合もある。たとえば、衣類の場合、サイズがＳＳ、Ｓ、Ｍ、Ｌ、ＬＬと合った場合、ＳＳ〜Ｌまでは均一価格であるが、ＬＬについては、１００円割り増しという場合もある。また、たとえば、料理の場合、つけあわせの種類によって、料金の割り増しや、割引を設定（たとえば、ベークトポテトは100円引き、マッシュドポテトは100円増し、温野菜は割り増しなしなど）してもよい。ものがある。アイスクリームの場合、トッピングの種類に応じて、割増料金をゼロ円から、３００円などと、個別に設定してもよい。

また、キャンペー情報システム２２００（第２の追加情報サービス）においては、追加情報７６５は、キャンペーン情報である。キャンペーン情報とは、携帯電話３００で商品情報７６０を取得した買物対象商品に関連するさまざまなキャンペーンやプロモーションの識別子である。

ここで識別子は、例えば、会員割引対象商品であるとか、秋物商品在庫処分セール対象商品であるとか、雨の日特典割引対象商品であるとか、まとめ買い割引セール対象商品であるとか、組み合わせ購入による割引対象商品であるとか、アンケート対象商品であるとかである。

ここでキャンペーン情報の識別子（追加情報７６０）は、キャンペーン対象商品を指定することに使われるが、キャンペーンの内容まで画一的に定義していないという特徴がある。すなわち、追加情報７６０を取得した携帯電話３００によって、異なる内容のキャンペーンを提供することも可能である。例えば、キャンペーン情報の識別子が、冬物処分セールであった場合、携帯電話３００の利用者の過去の買物行動に応じて、異なった割引率（１０％、２０％、３０％など）を提供するようなキャンペーンを提供できる。

さて、追加情報サービス処理システムが導入された場合の、携帯電話３００の動作について、図２６も参照しつつ、詳しく説明する。

携帯電話３００は、商品タグ１００から追加情報７６５を含む商品情報７６０（厳密には商品情報データベース７６０に含まれる該当商品に対応する１レコード分）を取得し、追加情報データベース３４０を参照して、追加情報７６５に対応する当該店舗で有効な（図２２の対象店舗リスト３４１、および、有効期限３４４）識別子３４２に関連付けられているコンテンツ３４３を取得して、取得したコンテンツ３４３も含めて携帯電話３００の画面に表示（図２６のステップ３５８）し、顧客が携帯電話３００を操作して追加情報７６５に対応するコンテンツを操作した場合はその顧客の操作情報も含めて買物情報４３０Ａに記録（図２６のステップ３６４）し、買物完了操作（図 ２６のステップ３６６）とともに、買物情報４３０Ｂとして、インターネット１０などの通信ネットワークを経由して、買物・精算管理システム５００へ送信（図２６のステップ３６８）することで、買物情報４３０Ｂの追加情報４３６で指定した商品の購入ができる。

次に、追加情報サービス処理システム（商品バリエーション管理システム２０００、キャンペーン情報システム２２００など）について、適宜、図３４および図 ３５を参照しながら説明する。ここで、図 ３４および図 ３５は、それぞれ、商品バリエーション管理システム２０００およびキャンペーン情報システム２２００の動作例を示すフローチャート２０５０および２２５０である。

追加情報サービス処理システム（商品バリエーション管理システム２０００、キャンペーン情報システム２２００など）においては、買物情報管理機能１４１０は、買物・精算管理システム５００より、買物情報４３０Ｂを取得（図３４のステップ２０５４および図 ３５のステップ２２５４）し、検索・処理機能１４２０が買物情報４３０Ｂに含まれている追加情報７６５について、買物情報データベース１４３０に記録（図３４のステップ２０５６および図 ３５のステップ２２５６）するとともに、対応する処理を行う。

追加情報サービス処理システムが商品バリエーション管理システム２０００である場合における対応する処理とは、検索・処理機能１４２０が、図３４のステップ２０５８で、取得した追加情報７６５とその操作記録について、買物情報４３０Ｂの店舗４３７に対応する店舗の商品バリエーション情報データベース７８０などを必要に応じて参照し、追加情報７６５およびその指定パラメータが商品のバリエーション情報として有効であることを確認し、指定パラメータにより示されている商品バリエーションに対応する商品情報７６０に変換するなど、追加情報７６５の指定に従って、買物情報４３０Ｂのレコードを編集する。追加情報７６５の種類によっては、追加料金や割引料金が発生するので、買物情報４３０Ｂの価格４３５が変更される場合もある。

追加情報サービス処理システムがキャンペーン情報システム２２００である場合における対応する処理とは、検索・処理機能１４２０が、図３５のステップ２２５６で、取得した追加情報７６５とその操作記録を買物情報データベース１４３０だけでなく、さらにキャンペーン管理システム４２２０のキャンペーン管理データベース４２１０にも保存し、ステップ２２５８で買物情報４３０Ｂの店舗４３７に対応する店舗に有効なキャンペーン情報について、キャンペーン処理システム４２００に照会して、この携帯電話３００の利用者に対応したキャンペーン情報のコンテンツに対応する割引情報の取得やキャンペーンのエントリーの確認情報の取得を行い、ステップ２２６０では、照会結果を用いて、追加情報７６５の示唆するこの携帯電話３００の利用者に対応したキャンペーン情報のコンテンツと有効性を確認し、、ステップ２２６２で、必要に応じて、買物情報４３０Ｂのレコードの編集（値引き処理）やレコードの追加（クーポンレコード）を行う。

同時に、キャンペーン管理システム４２００では、キャンペーン情報システム２２００から取得した買物情報４３０Ｂより、キャンペーンに応募した携帯電話の利用者と応募しているキャンペーンについて、キャンペーン管理データベース４２１０を参照することで特定するとともに、応募実績についてキャンペーン管理データベース４２１０に登録する。キャンペーン作成評価システム４２１０は、キャンペーン管理データベース４２１０を運用することで、過去のキャンペーンの効果の測定、および、新しいキャンペーンの生成と登録を行う。ここでキャンペーン管理システム４２００とは、例えばＩＢＭのＵＮＩＣＡおよびＣＯＲＥＭＥＴＲＩＣＳのようなシステムをさしている。

買物・精算管理システム５００は、追加情報サービス処理システム（商品バリエーション管理システム２０００、キャンペーン情報システム２２００など）より編集された買物情報４３０Ｂを取得し、精算処理を行ったのち、精算情報５８０をストアシステム７００に送信し、買物処理を完了する。

次に、携帯電話３００が取得した追加情報７６５を含む商品情報７６０を画面に表示し、買物情報４３０Ｂを作成するステップについて、携帯電話３００の画面の例を詳しく説明する。

図 ３６は、携帯電話３００が、商品タグ１００から取得した商品情報７６０を、画面に表示した例である。

商品であるグレーのストレートパンツからは、メーカ７６１として『Ｇ衣料』、商品名７６２として『ストレートパンツ 色：グレー サイズ：ウエスト７６ 股下７２』、商品コード７６３として『４９０８４２００９９０２３』、価格７６４として『１９８０円』、店舗コード７６６『Ａ５５０』などを商品情報７６０として取得する。

追加情報サービスが追加されている場合は、さらに追加情報として、カラーテーブルとして識別子『Ｃ０３』、サイズテーブルとして識別子『Ｓ０２』、キャンペーンとして識別子『Ｍ００２』『Ｄ００３』もあわせて取得する。

追加情報サービスが追加されている場合には、例えば、商品名７６２は、『ストレートパンツ 色：%%C03%{グレー} サイズ：%%S02%{８２ ７８} %%M002%{%} %%D003%{%}』であるような商品情報７６０を取得する。

この例では、携帯電話３００の表示画面上の商品名欄に情報を追加することを明示するために、追加したい場所を特殊文字列”%{“および”%}”ではさみ、その直前に識別子を特殊文字列”%%”に続けて挿入している。

すなわち、『オーク』については、カラーテーブルＣ０３が示す色違い商品の選択肢があること、『ウエスト７６ 股下７２』については、サイズテーブルＳ０２が示すサイズ違い商品の選択肢があることを示している。また、この商品は、キャンペーンコードＭ００２およびＤ００３の対象商品であることも示している。

携帯電話３００は、取得した商品情報７６０より、追加情報７６５を抽出する。上の例では、追加情報に識別子は、”%%”、識別子、”%{“、追加対象の情報、”%}”のようにしてエンコードされているので、取得した情報より”%%”を検出することで、追加情報７６５の識別子（Ｃ０３，Ｓ０２，Ｍ００２およびＤ００３）とそれぞれを追加表示する位置とを取得できる。

引き続き、携帯電話３００は、取得した追加情報７６５のコンテンツを、携帯電話内の追加情報データベース３４０を参照して取得する。

図 ２２は追加情報データベース３４０の例である。追加情報データベース３４０は携帯電話３００の中に存在し、携帯電話３００が取得した追加情報７６５のコンテンツを取得するために使われる。追加情報データベース３４０は、各レコードが、対象店舗リスト３４１、識別子３４２、コンテンツ３４３、有効期限３４４、状況３４５に関する情報を含んでいる。

対象店舗リスト３４１とは、その行のレコードのコンテンツ３４３が有効な店舗を示す。特定の店舗1軒のみ（Ｆ２０３のみ、あるいはＡ５５０のみ）の場合もあれば、複数店舗の場合（Ａ５５０およびＡ５５１）の場合もあれば、グループ店舗全部の場合（Ａグループ店舗、すなわち、Ａ００１からＡ９９９までなど）もある。

識別子３４２とは、その行のレコードのコンテンツ３４３が有効な識別子を示す。

コンテンツ３４３は、取得した商品情報７６０に含まれている識別子を置き換えるコンテンツを示している。図の例では簡単な表現となっているが、スクリプトやプログラムを含めるようにしてもよい。

有効期限３４４は、その行のレコードのコンテンツ３４３の有効期限を示す。有効期限切れとなったコンテンツは、携帯電話３００が、適宜（アプリの起動時などに）、追加情報データベース３４０から削除する。

状況３４５は、その行のレコードのコンテンツ３４３の利用状況を示す。表示済、応募済、棄却済など、過去にその携帯電話３００において、そのコンテンツ３４３に対してどのような操作が行われたかを記録する。

この状況３４５の情報を用いて、必要に応じてコンテンツの表示を修正することができる。たとえば、表示済や応募済のコンテンツであれば、携帯電話３００の画面に商品情報を表示する際（たとえば、図３６の画面Ｂ〜Ｄのキャンペーン表示２２３２および２２３４）に過去の操作状況に応じて表示の色を変えて、顧客に知らせることができる。

このことにより顧客は以前表示したものと同じ情報であることやすでに応募済の情報であることを知ることができ、操作性を向上できる。例えば、応募済の場合（あるいは自動応募も含む）は、詳細画面において、応募ボタン（図３６の画面Ｆ〜Ｇの応募ボタン２２２６など）を削除して、詳細画面にも応募済などと表示をすることもできる。

さらに、買物情報の取得回数に応じて、応募可能な回数が増える場合は、その条件に応じたようなカウントや最終応募日時のような情報を状況３４５に記録することで、商品情報表示画面や詳細画面に対応する情報を表示することができる。

取得した追加情報７６５に対応するコンテンツを取得するには、それぞれの追加情報７６５の識別子に対して、識別子３４２フィールドの一致するレコードを抽出し、さらに、取得した店舗コード７６６に合致するレコードを抽出する。抽出されたレコードのコンテンツ３４３が追加情報７６５に対応するコンテンツとなる。

たとえば、上の例では、識別子Ｃ０３のカラーテーブルは、店舗Ａ５５０で取得したので、対象店舗リスト３４１が『Ａ（グループ店）』、識別子３４２が『Ｃ０３』のレコードのみが一致し、有効期限３４４も期限内の『2020年12月31日』であることから、コンテンツ３４３として、『カラー選択, {グレー, ブラック,オーク}』が求まる。

一方で、同じ識別子Ｃ０３のカラーテーブルは、別店舗Ａ５５１で取得していれば、同じＡグループ店であるが、期間限定（2011年12月31日まで）、店舗限定（Ａ５５１とＡ５５２のみ）で、限定色カラー『ゴールド』が追加されたテーブルとなる。なお、店舗Ａ５５１では、条件に合致するコンテンツ３４３が二つ（『カラー選択, {グレー, ブラック,オーク}』および『カラー選択, {グレー, ブラック, オーク、ゴールド}』）存在するが、複数の候補が存在した場合は、対象店舗リスト３４１や有効期限３４４の指定がより限定的なものを優先する、コンテンツ３４３のバイト数の少ない方を優先する、コンテンツ３４３のハッシュ値の少ない方を優先するなど、あらかじめ一つに絞り込むルールを適用する。

逆に、識別子３４２と対象店舗リスト３４１と有効期限３４４で絞込みレコードを抽出して条件に合致するレコードがひとつも存在しない場合も考えられる。その場合は、追加情報データベース３４０を更新することで、最新の追加情報を入手すれば、コンテンツを取得できる可能性がある。

また、店舗Ａ５５０でキャンペーンＳ２２３を取得した場合は、コンテンツ３４３が『ＮＵＬＬ』となっているが、このキャンペーンＳ２２３はこの携帯電話３００では対象外であり、この携帯電話３００に対応する追加情報が存在しないことを示している。

ここでは、追加情報は、商品バリエーション情報とキャンペーン情報を含む。

追加情報の商品バリエーションの例としては衣類などのカラーテーブルがある。

同様に追加情報としては、衣類などのサイズテーブル、アイスクリームのフレーバーやトッピング、ステーキの付け合せの野菜やライスやポテトの選択などがある。

また、追加情報のキャンペーン情報の例としては、通年キャンペーン、月代わりキャンペーン、日替わりキャンペーン、タイムサービスなどがある。

追加情報の種類に応じて、識別子を分類すると、携帯電話３００において、画面表示をする際に、識別子に対応するコンテンツを、追加情報の種類に対応する表示フィールドに振り分けたり、キャンペーンの期間に応じて、前回の更新と比較して、最新情報の取得が必要かどうかの判断に使ったりできる。

たとえば、カラーテーブルは識別子をＣで始めたり、サイズテーブルは識別子をＳで始めたりして分類できる。

また、キャンペーンは、通年キャンペーン、月替わりキャンペーン、日替わりキャンペーン、タイムサービスなどキャンペーン期間に応じて、識別子をそれぞえＹ、Ｍ、Ｄ、Ｓで始めるなどして、区別することもできる。

ふたたび、図 ３６にもどり、携帯電話３００が取得した商品情報７６０を画面に表示している様子を画面Ａより画面Ｇに示している。

図 ３６の画面Ａは携帯電話が取得した商品情報７６０の基本情報を示している図である。追加情報サービスが追加されていない場合はこの画面が基本となる。また、追加情報サービスが追加されていても、追加情報の識別子（例えば、Ｃ０３、Ｓ０２，Ｍ００２、Ｄ００３）が有効でない場合は画面Ａのようになる。

ここで、追加情報の識別子が有効ではないということは、識別子がこの携帯電話３００にとって、対象外であるか、期限切れであるか、未取得であるかのいずれかである。

画面Ａでは、２０２０に画面のタイトル『お買物確認画面』、２０２２、２０２４、および２０２６に商品名７６２を、２０２８に価格７６４『１９９０円』が表示されている。２０３０には個人価格、２０３２に定価と個人価格の差額である値引き額が表示されている。個人価格は、モバイル・ショッピング・システムが発行したクーポンなどにより、携帯電話３００が計算した、割引価格である。２０３４は顧客が購入希望の個数を指定するドロップダウンメニューである。

さらに、画面の下部には、２０３６の購入ボタン、２０４０の次の商品ボタンがある。購入ボタン２０３６を押すと購入商品として買物情報４３０Ａに登録される。次の商品ボタン２０４０を押すと購入しなかった商品として買物情報４３０Ａに登録される。

さらに、ブックマークシステム１８００が追加されている場合には、２０３８のＢＭボタンも表示される。ＢＭボタン２０３８を押すとブックマーク商品として、買物情報４３０Ａに登録される。

購入ボタン２０３６、ＢＭボタン２０３８、あるいは、次の商品ボタン２０４０のいずれかが押され、買物対象商品への操作が完了すると、次の買物対象商品について商品情報の取得を行うか、今までに取得した買物情報４３０Ａについて、精算処理の操作を行い買物を完了する。

図 ３６の画面Ｃは、追加情報サービスが追加されている場合で、上の画面Ａの例とまったく同じ商品情報７６０を取得し、商品名７６２『ストレートパンツ 色：%%C03%{グレー} サイズ：%%S02%{８２ ７８} %%M002%{%} %%D003%{%}』に含まれる追加情報Ｃ０３、Ｓ０２、Ｍ００２およびＤ００８を展開した様子である。

画面Ｃを画面Ａと比較すると、Ｃ０３およびＳ０２により、それぞれお２０２４の色の行および２０２６のサイズの行が、ドロップダウンメニューとなって、それぞれ他の色およびサイズに変更できるようになっている。

またさらに、画面Ｃを画面Ａと比較すると、画面下部に、ふたつのキャンペーンが表示されており、Ｍ００２が『まとめ買いキャンペーン』２２３２、Ｄ００８が『ベルトキャンペーン』２２３４に対応している。

画面Ｃにおいて、色のドロップダウンメニュー２０２４をクリックすると２０４２のようなメニューが表示され、買物対象商品はグレーであるが、別の色の商品に変更できる。この場合は色の指定を単一選択メニューで変更できるようなコンテンツである。

コンテンツの記述言語を例えばＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を利用するなどして拡張すれば、単一選択、0個以上の複数選択、1個以上の複数選択、3個選択など、オプションや選択をさまざまに指定できる。

同様にサイズのドロップダウンメニュー２０２６をクリックすると２０４４のようなメニューが表示され、買物対象商品とは異なるサイズの商品を指定して買物できる。また、画面Ｃにおいて、２２３２および２２３４のキャンペーンをクリックすると、キャンペーンの詳細画面で画面Ｆおよび画面Ｇをそれぞれ表示する。

画面Ｆおよび画面Ｇにはキャンセルボタン２２２８が設置されており、画面内容を確認して、画面Ｃに戻ることができる。

キャンペーンによっては、自動的に応募対象とならず、クリックして応募することを条件とするものがある。このことによって買物客のキャンペーンへ参加できるメリットを明確にしておとく感を与えるとともに、キャンペーンの有無にかかわらず購入するような買物客に対してかける不必要なコストを削減することができる。このように応募を前提とするキャンペーンの場合は、応募を確認するための応募ボタン２２２６を画面Ｆおよび画面Ｇに設置する。

携帯電話３００の画面Ａ〜画面Ｇまでの、選択操作および表示操作は、操作の日時および操作結果とともに買物情報４３０Ａの追加情報４３６に記録される。

例えば、図 ９の追加情報４３６には、操作対象となった追加情報については操作結果の組のリストとして記述される。

たとえば、『Ｃ０３青』とは、カラーテーブルＣ０３を参照して、青を選択したという意味であり、『Ｓ０２Ｍ』とは、サイズテーブルＳ０２を参照して、Ｍを選択したという意味である。この図９においては、簡単のため追加情報とその操作結果のみを記載しているが、さらに、操作の過程についてもあわせてタイムスタンプをつけて記述し、詳細にリストとして記述することもできる。

そうすれば、買物対象商品について、２０１１年１１月５日午前１０時２８分３０秒にカラーテーブルＣ０３を表示して、午前１０時２８分３５秒にピンクを選択して色の変更をし、さらに、午前１０時２８分５０秒にカラーテーブルＣ０３を表示して、午前１０時２９分５秒に青を選択して色の変更をし、午前１０時２９分４５秒にキャンペーンＹ０００２をクリックして詳細表示して、午前１０時３０分４０秒にキャンペーン応募ボタンをおしてキャンペーンへの参加登録をしたなどの情報が詳細に記録される。

操作されなかった追加情報については、パラメータ（操作記録や操作時刻）なしで買物情報４３０Ａの追加情報４３６に記録してもよい。このことにより、追加情報の効果を測定することもできる。また、以前応募したキャンペーンなどまだ有効で、応募済表示をしたような場合は、今回の買物においては応募操作はないが、今回の買物情報に応募済表示済などとして含めておくべきである。

このことにより、追加表示の有無、さらに、表示から選択までの所要時間などによって、色の選択の人気度やキャンペーンの効果などを分析することができるようになる。

再び図 ３６を参照しながら説明を続ける。

取得した追加情報を画面に展開するには、追加情報データベース３４０を参照して、対応するコンテンツを取得する。たとえば、識別子Ｃ０３のカラーテーブルは、『カラー選択, {グレー, ブラック,オーク}』がコンテンツである。

画面Ａの『グレー』の部分をグレー、ブラック、オークの選択メニューにおきかえ、デフォルト値を買物対象商品の色である『グレー』にセットする。

また、キャンペーンなどは、欄外にタイトルのみを表示し、クリックすることで、詳細表示画面で応募するかどうかの確認をする。コンテンツの既述にキャンペーンタイプをさらに指定すれば、キャンペーンを応募式だけでなく、自動応募式などさまざまな種類を指定できるようになる。

図 ３６の画面Ｂおよび画面Ｄも、画面Ｃ同様に、追加情報サービスが追加されている場合で、上の画面Ａの例とまったく同じ商品情報７６０を取得し、商品名７６２『ストレートパンツ 色：%%C03%{グレー} サイズ：%%S02%{８２ ７８} %%M002%{%} %%D003%{%}』に含まれる追加情報Ｃ０３、Ｓ０２、Ｍ００２およびＤ００８を展開した様子である。

画面Ｄでは２２３４は表示されているが２２３２は表示されていない、すなわち、取得した追加情報に対応する一部キャンペーンが表示されていない。これは、画面Ｄを表示している携帯電話３００では、追加情報Ｍ００２を追加情報データベース３４０に照会するとコンテンツＮＵＬＬ（対象外）となるためである。

また、画面Ｂは、一見画面Ｃと同様であるが、２２３２のキャンペーンをクリックして得られる詳細画面が画面Ｅとなり画面Ｆと異なる。これは、画面Ｂを表示する携帯電話３００と画面Ｃを表示する携帯電話３００とでは、追加情報Ｍ００２をそれぞれの携帯電話３００の追加情報データベース３４０に照会すると、コンテンツは携帯電話３００によって異なるため、表示される優待情報が異なっているためである。

続いて、携帯電話３００が内部に持つ追加情報データベース３４０を更新・管理する方法について説明する。

追加情報データベース３４０は、携帯電話３００が商品情報７６０から取得した追加情報７６５を適切に解釈できるように、最新になるように管理されることが望ましい。取得した追加情報７６５が追加情報データベース３４０に存在しなかったり、有効期限切れであったりした場合は、追加情報データベース３４０を更新（対応する追加情報のみの取得あるいは追加情報データベース全体の更新）しないと取得した追加情報を表示できない。そのような場合は、追加情報の表示をしないか、追加情報を取得してから追加情報を含めた情報表示を行うかする。

追加情報データベース３４０の更新は、顧客の操作、通信コスト、顧客の買物操作の中断や遅れの、いずれかあるいは全部を伴う場合があるので、更新を行う前に、顧客に更新を行うかどうかの確認を求め、顧客の同意が得られた場合のみ更新を行うようにしてもよい。

追加情報の表示をしない場合は、追加情報データベース３４０を更新すると新しい追加情報を表示できる可能性があることを、携帯電話３００が顧客に通知することもできる。通知方法は、携帯電話３００は、画面表示や音や振動などで行う。

追加情報データベース３４０の一部または全部を更新してから、追加情報の表示をする場合は、携帯電話３００は、更新に伴う顧客の操作について、画面表示や音や振動などで伝えてもよい。

ここで、更新の方法とは、顧客が追加情報タグを見つけ、携帯電話３００が、顧客がかざした追加情報タグから追加情報を取得することを含む。

たとえば、衣料品販売店では、携帯電話３００が、セーター（色：青色、サイズ：Ｍ）に対応する商品タグ１００から取得した商品情報７６０に含まれている、色やサイズの商品バリエーションに関する追加情報７６５が、追加情報データベース３４０に含まれていない場合、この衣料品販売店の入り口や、壁や、柱などに設置された、色・サイズコードテーブルに対応する追加情報タグを読み取り、追加情報データベース３４０を更新する。

この場合、追加情報タグは、この衣料品販売店が扱う追加情報を、図 ２３に示すような商品バリエーション情報管理データベース７８０から取得して、対象者７８３の限定のない、識別子７８１、有効期間７８２、コンテンツ７８４を提供する。

携帯電話３００は、提供された追加情報のすべて、あるいは、必要な一部を取得する。ここで必要な一部とは、現在表示しようとしている商品情報７６０に含まれている追加情報７６５の取得を済ませれば、必ずしも全部を一度に取得する必要はない。特定の顧客のみが対象の追加情報については、後述する買物終了時や追加情報データベース更新処理時などに取得し、今回の買物では利用できない。

また、追加情報タグは、この衣料品販売店が扱う追加情報を、図 ２３に示すような商品バリエーション情報管理データベース７８０から取得して、対象者７８３の限定のある情報も含めて、識別子７８１、有効期間７８２、対象者７８３、コンテンツ７８４を提供してもよい。

携帯電話３００は、提供された追加情報を取得する際に、携帯電話３００が保持しているモバイル・ショッピング・システムに関する登録情報およびカストマイズ情報（携帯電話３００の利用者、あるいは、モバイル・ショッピング・システム利用によって買物を行う顧客に関する基本情報やプリファランス情報など）と比較して一致するものを探し、携帯電話３００が対象となっている情報のすべて、あるいは、必要な一部を取得する。

また、他の更新の方法では、携帯電話３００が、自動的に、あるいは、必要に応じて顧客に同意の操作をうながし、携帯電話網や無線ＬＡＮなどの通信機能を用いて、主にインターネット１０を経由して、追加情報サービス処理システム（商品バリエーション管理システム２０００、あるいはキャンペーン情報システム２２００）に追加情報データベース３４０の更新情報を取得する通信し、携帯電話３００が対象となっている追加情報のすべて、あるいは、必要な一部を取得する。

ここで必要な一部とは、通信時に携帯電話３００が、取得したい追加情報を、携帯電話３００を利用している顧客ＩＤと商品情報を取得した店舗ＩＤとともに、照会のパラメータとして含めて、追加情報サービス処理システム（商品バリエーション管理システム２０００、あるいはキャンペーン情報システム２２００）に送信することで実現する。

あるいは、必要な一部とは、通信時に、拡張買物管理システム１４００が、買物情報データベース１４３０から対象となる携帯電話３００の追加情報データベース３４０の更新情報を抽出し、最終更新時からの差分だけの追加情報を送信することで実現する。

追加情報サービス処理システムは、前述の精算時と同様の仕組みにより、商品バリエーション管理システム２０００、あるいは、キャンペーン情報システム２２００が商品バリエーションデータベース７６０あるいはキャンペーン管理データベース４２１０より、携帯電話３００が対象となる追加情報７６５を取得する。

さらに、他の更新の方法では、携帯電話３００が、買物・精算システム５００より精算結果情報を受け取って、精算結果表示を行う時（図２６のステップ３７０）に、追加情報サービス処理システム（商品バリエーション管理システム２０００、あるいはキャンペーン情報システム２２００）より、買物・精算システム５００を経由して、前記と同様な方法で生成した更新情報により、追加データベース３４０を最新に更新する。

さらに、他の更新の方法では、携帯電話３００が、買物を行う前などに、顧客の了承のもと、あるいは、自動的に、あるいは、定期的に、追加データベース３４０を最新に更新する。

より具体的には、図 ２６において、ステップ３５４において、通常の買物以外の追加データベース３４０のメンテナンスモードが選ばれた場合、まず、ステップ３８４において、追加データベース３４０の最終更新日時を取得し、ステップ３８６において、追加データベース３４０の更新の必要性について判断し、過度の更新手続きを排除しつつ、更新が必要な場合は、ステップ３８８において、追加情報サービス処理システム（商品バリエーション管理システム２０００、あるいはキャンペーン情報システム２２００）と通信して更新に必要な差分情報取得し、ステップ３９０において、追加データベース３４０に対して、有効期限切れの追加情報を削除した上で、取得した追加情報を挿入し、最新の状態に更新し、最終更新情報も更新する。

ステップ３８６において、更新の必要がないと判断された場合は、ステップ３９０において、追加データベース３４０に対して、有効期限切れの追加情報の削除などの整理のみを行う。

図 ３２は、携帯電話３００が、追加データベース３４０を新規導入を含む維持管理するフローの一例４８０を示している。

ステップ４８４において、まず携帯電話３００は追加情報サービス処理システム（商品バリエーション管理システム２０００、あるいはキャンペーン情報システム２２００）に接続する

ステップ４８６において、携帯電話３００からの最初の接続か、更新の接続かを判断する。ここで、最初の接続はリセットを含む。

更新の接続の場合は、ステップ４８８において、追加情報サービス処理システム（商品バリエーション管理システム２０００、あるいはキャンペーン情報システム２２００）上の更新情報の有無を確認する。

更新情報がない場合は、通信を切断し、終了する。更新情報があれば、ステップ４９２において、前回更新からの追加された更新情報を追加情報サービス処理システムから取得する。

ステップ４９４において、追加情報サービス処理システムは携帯利用者ＩＤに対応して、買物客にカストマイズした更新情報を送信する。携帯電話は、更新情報を受け取り、携帯端末内の追加情報データベース３４０を更新する。更新情報は、情報ラベル３４１、コンテンツ３４２、状態３４３、有効期限３４４を含む。さらに、追加情報データベースの更新日時情報も更新する。そして、通信を切断し、終了する。

ステップ４８６において、最初の接続であった場合は、ステップ４９０において、対象情報（パーソナライズ済）ラベルとその情報本体をサーバから取得する。そして、ステップ４９４に進む。

図 ３３は、追加情報サービス処理システム（商品バリエーション管理システム２０００、あるいはキャンペーン情報システム２２００）が、追加データベース３４０を維持管理するために携帯電話３００と通信するフローの一例２１５０を示している。

ステップ２１５４で携帯電話３００と接続し、通信を開始する。

ステップ２１５６では、利用所登録情報データベース９００に登録済の携帯電話３００であるかを確認する。

ステップ２１５６で未登録であった場合は、ステップ２１６０で、顧客情報、携帯端末情報、プリファランス情報を、携帯電話３００から取得し、利用所登録情報データベース９００を更新する。例えば、携帯電話３００の画面上にインタラクティブなタイヤログボックスなどを提示し、携帯電話３００の利用者である顧客に入力してもらう。

ステップ２１５６ですでに登録済の携帯電話３００であった場合は、ステップ２１５８でリセット要求か更新要求かを判断する。

ステップ２１５６でリセット要求であった場合、および、ステップ２１６０を実行した後は、ステップ２１６２で追加情報データベース３４０の更新範囲を全部とし、ステップ２１６６へ進む。

ステップ２１５６で更新要求であった場合は、ステップ２１６４で、追加情報データベース３４０の更新範囲を最終更新日からの差分更新とし、ステップ２１６６へ進む。最終更新日は、買物情報データベース１４３０に記録されている、対象携帯電話３００の、追加情報データベースの更新記録を取得し、求めたものを使用する。

ステップ２１６６では、利用所登録情報データベース９００にを参照して、携帯端末３００の属性と、携帯端末３００の利用者である顧客の基本情報とプリファランスに対応した対象顧客カテゴリ情報を取得し、対応する対象顧客カテゴリに有効で、有効期限内の追加情報を、商品バリエーション情報データベース７８０およびキャンペーン情報データベース４２１０から取得し、携帯端末３００へ送信する。

最後に、ステップ２１６８で、買物情報データベース１４３０に、追加情報データベース３４０の更新の記録を追加する。

図 ２７の買物・精算管理システム５００のフローチャートのステップ２０５０あるいはステップ２２５０において、それぞれ商品バリエーション処理２０５０（図３４）およびキャンペーン処理２２５０（図 ３５）が呼ばれる。

図 ３４は、追加情報サービス処理システムが、商品バリエーション管理システム２０００である場合、検索・処理機能１４２０が、買物情報４３０Ｂから、追加情報を取得し、買物情報４３０Ｂを修正するフローの一例２０５０を示している。

ステップ２０５４で、買物情報２４０Ｂより、追加情報を店舗情報と商品コードとともに取得し、商品バリエーション管理システム２０００が処理すべき、識別子とパラメータ（指定パラメータ、操作日時など）とを取得する。

続いて、ステップ２０５６では、取得した追加情報（識別子とパラメータ）を買物情報データベース１４３０に保存する。

続いて、ステップ２０５８では、取得した追加情報（識別子とパラメータ）から、対応する店舗の商品バリエーション情報データベース７８０を参照して、商品コードを指定されたバリエーションに対応する商品コードに変更するなどして、必要に応じて、買物情報４３０Ｂを修正する。

図 ３５は、追加情報サービス処理システムが、キャンペーン情報システム２２００である場合、検索・処理機能１４２０が、買物情報４３０Ｂから、追加情報を取得し、買物情報４３０Ｂを修正するフローの一例２２５０を示している。

ステップ２２５４では、買物情報２４０Ｂより、追加情報を店舗情報と商品コードとともに取得し、キャンペーン情報システム２２００が処理すべき、識別子とパラメータ（指定パラメータ、操作日時など）とを取得する。

続いて、ステップ２２５６では、取得した追加情報（識別子とパラメータ）を買物情報データベース１４３０およびキャンペーン管理データベース４２１０に、買物情報あるいはキャンペーンの効果情報として記録する。ここでパラメータとは、各キャンペーンへの操作状況（表示して応募、表示しただけ、表示しない）と各操作の時刻を指す。これらから、各キャンペーンが、顧客にどの程度の関心を与えたかを分析できる。

ステップ２２５８では、買物情報２４０Ｂの追加情報に含まれるキャンペーン識別子（操作記録のないものも含む）を抽出し、さらに、買物情報データベース１４３０から応募すみや自動応募など今回の買物で有効なもののみを抽出する。

ステップ２２６０では、ステップ２２５８で抽出したキャンペーン識別子に対応するキャンペーンを、買物情報４３０Ｂと照合して、条件を満たしていて適用可能であるものと、キャンペーンが適用されることによって提供できる報酬（今回の買物の割引クーポンなど）を生成する。

ステップ２２６２では、ステップ２２６０で求められた報酬（割引クーポン）などを買物情報４３０Ｂに追加するなど、キャンペーンを適用して買物情報４３０Ｂを修正する。

図 ２３は、商品バリエーション情報データベース７８０構成の一例を示す。

商品バリエーション情報データベース７８０は、ストアシステム７００の一部として、店舗ごとに存在し、その店舗が提供する追加情報の識別子７８１、有効期間７８２、対象顧客カテゴリ７８３、および、コンテンツ７８４を含む。

識別子７８１は、商品タグに追加情報として含まれるコード情報である。

有効期間７８２は、商品バリエーション情報データベース７８０の一行に対応する追加情報の各レコード追加情報識別子７８１の有効期間を示している。ブックマーク購入サービスを導入している店舗では、有効期限が失効したテーブルも保存しておく必要がある。

対象顧客カテゴリ７８３は、各レコードのバリエーションが有効である利用者、あるいは、携帯電話３００の分類を示す。例えば、『ＡＮＹ』とはすべての携帯電話３００が対象であることを示す。また、『ＳｍａｌｌＳｉｚｅ』とは小さいサイズ商品のみの購入をする利用者が携帯電話３００あるいは商品バリエーション管理システム２０００に登録した携帯電話３００のみが対象であることを示す。

コンテンツ７８４は、対応するレコードの識別子７８１の意味を示す。

図２４は、キャンペーン管理データベース４２１０の構成の一例を示す。

キャンペーン管理データベース４２１０は、キャンペーン管理システム４２００が維持管理し、キャンペーン管理システム４２００が管理しているキャンペーンについて、識別子４２１１、有効期間４２１２、対象店舗リスト４２１３、対象顧客カテゴリ４２１４、および、コンテンツ４２１５を含む。

識別子４２１１は、商品タグに追加情報として含まれるコード情報である。

有効期間４２１２は、キャンペーン情報データベース４２１０の一行に対応する追加情報の各レコード追加情報識別子４２１１１の有効期間を示している。ブックマーク購入サービスを導入している店舗では、有効期限が失効したテーブルも保存しておく必要がある。

対象顧客カテゴリ４２１４は、各レコードのキャンペーンの対象となる店舗あるいはグループ店のリストである。ここで、グループ店とは、同一あるいは類似形態の店舗をチェーン展開するチェーン店舗群（単一スーパーの各支店など）や、異なる業態や経営を含む提携店舗群（単一のポイントカード提携店舗など）を含む。

対象顧客カテゴリ４２１４は、各レコードのキャンペーンが有効である利用者、あるいは、携帯電話３００の分類を示す。例えば、『ＧＯＬＤ』とは携帯電話３００の利用者がＧＯＬＤ会員であることを示す。また、『Ashop-GOLD』とは、Ａグループ店でのゴールド会員を示す。この場合は、Ｂグループ店で『Ashop-GOLD』を優遇するとは、Ａグループ店のタイアップイベントで、Ａグループ店の優良顧客を優遇している例である。

コンテンツ４２１５は、対応するレコードの識別子７８１の意味を示す。

本発明は、ステップの各々を処理する方法として、各ステップを処理するプログラムコードを有するプログラムとして、さらには、処理を行うシステムとして、体現することができる。

特許請求の範囲において（ ）付きで付されている一連の符号の全ては、明細書や図面との対応付けを分かりやすくするためのものにすぎず、各用語の意義や本発明の技術的思想が限定的に解釈されてしまう理由とはならない。

１０：インターネット
２０：メーカ
３０：小売
６０：ＰＯＳ ＩＦエミュレータ・システム
１００：商品タグ
１２０：ＥＳＬ
１４０：紙棚札
２００：商品タグ管理システム
２２０：棚札コントローラ
２４０：紙棚札印刷
２５０〜２６２：棚札コントローラ動作フローチャート、および、各ステップ
３００：モバイルデバイス（携帯電話、携帯デバイス、携帯端末）
３４０：追加情報データベース
３４１〜３４５：追加情報データベースの列の名前
３５０〜３９０：携帯電話３００の動作フローチャート、および、各ステップ
４３０：買物情報
４３１〜４４３：買物情報の表の列の名前
４４９：ブックマーク購入のレコード
４３０Ａ：買物情報(通常、買物中)
４３０Ｂ：買物情報(通常、精算時)
４３０Ｃ：買物情報(ブックマーク購入、買物中)
４３０Ｄ：買物情報(ブックマーク購入、精算時)
４８０〜４９６：携帯電話３００が追加情報データベース３４０を取得・更新するフローチャートおよび各ステップ
５００：買物・精算管理システム
５１０：買物・精算管理システムの通信機能
５２０：買物・精算管理システムの買物情報取得機能
５３０：買物・精算管理システムの買物情報抽出機能
５４０：買物・精算管理システムの精算確認機能
５５０：買物・精算管理システムの通信機能
５８０：精算情報、あるいは、精算情報データベース
５８１〜５８６：精算情報データベースの列の名前
５８８：ブックマーク購入の行（精算情報）
５９０：アフィリエート購入の行（精算情報 商品スキャンの店舗）
５９１：アフィリエート購入の行（精算情報 商品購入の店舗）
６５０〜６６８：精算システムフローチャートおよび各ステップ
７００：ストアシステム
７２０：ＰＯＳ
７２０：ＰＯＳの精算機能
７３０：ＰＯＳのキーボード・インタフェース
７４０：ＰＯＳのディスプレイ・インタフェース。
７５０：ストアシステムの通信機能
７６０：ストアシステムの商品情報データベース
７６１〜７６７：商品情報データベースの列の名前
７７０：ストアシステムの商品情報履歴データベース
７８０：ストアシステムの商品バリエーション情報データベース
７８１〜７８４：商品バリエーション情報データベースの列の名前
９００：利用者登録情報データベース
９３１〜９３６：利用者登録情報データベースの列の名前
１２００：POS IFエミュレータ
１２１０：POS IFエミュレータの通信機能
１２２０：POS IFエミュレータの精算データ加工検証機能
１２３０：POS IFエミュレータのＰＯＳ精算データ入力
１２４０：POS IFエミュレータのキーボード・スキャナ・エミュレーション
１２６０：POS IFエミュレータのキーボード・インタフェース
１２７０：POS IFエミュレータのディスプレー・データ・モニター
１２８０：POS IFエミュレータのディスプレー・インタフェース
１３１０：キーボード・インターフェース入力用データ
１３５０〜１３７２：POS IFエミュレータ動作フローチャート、および、各ステップ
１４００：拡張買物管理システム（懸賞システム１６００、ブックマークシステム１８００、商品バリエーション管理システム２０００、キャンペーンシステム２０００など）
１４１０：拡張買物管理システムの買物情報管理機能
１４２０：拡張買物管理システムの検索・処理機能
１４３０：拡張買物管理システムの買物情報データベース
１４６０：拡張買物管理システムの懸賞情報データベース
１４７０：拡張買物管理システムの通信機能
１４８０：拡張買物管理システムのブックマークデータベース
１４９９：買物情報（ブックマーク）のレコード
１６００：懸賞処理システム
１６１０： 懸賞用買物情報の抽出例（順序、組み合わせ懸賞）
１６１１〜１６１３：懸賞用買物情報の表の列のラベル（順序、組み合わせ懸賞）
１６２０：懸賞データの例（順序、組み合わせ懸賞）
１６３０： 懸賞用買物情報の抽出例（時間・数量限定懸賞）
１６３１〜１６３３：懸賞用買物情報の表の列または行の名前（時間・数量限定懸賞）
１６４０：懸賞データの例（時間・数量限定懸賞）
１６５０： 懸賞用買物情報の抽出例（ランダム懸賞）
１６５１〜１６５２：懸賞用買物情報の表の列または行の名前（ランダム懸賞）
１６６０：懸賞データの例（ランダム懸賞）
１６７０：買物情報（アフィリエート購入）のレコード
１７５０〜１７７２：懸賞処理システム動作フローチャート、および、各ステップ
１７８０〜１７９４：懸賞当選処理システム動作フローチャート、および、各ステップ
１８００：ブックマークシステム
１９５０〜１９６８：ブックマーク処理動作フローチャート、および、各ステップ
２０００：商品バリエーション管理システム
２０２０〜２０４６：携帯画面各部
２０５０〜２０６０：商品バリエーション管理システム動作フローチャート、および、各ステップ
２１５０〜２１７０：商品バリエーション管理システムセットアップ動作フローチャート、および、各ステップ
２２００：キャンペーン情報システム
２２２２〜２２３４：携帯画面各部
２２５０〜２２６４：キャンペーン情報システム動作フローチャート、および、各ステップ
３２００：POS機能データベース
４２００：キャンペーン管理システム
４２１０：キャンペーン管理データベース
４２１１〜４１２５；キャンペーン管理データベースの列の名前
４２２０：キャンペーン作成評価システム

Claims (12)

1. 携帯電話（３００）によって、商品に対応する商品タグ（１００）から商品情報（７６０）を取得し、１回以上の取得によって買物情報（４３０Ａ、４３０Ｂ）を作成し、その買物情報（４３０Ｂ）から精算情報（５８１〜５８５）を抽出し、利用者登録情報（９００）から取得した精算情報（５８６）とから作成した精算情報（５８０）を対象（５００からの出力）にして、
   精算データ加工検証機能（１２２０）が、ＰＯＳ機器情報（３２００、キーボード／スキャナーインターフェース情報、ＰＯＳアプリケーションの操作順序、等）に従って、抽出された精算情報を加工して、ＰＯＳの入力操作をエミュレーションして、キーボード／インターフェースから、ＰＯＳ（７１０）に入力し、
   ＰＯＳ機器情報（３２００）に対応するＰＯＳ（７１０）が精算できるようにする、
   ＰＯＳ ＩＦ エミュレータ（１２００）。
2. さらに、
   精算データ加工検証機能（１２２０）が、入力に応じてＰＯＳ（７１０）が出力したディスプレイ出力を、ＰＯＳ機器情報（３２００、カスタマーディスプレーインターフェース情報）に従って取得する、
   請求項１に記載のＰＯＳ ＩＦ エミュレータ（１２００）。
3. ＰＯＳ（７１０）が出力したディスプレイ出力と、ＰＯＳ（７１０）に入力した精算情報（５８３×５８４）とを比較し、
   これらが一致しなかった場合には、ＰＯＳの操作をエミュレーションして、キーボード／インターフェースから、取り消し操作をＰＯＳ（７１０）に入力する、
   請求項２に記載のＰＯＳ ＩＦ エミュレータ（１２００）。
4. ＰＯＳ（７１０）が出力したディスプレイ出力と、ＰＯＳ（７１０）に入力した精算情報（５８３×５８４）とを比較し、
   これらが一致しなかった場合であっても、ＰＯＳ（７１０）に入力した精算情報（５８３×５８４）の方が安い場合にのみ、取り消し操作をＰＯＳ（７１０）に入力する、
   請求項２に記載のＰＯＳ ＩＦ エミュレータ（１２００）。
5. ＰＯＳ（７１０）からの検証されたディスプレイ出力と、ＰＯＳ（７１０）に入力した精算情報（５８３×５８４）とを比較し、
   これらが一致しなかった場合には、ストアシステム（７００）に通知する、
   請求項２に記載のＰＯＳ ＩＦ エミュレータ（１２００）。
6. 請求項１に記載のＰＯＳ ＩＦ エミュレータ（１２００）と、
   作成された買物情報（４３０）から精算情報（５８０）を抽出し、抽出された精算情報（５８１〜５８５を抽出、５８６を省く）を得る、買物・精算管理システム（５００）とを有する、
   システム（６０）。
7. 請求項１に記載のＰＯＳ ＩＦ エミュレータ（１２００）の機能を備えた、
   商品タグ管理システム（２００）。
8. 買物情報（４３０）に含まれている店舗情報（４３７）を使って、店舗ごとの精算情報（５８０）を抽出することによって、それぞれの店舗のＰＯＳにおいて精算できるようにする、
   請求項１に記載のＰＯＳ ＩＦ エミュレータ（１２００）。
9. 請求項１に記載のＰＯＳ ＩＦ エミュレータ（１２００）を複数利用することによって、買物情報（４３０）に含まれている店舗情報（４３７）を使って、店舗ごとの精算情報（５８０）を抽出することによって、対応する複数の店舗のそれぞれのＰＯＳにおいて精算できるようにする、
   買物精算管理システム（５００）。
10. 請求項１に記載のＰＯＳ ＩＦ エミュレータ（１２００）を利用して、複数の店舗が展開されている商業施設において、それぞれの店舗のＰＯＳにおいて精算できるようにされている、
    店舗運営システム。
11. 携帯電話（３００）によって、商品に対応する商品タグ（１００）から商品情報（７６０）を取得し、１回以上の取得によって買物情報（４３０Ａ、４３０Ｂ）を作成し、その買物情報（４３０Ｂ）から精算情報（５８０）を抽出し、抽出された精算情報（５８１〜５８５を抽出、５８６を省く）を対象（５００からの出力）にして、
    精算データ加工検証機能（１２２０）が、ＰＯＳ機器情報（３２００、キーボード／スキャナーインターフェース情報、ＰＯＳアプリケーションの操作順序、等）に従って、抽出された精算情報を加工するステップと、
    精算データ加工検証機能（１２２０）が、ＰＯＳの入力操作をエミュレーションして、キーボード／インターフェースから、ＰＯＳ（７１０）に入力するステップとを有し、
    ＰＯＳ機器情報（３２００）に対応するＰＯＳ（７１０）が精算できるようにする、
    ＰＯＳ ＩＦ エミュレータ（１２００）を利用したエミュレーション方法。
12. 携帯電話（３００）によって、商品に対応する商品タグ（１００）から商品情報（７６０）を取得し、１回以上の取得によって買物情報（４３０Ａ、４３０Ｂ）を作成し、その買物情報（４３０Ｂ）から精算情報（５８０）を抽出し、抽出された精算情報（５８１〜５８５を抽出、５８６を省く）を対象（５００からの出力）にして、
    精算データ加工検証機能（１２２０）が、ＰＯＳ機器情報（３２００、キーボード／スキャナーインターフェース情報、ＰＯＳアプリケーションの操作順序、等）に従って、抽出された精算情報を加工するプログラムコードと、
    精算データ加工検証機能（１２２０）が、ＰＯＳの入力操作をエミュレーションして、キーボード／インターフェースから、ＰＯＳ（７１０）に入力するプログラムコードとを有し、
    ＰＯＳ機器情報（３２００）に対応するＰＯＳ（７１０）が精算できるようにする、
    ＰＯＳ ＩＦ エミュレータ（１２００）に実行させるプログラム。

Images