WO2014141395A1 - 発注情報制御システム、方法、プログラム - Google Patents

Abstract

食品などには、原材料名やカロリーなど、様々な商品属性情報が記載されている。これらの情報と用いて、従来、店頭で、商品が顧客のアレルギ源を含むかを抽出する、さらに、顧客等のアレルゲン情報に示すアレルゲン物質を含まない代替商品の抽出を行っている。しかし、これらの技術では、当該店舗に在庫がある代替品しかユーザに提供出来ない。一方、小売企業側としては、店舗に並べきれないほどの種類の商品を入荷する購買力や倉庫を持っているため、店舗にある以上の商品を提示することは可能である。店舗にある以上の商品を提示し顧客が自発的に探索して買って行ってくれるのであれば、販売機会が増えるため、経済的なメリットが大きい。そこで、本願発明は、ユーザが商品情報を取得した店舗の店舗情報に応じた代替品情報を提供することを目的とする。

Description

発注情報制御システム、方法、プログラム

　本発明は、特定の制約条件に基づいて商品を購入する必要のあるユーザに対して、適切な商品提示を行うとともに発注を支援する発注情報制御システムに関する。

　近年、IT技術の進化に伴って、スマートホンやタブレット端末といった、小型でこれまでのパーソナルコンピュータとは異なるユーザインタフェースを備えた端末が、街中で利用されることが珍しくなくなってきている。これらの小型端末は、ほぼ常時ネットワークに接続されて利用され、ユーザがネットワーク経由でサーバとデータをやり取りする上での、簡単な入力端末であり、結果の表示出力端末であると言える。

　そのため、このような小型の端末は、様々なネットワークインタフェースを備えるようになってきている。一例を挙げれば、無線LAN、３Ｇネットワークとも呼ばれる携帯電話通信網、ＬＴＥ、近距離赤外線、非接触ＩＣカード、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などである。これら様々なネットワークは、大規模なものから小規模なものまで、遠距離から近距離まで、必要な送受信データ量や許容される電力使用量などによって使い分けられている。これらのネットワークインタフェースは、ネットワークの両端に情報処理装置が存在することを想定しているが、情報発信、情報受信のみを行えばよいアプリケーションも多くあり、それには別の技術が用いられることも多い。

　その一例としては、情報を記録・記憶する手段として、バーコードやＲＦＩＤが使用されており、バーコードリーダやＲＦＩDリーダと対で用いられる。先ほどの説明に対応付けるならば、バーコードやＲＦＩＤは、情報発信のみを行っており、バーコードリーダやＲＦＩＤリーダは、情報受信のみを行う。ＲＦＩＤは、内部に半導体回路と不揮発性メモリを備えるなど、単に印刷された画像パターンであるバーコードよりも技術的に進んでおり、ＲＦＩＤリーダで読むだけではなく、ＲＦＩＤライタで情報の書き換えが可能であることが多い（すべてのＲＦＩＤが書き換え可能なわけではなく、読取専用であることを特徴として訴求しているＲＦＩＤも世の中には存在する）。印刷方式のバーコードは、白黒のパターン印刷で実装することができるなど、取り扱いがしやすく、実績も多くあることから、商品管理におけるスタンダードの地位を占めている。

　特にＲＦＩＤは、半導体素子を記憶装置として搭載していることから、電子タグとも呼ばれる。ＲＦＩＤには、同一面積内にバーコード以上の情報量を記録することができるため、ＲＦＩＤを貼り付けた対象の属性情報を大量に持つことができる。ＲＦＩＤのサイズは、数ｍｍから数ｃｍなど、用途によりまちまちであるが、小売店で扱われている程度のサイズの商品に張り付けるためのＲＦＩＤであれば、小型のものであれば、１ｃｍ未満のものもある。すなわち、商品ごとにＲＦＩＤを取り付けることも、ＲＦＩD自体と取り付けに係るコストを考慮しなければ、可能である。ＲＦＩＤやバーコードには、容量の制限の範囲内で様々な情報を記録することが出来る。そのような情報の中には、商品の価格や、原材料の一部なども含まれ得る。

　一方、食物アレルギー患者は、自身が反応するアレルゲンの情報を知識として持っており、その情報を食品の原材料表記と照らし合わせて、問題が無い場合に、その商品を購入するというプロセスで買い物をしている。最初に考えられる解決方法は、アレルゲン情報と食品の原材料表記の情報をいずれも電子的に保持しておき、それらをコンピュータ上で比較して問題の有無を判別する方法である。

　特許文献１では、電子タグは食品ごとの原材料を含む商品情報を記憶し、ＩＣカードは顧客を登録のアレルゲン情報を含む顧客情報を保持し、読み取り装置は、商品情報と顧客情報とを読み取り、読み取った顧客等のアレルゲン情報と商品情報とを付き合わせを行い、原材料にアレルゲン物質を含むアレルゲン含有商品を抽出することが開示されている。また、商品情報に、各商品の商品ジャンルを含めることで、顧客等のアレルゲン情報に示すアレルゲン物質を含まない代替商品の抽出を行っている。具体的には、店頭にサーバと読み取り装置が設置され、読み取り装置と接続されたサーバは、代替商品検索手段を備え、代替商品検索手段は、読み取り装置が抽出したアレルゲン含有商品の商品ジャンルに応じて、商品情報ファイルから同一ジャンルの代替商品を検索する。これにより、顧客は代替商品の購入が容易となり、店舗側にとっても代替商品の購入可能性が高まるため、アレルゲン含有商品を取扱うことによる売り上げの減少を極力防止することが可能となることが開示されている一方、特許文献２では、商品発注・代替品表示Ｗｅｂサーバは、ユーザ端末が指定した商品の在庫が無い場合に、ユーザ端末に代替商品を提示して、ユーザ端末は、その代替品を発注する事ができるシステムが開示されている。

特開２００６－３０２０７６ 特開２００２－２４５３０２

しかし、特許文献１に記載の技術では、当該店舗に在庫がある代替品しかユーザに提供出来ない。一方、小売企業側としては、店舗に並べきれないほどの種類の商品を入荷する購買力や倉庫を持っているため、店舗にある以上の商品を提示することが可能である。店舗にある以上の商品を提示し顧客が自発的に探索して買って行ってくれるのであれば、販売機会が増えるため、経済的なメリットが大きい。そこで、本願発明は、ユーザが商品情報を取得した店舗の店舗情報に応じた代替品情報を提供することを目的とする。

　これらの課題を解決する手段として、本願のシステムは、ユーザ端末は、商品情報と店舗情報とを中央サーバに送信し、中央サーバは、前記受信した店舗情報に応じた代替商品情報を取得し、前記取得した代替商品情報を前記ユーザ端末に送信することを特徴とする。

　ユーザ端末が送信する店舗情報に応じた代替品情報を提供することができる。

本システムのネットワーク接続図 中央サーバおよびＤＢの構成 ユーザ端末の構成 ユーザ端末の外観 ユーザデータベース例 店舗位置データベース例 商品データベース例 商品提供時期データベース例 配達商品データベース例 購買フロー 全体システムのシーケンス図 ユーザ端末における情報表示例 ユーザ端末の動作フロー レジにおけるユーザ端末およびレジ端末の動作フロー１ レジにおけるユーザ端末およびレジ端末の動作フロー２ 中央サーバにおける商品情報、代替商品情報提供フロー 中央サーバにおける発注受付、倉庫編情報伝達フロー 中央サーバにおける店舗売上加算フロー 中央サーバにおける商品データベース作成フロー 中央サーバにおける商品データベース更新フロー 倉庫サーバにおける商品発注フロー 倉庫サーバにおける商品発送受注・発送フロー 商品の一般的な形状と記載情報 店舗における商品陳列棚および値札の例 ユーザ端末による商品陳列棚撮影例 ラインスキャンによるバーコード読取の例１ ラインスキャンによるバーコード読取の例２ パッケージの画像認識による商品識別

　本発明のシステムの実施例を示す。図１に示す通り、本実施例の発注情報制御システムは、ユーザ端末１０１、メーカＡレジ端末群１１３、メーカＢレジ端末群１１１、中央サーバ１０３、メーカＡサーバ１０５、メーカＢサーバ１０７、中央倉庫サーバ１０９、メーカA倉庫サーバ１１８、メーカB倉庫サーバ１２０、中央サーバ１０３に接続された中央－ＤＢ１０４、メーカＡサーバ１０５に接続されたメーカＡ－ＤＢ１０６、メーカＢサーバ１０７に接続されたメーカＢ－ＤＢ１０８、中央倉庫サーバ１０９に接続された中央倉庫－ＤＢ１１０、メーカA倉庫サーバ１１８に接続されたメーカA倉庫－ＤＢ１１９、メーカＢ倉庫サーバ１２０に接続されたメーカＢ倉庫－ＤＢ１２１さらにこれらを接続するインターネットワーク１０２、メーカＡネットワーク１１４、メーカＢネットワーク１１２、配送業者サーバ１２５から構成される。

　レジ端末は、各メーカサーバに独自のネットワークないしはインターネットを経由して接続されている。図１では、メーカAが管理する（たとえば、メーカAのある店舗に設置されている）レジ端末A1およびA2（１１３）は、独自のネットワーク１１４を通じてメーカAサーバ１０５に接続されており、レジ端末はこれを経由してメーカA－ＤＢ１０６に記録されている情報にアクセスすることが出来る。

　独自のネットワー１１４は、ここではインターネット１０２と別のものであるかのように記載しているが、然るべきセキュリティ構成（Virtual Private Networkとするなど）をすることで、インターネット１０２とデータ伝送網の少なくとも一部を共用にしても良い。

　レジ端末、独自ネットワーク、サーバ、DBは、メーカごとに管理していることが通常であり、図１では、メーカBのシステム１１７についても、メーカAのシステム１１６と同様の構成がされている例を示している。ここで、メーカＡとメーカＢに限定して記載をしたが、メーカサーバの数は制限されておらず、いくつのメーカと接続されていても良い。また、データベースについても、各サーバにつきひとつを記載しているが、これは、サーバに内蔵されていても良いし、ひとつのサーバに対して複数のデータベースを持っていても良い。

　メーカＡサーバ、及び、メーカＡ－ＤＢは小売業者Ａが管理するものであり、中央サーバは当該サービスを提供するサービス提供業者が管理する。中央倉庫サーバと中央倉庫DBは、サービス提供業者が統合的に管理しても良い。しかし、中央サーバおよび中央―DBのサービス提供者と、倉庫サーバおよび倉庫DBのサービス提供者が異なっても良い。両者が異なる場合は、ネットワーク１０２が到達可能な範囲で両者の物理的な距離は問題にはならない。また、中央倉庫サーバ１０９および中央倉庫DB１１０は、物品現物を入出庫する倉庫拠点に置かれている必要も必ずしもないため、前記の中央サーバシステム（１０３および１０４）、倉庫サーバシステム（１０９および１１０）、倉庫拠点は、それぞれ設置場所にある程度の自由度を有している。一方、これらを統合的に管理することによって、全体的な入出荷を最適化することができるため、統合することによるメリットは大きい。

　中央サーバ１０３は、ユーザ端末１０１からネットワーク１０２を介して受信したデータを元に、中央－ＤＢ１０４から情報を抽出して、ユーザ端末に情報を送信する。中央サーバは、メーカＡサーバやメーカＢサーバとの通信を通じて、自身の管理している中央―ＤＢを作成・更新する。メーカＡサーバやメーカＢサーバは、それぞれが管轄に含まれる倉庫サーバから倉庫－ＤＢ情報を取得して、これらを合わせて中央サーバに送信する。もしくは、中央サーバは直接各メーカ倉庫サーバに問い合わせを行う構成としても良い。中央サーバは、中央倉庫サーバにも同様にアクセスして、情報を取得する。この更新作業は、中央サーバが定期的にメーカサーバに問合せのアクセスをすることで、更新情報がある場合にメーカサーバからデータを受信するように実装しても良いし、メーカサーバが、更新情報がある場合に自発的に中央サーバに情報更新の報告をする形をとっても良い。そのように構成することで、中央－ＤＢには、常に最新の情報が保持されるようになる。ただし、データベース上の情報を最新に保つために、必ずしも中央－ＤＢを最新に保つ必要はなく、毎回メーカサーバに最新情報を問い合わせても、ネットワークの遅延が大して問題ではない場合は、同様の効果を得ることができる。なお、中央サーバは、ネットワーク１０２上にただひとつ存在するように記載をしているが、必ずしもひとつに限定されるわけではなく、２つ以上（中央サーバ群や中央－ＤＢ群）存在しても良い。その場合は、互いに独立に動作する形となるが、メーカＡやメーカＢなどは、その中央サーバ群から排他的にアクセスされる共通のサーバという形態となる。

　配送業者サーバ１２５は、インターネットワーク１０２を介して接続されている。中央サーバ、中央倉庫サーバ、メーカAサーバ、メーカA倉庫サーバ、メーカBサーバ、メーカB倉庫サーバはいずれも、ユーザへの配送業務が発生する場合に、メーカAネットワーク１１４やメーカBネットワーク１１２やインターネットワーク１０２を介して、配送業者サーバにアクセスし、配送手配を行うことができる。もちろん、メーカごとに異なる配送業者に配送手配を行うことが考えられ、その場合は、必ずしも他メーカ等がアクセスできない場所に当該配送業者サーバが接続されることもある。

　各倉庫サーバは、倉庫にストックしている商品のデータを保持する倉庫－ＤＢを持ち、中央－ＤＢやメーカＡ－ＤＢやメーカＢ－ＤＢには、その管轄内の倉庫－ＤＢからストック情報も反映している。また、少なくとも中央倉庫サーバは、配達商品データベースを保持する。

　図２に、中央サーバ１０３および中央－ＤＢ１０４のより詳細の構成を示す。図２において、中央サーバ２０２は、ネットワークインターフェース２２０を通じて、インターネット２０１やイントラネット２０３に接続されている。インターネットとイントラネットの間には、ファイアウォールやゲートウェイと呼ばれるサーバが設置されているのが通常であるが、その構成は本発明の本質に影響を与えないため、ここでは、その記載を省略している。中央サーバ内には、ネットワークインターフェース２２０を通じて送られてきたデータを内部で配信するための内部バス２２４があり、この内部バスは、メモリ２２１、ＣＰＵ２２２、入力インターフェース２２３、ハードディスクドライブ２２５、表示装置２２６に接続されている。メモリ２１１には、中央サーバ処理プログラムが格納され、以下で説明する中央サーバの処理は、ＣＰＵ２２２が中央サーバ処理プログラムを読みだし実行することで実現される。各コンポーネントに小型のＣＰＵが搭載されていることがあるが、ここでは、ＣＰＵ２２２が、中央サーバの全体挙動をつかさどる中央演算ユニットであるとして、説明を行う。ＣＰＵは、自身のネットワークインターフェース２２０に、インターネット２０１を通じてユーザ端末１０１が接続するのを待つ。ひとたびユーザ端末からのアクセスを受けると、受信した情報を元に、自身のデータベースである中央－ＤＢにアクセスして、必要な情報を取り出して、ユーザ端末に返信する。ここで、中央－ＤＢの実体は、ＣＰＵが別プロセスで実行しているデータベースインターフェースとデータを格納するデータファイルであって、その格納データは、ＨＤＤ２２５ないし、ネットワークストレージ２０４などに置かれる。ここで、ＣＰＵが動作に使用するプログラムは、ＨＤＤ２２５に格納されており、また、メモリ２２１にその一部が展開されている。データベースについても同様で、常にＨＤＤやネットワークストレージに格納されているデータのみにアクセスするわけではなく、高速化のために、データの一部をメモリ上に保持することもある。入力インターフェース２２３や表示装置２２６は、サーバの管理者とのやり取りのために使用されるもので、そのようなやり取りが必要ない場合は、これらを少なくとも専用には備えている必要はない。近年のラックマウント型のサーバであれば、入力インターフェースや表示装置を、同じラック内に納められた複数のサーバ間で共有する仕組みを備えているので、そのような構成であっても良い。たとえば、図２では、中央サーバとネットワークストレージが、イントラネットを介して接続されており、独立に存在しているが、同一のラックに収められていても問題は無い。

　ネットワークストレージ２０４は、ここでは、イントラネット２０３を介して、中央サーバに接続されている。一般的に、ネットワークストレージは、ネットワークインターフェース２４１を通じてネットワークに接続されたハードディスクドライブ２４４が機能の主体である。しかし、実際には、ＨＤＤが独自に外部とのデータ通信を行うわけではなく、内部バス２４２を通じて接続されたＣＰＵ２４５やメモリ２４３を同時に備えている。つまり、ＨＤＤから情報を読み出したりＨＤＤへ情報を書き込んだりするのは、ＣＰＵの役割であり、その一時記憶としてメモリが使用される。ＣＰＵが動作するためのプログラムは、ＨＤＤ２４４の一部を割り当てることが多いが、場合によっては、独自にＲＯＭやフラッシュメモリなどの記憶領域を持ち、そちらから読みだすようにすることもある。ネットワークストレージは、イントラネット内にひとつというケースは少なく、むしろ複数台がイントラネット２０３に接続されるのが普通である。複数あるネットワークストレージに対してＤＢのうちどの部分を割り当てるかは、中央サーバのＣＰＵ２２２で判断され使用されるのが通常であるが、高機能なネットワークストレージになると、代表となるネットワークストレージが一台あり、その他のネットワークストレージ群が、あたかも一台の巨大なストレージであるかのようなアクセスインターフェースを提供するものもある。それを中央サーバ上に仮想的に提供するようなソフトウェアを使用しても類似の効果が得られる。なお、中央サーバやネットワークストレージで示した各コンポーネントの数は、それぞれ一つである場合を図示したが、近年、同一のパッケージ内に複数のコンポーネントを搭載するケースもあり、特にＨＤＤやネットワークインターフェースは、処理の分散やバックアップの目的で複数備えることも多くなっている。

　中央サーバは、ユーザデーベース、店舗位置データベース、商品データベースをメモリ２２１で保持する。

　ここでは、中央サーバを例として説明をしたが、メーカＡサーバおよびメーカＡ－ＤＢ、倉庫サーバ、メーカＢサーバおよびメーカＢ－ＤＢ、倉庫－ＤＢなど、ほぼ同様の構成となり、主な相違は、サーバ上で動作しているソフトウェアの性質である。すなわち、中央サーバは、ユーザ端末１０１とのデータのやり取りが主な処理であるのに対して、メーカサーバ、倉庫サーバは、中央サーバとのデータのやり取りが主な処理であるから、同時接続数や、一回の通信におけるデータ通信量などが異なる。そのため、搭載するべきＣＰＵ２２２のコア数やメモリ２２１の容量が異なるのが通常である。

　図３に、ユーザ端末３０２の構成を示す。ユーザ端末は、ネットワークインターフェース３２０を通じて、インターネット３０１に接続されている。ここで、ネットワークインターフェース３２０は、必ずしも直接インターネットに接続される有線ＬＡＮや無線ＬＡＮである必要はなく、携帯電話の通信網を通じてキャリアのサーバを経由してインターネットに接続されていてもよいし、その他の通信手段で接続されたその他のコンピュータを介してインターネットに接続されていても良い。さらにいえば、中央サーバやユーザ端末が接続されている先が必ずしもインターネットである必要はなく、両者が問題なく情報を交換できさせすればよい。

　ユーザ端末は、一般的なコンピュータの形態をとることが多いため、ここではそのような構成として記載している。すなわち、ユーザ端末３０２は、内部バス３２５で接続された、ネットワークインターフェース３２０、メモリ３２２、ＣＰＵ３２３、入力インターフェース３２４、フラッシュメモリ３２６、表示装置３２７を搭載する。メモリ３２２はＳＤＲＡＭなどの揮発性メモリを想定しているが、近年では、高速な書き換えが可能でかつ書き換え耐性の高い不揮発性メモリも開発されており、そのようなメモリを使用しても良い。特にユーザ端末のように電源のＯＮ／ＯＦＦが多いことが想定される端末では、不揮発性メモリの利点も大きい。メモリには、ユーザ端末のOSやアプリケーションソフトウェアの一部が展開されていたり、一時的な情報などが記録される。フラッシュメモリ３２６は、小型のモバイル端末ではＨＤＤよりも広く使われている。これは、携帯端末である以上、常に振動や揺れにさらされるリスクがあり、ＨＤＤのような機械的に動作する媒体をできるだけ避けたいという要求からきている。フラッシュメモリには、ユーザ端末を稼動させるためのOSのほか、本願発明の機能を実現するアプリケーションソフトウェアなどが記録されている。ＣＰＵは、小型化と低消費電力化の成果で、マルチコアの製品でさえ、スマートホンなどの小型端末にも使用されており、グラフィクス処理などが得意なＧＰＵでさえ、利用が可能になってきている。そのため、表示装置３２７に表示される情報もグラフィカルなものが主流になってきており、ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）など三次元空間処理さえも使われることがある。入力インターフェース３２４としては、独自のキーパッドを備えるものもあるが、表示装置３２７に重ねた感圧式や静電容量方式のタッチ入力方式が想定される。本実施例では、ユーザが、商品を選択する際に、画面上に表示された商品を指先等で選択し、画面上に表示された発注ボタンを指先等で押すことを想定している。キーパッド式でも同様の入力操作は可能ではあるが、二次元的な情報をキーパッドで入力するには、複数のステップが必要となり、入力により多くの時間を要する。　前記したように、本実施例では、ユーザ端末として、スマートホンを想定しているが、タブレット型のコンピュータであっても同様の装置構成であるし、一般的なパーソナルコンピュータもタッチ入力方式が採用されつつあり、トラックパッドでタッチパネル相当の二次元的な操作も可能なので、本実施例を同様に適用することができる。もちろん、専用に設計されたユーザ端末でもよく、そのような場合は、ＣＰＵなど一部のコンポーネントが、ＦＰＧA等で置き換えられる可能性もある。

　図４に本実施例のユーザ端末の外観を示す。ユーザ端末４０１は、表示装置とタッチ入力インターフェースが一体となった入出力部４０４と、電源やコマンド送信、コマンドキャンセルなどプログラムの状態によって機能が変化するボタン４０３と、画像撮影用前面カメラ４０２と、画像撮影用背面カメラ４０５と画像撮影時の光源となるライト４０６を備えている。

　次に、各装置が備えるデータベースについて説明する。

　中央サーバが保持するユーザデータベースの内容例を図５に示す。各ユーザについてユーザの属性情報、すなわち、ユーザＩＤやパスワード、氏名、住所（配達先と異なる場合は、複数の住所が記載されても良い）、電話番号などの連絡先、ユーザＩＤの失効状態などが記録される。配達条件として、ユーザが指定する配達の条件を記録する。さらに、ユーザデータベースは、ユーザごとの商品制約情報を記録する。商品制約情報とは、例えば、特定原材料を含む商品は不可あるいは可である旨の情報、カロリー条件情報である。

　中央サーバが保持する店舗位置データベースの内容例を図６に示す。店舗位置データベースは、位置を識別する位置コード、店舗を識別する店舗コード、登録されている情報の最終確認日時、店舗名、店舗の住所、店舗の電話・ＦＡＸ、該店舗の情報が有効か無効かを示す有効情報を保持する。中央サーバはユーザ端末から送信される店舗情報と該店舗位置データベースとに基づいて、店舗識別情報、すなわち、店舗コードを特定する。ユーザ端末から送信される店舗情報は、ユーザの現在位置でもよいが、必ずしもユーザの現在位置である必要はなく、店舗を特定することができればよい。例えば、入店ゲートを通過した際の、通過ゲート番号や通過時間なども利用可能である。また、店舗の特定は、ユーザの商品情報の取得と必ずしも同タイミングである必要は無いので、後に店舗売上げやリベート発行のタイミングまでに特定されるように、前記の入店ゲートを通過した際の情報に加えて、退店ゲートを通過した際のゲート番号や通過時間などを使用しても良い。また、ユーザ端末が、ユーザ端末のネットワークインタフェースの状態を読み取って、画像の撮影時点などのタイミングで接続していたか接続可能範囲にあった無線ネットワークのアクセスポイントのＭＡＣアドレスのリストなどとしても良い。ＭＡＣアドレスは、全てのアクセスポイントに異なる番号が割り当てられているため、アクセスポイントの位置とＭＡＣアドレスの対応表を予め用意しておけば、ユーザ端末の現在の位置を特定することができる。

　図７に中央サーバが保持する商品データベースの一例を示す。商品データベースは、商品を識別する商品コード、商品を保持する店舗の店舗コード、該情報が登録された日時、商品の属性情報、すなわち、商品の商品名、商品のカテゴリー、商品の原材料リスト、商品のカロリーを保持する。また、商品画像、在庫数を保持してもよい。商品コードとして、ここではＪＡＮコードを想定した番号を記載している。ＪＡＮコードは、商品ごとにユニークな番号であることが期待されるが、限られたコード体系をレンタルという形で運用しているため、流通時期が大きく異なる場合は、異なる商品に同一のコードが割り当てられることもあり得る。それをユニークな番号にするため、ここでは、各商品コードにはそれが有効である日時の情報を併せて記録している。この例では、ある一つのタイミングとしてコードを割り当てた日を記載するような構成としているが、同コードが有効である期間を記録しても良い。各商品について、商品名やカテゴリー、原材料リスト、カロリー、商品画像などが記録されており、必ずしもこの例に記載したものに限定されず、様々な属性情報を記録してよい。また、図７の下図では、プライベートコードを使用する場合の例記載している。ここでは番号が０２から始まるものをプライベートコードに割り当てている。プライベートコードは、店舗ごとに自由に設計使用可能な体系である。　中央サーバ、メーカAサーバ、メーカBサーバ等が保持する商品提供時期データベースの内容例を図８に示す。商品提供時期データベースは、店舗を識別する店舗コード、商品を識別する商品コード、データベースの更新日時、当該店舗が当該商品を提供できる時期およびその際の提供場所についての情報を含む。図８の例では、複数の店舗コードを含んでいる。これは、中央サーバなどのように複数の店舗を検索対象とするサーバが保持するデータベースの特徴である。たとえば、あるひとつの店舗のサーバにおいては、必ずしも複数の店舗コードの商品情報を保持する必要はないため、店舗コードの列を保持しないことも可能である。一方、あるひとつの店舗であっても、それを代表店舗として位置付け、やはり複数の店舗コードの商品情報を保持するようにしてもよい。必ずしも店舗すべてにアクセスする必要が無いように、メーカサーバにおいて一部または全部の最新データを保持するようにしても良い。本データベースには、さらに、各店舗各商品の提供時期の情報が記録されている。また、その際に可能な提供場所も必要に応じて記録してもよい。本例では、「即」と記載されており、提供場所が「店頭」となっている商品は、すでに店頭に陳列されている商品のことを意味している。提供場所が「バックヤード」となっている商品は、店舗のバックヤードに在庫があるが、店頭には陳列されていないため、店舗担当者等に問い合わせることで入手が可能であることを意味している。提供時期が後日となっているものについては、それぞれ倉庫から直送される場合や、店頭で受け取ることもできるという選択肢が与えられる可能性がある。提供時期が「不可」となっている商品は、何らかの理由で提供ができない商品を意味している。そのような理由としては、生産中止となった商品であったり、生産が追い付かずに入手が困難な商品であるなどが想定される。

　図９に、中央倉庫サーバが保持する配達商品データベースの内容例を示す。本データベースには、ユーザＩＤ，配達条件、現時点で配達予約されている配達スタック、状況が記録されている。ユーザＩＤは、ユーザを同定するためのユニークなコード番号である。このユーザＩＤに関連して、中央サーバが保持するユーザデータベースが管理されており、ユーザＩＤを元に検索することで、ユーザの名前や配達先などの一連の情報を得ることができる。たとえば、図２４は２００１年６月５日１６時時点でのデータベースの状況を示しているとする。ユーザ0000001が、毎日１５時を締切として、その時点でスタックされている商品を配達するという指定をしている場合は、そのように配達が手配される。発送開始条件の判定のため、次回の締め切りが具体的に記載されていればなお良く、ここでは、２００１年６月６日１５時が次回の締め切りであるということが記載されている。この時点では、配達品は受付中であることを、状況カラムから読み取ることができる。その他のエントリについても同様である。特にユーザＩＤ0000003の行は、配達が完了しているエントリの記載例を示している。状況カラムには、すでに配達が完了していることが記載されており、その日時については、配達条件カラムに記録されている。このように、配達完了した場合でもログとして残しておくことで、ユーザが将来問合せを行うこともできるし、サービス提供側が、売れ筋商品などの解析に情報を利用することもできるようになる。

　図１０に、ユーザが商品情報の参照を行い、商品を受領するまでの、一連の動作を各コンポーネント間の関係を含めて示す。まず、ユーザは、スマートホンなどのユーザ端末にアプリケーションをインストールする。ここでは、アプリケーションを中央サーバから受信しているが、必ずしもそれに限らず、インターネットのアプリ配信サイトなどから受信しても良い。ユーザは、アプリをインストールし、ユーザの属性情報を入力し、その情報は、中央サーバに送信される。次に、ユーザは店舗（ここでは実店舗Ａ）で、先に述べたような方法で商品コードを取得し、ユーザＩＤ，画像撮影位置の情報とともに中央サーバに送る。中央サーバは、それに対して、選択商品のＯＫ／ＮＧ情報や代替品情報をユーザ端末に送信し、ユーザはそれを元に、購入方法の判断を行う。

　＜購入方法１＞
　たとえば、商品を店舗でそのまま購入する場合は、ここでは実店舗Ａにおいてレジ端末を通して購入・支払を行い、商品を持ち帰る。

　＜購入方法２＞
　一方、店頭在庫が無いものを後日受取り手配する場合は、実店舗Ａに対して、その手続きを行い、実店舗ＡはメーカＡ倉庫に対して配送手配を行う。倉庫からユーザに直接配送する場合は、配送完了後に実店舗Ａに配達完了情報が伝えられる。

　＜購入方法３＞
　ユーザが、商品をメーカを介さずサービス提供業者のサーバを経由して購入することを選択した場合は、ユーザ端末が、ユーザＩＤ、発注商品、位置情報を中央サーバに送付する。中央サーバは、図２２に示すような店舗位置データベースを持っており、位置情報（ここでは位置コードと呼ぶ）に対応づく店舗コードや店舗情報を読み取る。中央サーバは、中央倉庫に配達商品や配達先、店舗情報等の情報を送信し、倉庫は所定のタイミングで商品を集約してユーザに配送する。配達が完了すれば、中央倉庫は中央サーバに配達完了情報を送信する。配達完了情報を受けて、中央サーバは、ユーザへの課金を確定し、店舗への売上計上を行う。また、ユーザに対して所定の間隔で、購入履歴情報を中央サーバから送付しても良く、ユーザが特定されない程度に情報を撹拌することで、実店舗Ａなどに対して、一般消費トレンド情報などを提供することもできる。

　購入方法２及び購入方法３では、ユーザが手元の端末に引き続いて情報を入力することで購入が完了するため、レジ端末での処理待ち行列に並ぶ必要が無く、また店舗Aとの手続き窓口に出向く必要が無い。

　図１１に、上記サービスを実現するためにシステム内でやりとりされる情報を説明するシーケンス図を示す。メーカＡサーバ105は実店舗Ａに設置されているとする。まず、ユーザ端末101は、アプリケーションをインストールする（2001、2002、2003）。図１１では、アプリケーションを中央サーバから受信しているが、必ずしもそれに限らず、インターネットのアプリ配信サイトなどから受信しても良い。ユーザ端末は、ユーザから入力されたユーザの属性情報を中央サーバに送信する（2004）。中央サーバは、受信したユーザの属性情報をユーザデータベースに登録する。次に、ユーザ端末は、店舗（ここでは実店舗Ａ）で、商品の商品情報（例えば商品コード）を取得し、ユーザＩＤ，店舗情報（例えば画像撮影位置の位置コード）とともにユーザが選択した商品（ユーザ選択商品）の商品情報を中央サーバに送る（2005）。中央サーバは、受信したユーザ選択商品の商品情報（例えば商品コード）、ユーザＩＤ，店舗情報、保持するデータベースと、に基づいて、選択商品のＯＫ／ＮＧ情報や代替商品情報を取得する（2006）。代替商品情報は、代替商品の商品コードを少なくとも含む。中央サーバは、取得した選択商品のＯＫ／ＮＧ情報や代替品情報をユーザ端末に送信する（2007）。ユーザ端末は、受信した情報を表示する（2007）。

　図１２に、中央サーバから送付された商品情報や代替商品情報がユーザ端末にどのように表示されるかについて一例を記載する。ユーザ端末の入出力部２６０１には、現在の撮影画像ないし中央サーバに情報送付した際の画像や最後に撮影した画像などを背景として表示しており、その前面に商品の詳細商品属性情報２６０２として、カロリーやアレルゲン情報、価格などを表示している。また、同じ画面の右上には、代替商品情報２６０４が表示されている。右下に表示されているのは、ユーザが必ずしも持ち帰りで購入する必要が無いと判断した商品を、あとで自宅などに配達することを指定するためのボタン２６０３である。ボタン２６０３が押されると、アプリケーションは、購入方法２及び３で商品を購入するための画面を表示させる。（ここでは、ユーザがアプリケーションにユーザＩＤを登録した際に、併せて登録した商品属性情報に乳アレルギーという情報が含まれていた場合に、ユーザが指定した商品には乳成分が含まれていることを注意喚起する表示がなされている。この場合、代替商品としては、ユーザが購入し得ると判断される商品が幾つか提示される。ここでは、二つの商品が提示されている。ユーザは、この情報に基づいて代替商品の詳細を見たいと考えた場合、代替商品情報表示部２６０４の一つの商品について、入出力部２６０１の当該部分にタッチすることで、商品情報表示部２６０５の記載がその商品に変化する。本図では、代替商品をユーザが選択したことを見やすくするために、画面右上の代替商品情報表示部の当該商品画像を消去しているが、ここに、当初ユーザが指定した商品を入れ替わりに表示してもよい。そのようにすることで、ユーザがやはり元の商品を選択したいと考えた場合に速やかに元の画面状態に戻すことができる。なお、本図の例では、商品の価格が、「あとで価格」として、店舗での値札の価格よりも安く提示されている。これは、店頭陳列よりも倉庫保管のほうが管理コストが低いことから、値引きが可能であることを想定しての記載である。配送料を無料にする代わりに、店舗と同一価格とするなど、ここでの価格の提示方法にはさまざまなバリエーションが考えられる。

　ユーザはユーザ端末に提示される選択商品のＯＫ／ＮＧ情報や代替商品情報を元に、選択した商品が商品制約情報を満たすかを確認できる。また商品制約情報を満たす代替商品の情報を知ることができる。また、選択した商品や代替商品の在庫状況（店頭に在庫があるか、メーカの倉庫に在庫があるか、サービス提供業者の管理する中央倉庫に在庫があるか）、あるいは商品提供時期を知ることが出来る。これにより、ユーザは、下記の３つの購入方法のうちから購入方法を選択することができる。

　小売業者は、本システムで提供されるサービスに加入すると、店頭に在庫がある商品の中からユーザに商品制約情報を満たす代替商品を提示することが出来る。また、ユーザが先約した商品または代替商品が店頭に在庫がなく倉庫に在庫がある場合でも、ユーザに簡易に当該小売業者を介して商品を購入するよう促すことが出来る。

　図２７の説明に戻る。

　＜購入方法１＞
　たとえば、ユーザが商品を店舗で購入する場合は、ユーザ端末は、レジ端末に対してユーザＩＤを送付する。レジ端末は、ユーザＩＤを受領後、ユーザが購入した商品情報一式を店舗情報と共に中央サーバに送付して処理を終了する（購入方法１）。このように構成することで、中央サーバを通じて発注されなかった商品についても、中央サーバは、ユーザごとに購入品目録を作成することができる。このことのメリットは、ユーザが将来、一定の期間内に行った買い物の一式の金額を家計簿として記録したいと考えた場合に、中央サーバにアクセスすることで、必要な情報を得ることができるということや、後日、過去に購入した商品を本システムで発注したいと考えたときに、履歴情報から同商品を検索することができるといった効果が挙げられる。

　＜購入方法２＞
　一方、ユーザが店頭に在庫が無くメーカ倉庫に在庫がある商品を後日受取り手配する場合は、ユーザ端末は、ユーザからの入力を受け付け、メーカＡサーバ105に、倉庫品・後配購入手配要求を送信する（2007）。メーカＡサーバ105は、メーカ倉庫サーバに対して配送手配要求を送信する（2008a）。メーカ倉庫サーバは、配信業者サーバに配送手配要求を送信する（3008b）。配達業者は、配送手配要求に基づいて、票品をユーザに配送する。メーカ倉庫からユーザに直接商品を配送する場合は、メーカー倉庫サーバは、配送完了後にメーカＡサーバ配達完了情報を送信する（2009）。配達完了情報は、配達先のユーザID、配達条件、配達品リスト、配達完了日時、決裁方法などを含む。最低限必要な情報は、ユーザIDと配達完了の旨を意味するメッセージであるが、後の確認のために想定していた配達条件や配達（予定）品リスト、配達完了日時などを含むことには保全の意味でも有用である。また、決済手段が必ずしも確定していない後払いの場合は、配達時の現金支払いを行っても良いしクレジット払いを行っても良いため、支払いがどのような状況でどのような方法によって行われたかを記録することが望ましい。配達後に強制的にクレジット決裁が執行されるなどの場合は、必ずしも決裁に関する情報を記録しないことも想定される。これにより、ユーザは、店頭にないユーザ選択商品または代替商品を当該店舗を介して購入することが出来る。また、店舗は、店頭に在庫がなく倉庫に在庫がある商品をユーザに提供することが出来る。

　＜購入方法３＞
　また、ユーザが、実店舗を介さずに商品を購入することを選択した場合は、ユーザ端末は、ユーザからの入力を受け付け、ユーザＩＤ、発注商品、店舗情報を中央サーバに送付する（2010）。中央サーバは、受信した店舗情報に基づいて図２２に示す店舗位置データベースを検索し、店舗情報（ここでは位置コードと呼ぶ）に対応づく店舗コードなどを含む店舗識別情報を特定する。中央サーバは、中央倉庫サーバに配達商品や配達先、店舗識別情報を含む情報を送信し（2011a）、中央倉庫サーバは、配達業者サーバに配達商品や配達先、店舗識別情報等の情報を送信する(2011b)。ユーザねほ商品配達が完了すれば、配信業者サーバは中央倉庫サーバに配達完了情報を送信し（2012a）、中央倉庫サーバは、中央サーバに配達完了情報を送信する（2012b）。配達完了情報を受けて、中央サーバは、ユーザ端末に支払情報確定通知を送信する（2013）。中央サーバは、特定した店舗識別情報に基づいて対応するメーカーサーバに売上計上情報を送信する（2014）。また、中央サーバは、ユーザ端末に対して所定の間隔で、購入履歴情報を送信してもよい（2015）。中央サーバは、ユーザが特定されない程度に情報を撹拌し、メーカサーバに、一般消費トレンド情報を送信しても良い（2016）。これにより、ユーザは店頭に在庫がない商品、さらには来店した小売業者の倉庫に在庫がない代替商品を購入することが出来る。また、小売業者は、サービスを導入することで、店頭や倉庫に在庫がない商品、あるいは取り扱いのない商品についても、サービス業者から利益を得ることができる。

　提示した代替商品をその場で発注可能とし、商品をユーザが指定したタイミングで発送することで、ユーザは店舗に足を運ぶことで、必ず何らかの商品を購入することができるようになる。さらに、本願のシステムは、ユーザがスマートホンなどのインターネットに直接アクセスすることのできる移動端末を使用してアクセスすることで、各店舗のサーバを介する必要がなくなるため、店舗を選ばず、企業レベルでのシステム導入を迅速に行うことができる。一方で、店舗を介さずに前記の発注ができるので、店舗ごとの売り上げの把握が困難になる。このことは、マーケティング情報の収集の点で、不利である。そこで、本願のシステムでは、ユーザ端末が商品情報を送信する際に、ユーザが商品情報を取得した店舗を識別する店舗情報を中央サーバに併せて送信する。店舗情報は、先に述べたように、必ずしもユーザの現在位置である必要はなく、例えば、入店ゲートを通過した際の通過ゲート番号や通過時間、前記の入店ゲートを通過した際の情報に加えて、退店ゲートを通過した際のゲート番号や通過時間などを使用しても良い。もちろん、店舗情報は、マーケティング情報の収集に留まらず、商品の売上店舗の特定、すなわち商品販売に対する売上計上を行う店舗の選択にも使用することができる。本システムを通じた発注はすべて、店舗の売上として、各店舗にはリベートを提供するといった運用方法も可能である。各店舗への利益配分が可能となることで、システム運営上の協力を得やすくなるという効果もある。

　本明細書では、ユーザの商品制約情報として、食物アレルギーを想定して説明を行ったが、必ずしも食物アレルギーに限られるわけではない。たとえば、特定のメーカの製品であることや、特定の製造方法で製造されていることや、特定の価格以上ないし価格未満であることや、特定のユーザ層の購入割合が高いことや、特定のカロリー未満であることや、特定の原材料を含むことや、特定の種類数の原材料しか使用していないことや、特定の時期にのみ販売されていることなど、ユーザの嗜好に応じて様々に設定され得るものである。

　以下では、フローチャートを用いて、各装置の動作の流れを説明する。

　次に各装置の処理フローを説明する。

　図１３に、ユーザ端末の動作を記載する。ユーザ端末は、最初にアプリケーションをダウンロードし、自身の記憶装置に記録する（Ｓ1002）。ダウンロードしたアプリケーションは、インストール作業を行うことで、ユーザ端末で使用することができるようになる（Ｓ1003）。これは、ユーザ端末が、スマートホンのような、オペレーティングシステムを搭載しており、後付けでアプリケーションを追加できるような構成であることを想定している。しかし、ユーザ端末は、あらかじめ設定を済ませた専用端末であっても良く、その場合は、前記操作は、メーカの製造ラインなどで実施されることになる。以下では、スマートホンを想定して説明する。

　ユーザ端末がアプリケーションをインストールする際、もしくは初回の起動時などに、アプリケーションは、ユーザにユーザ属性情報の設定を求める画面を表示する（Ｓ1004）。ユーザ属性情報とは、例えば、ユーザＩＤの入力・選択、商品選別の条件である商品制約情報（特定原材料を含む食品を除外するなどの条件）、商品をあとで配送するという形で購入する場合の商品送付先住所や名前、決済に使用するクレジットカード、電子マネーなどの情報、配達するタイミングに関する条件などである。アプリケーションは、入力されたユーザ属性情報を中央サーバに送信する。以上を本アプリケーションを実際に使用・運用する前の初期設定として行う。

　初期設定後は、ユーザ端末は任意のタイミングでアプリケーションを起動し、アプリケーションは、商品コードの取得や店舗情報の取得を行い（Ｓ1005）、ユーザＩＤなどユーザを一意に特定する情報と共に中央サーバに取得した商品コード及び店舗情報を送付する（Ｓ1006）。その結果、アプリケーションは、中央サーバから商品詳細や代替商品の情報を提示情報として取得し（Ｓ1007）、ユーザ端末上に表示する。ユーザは、この情報に基づいて、商品を本システムを通して発注するか、情報を参考に店頭購入の上持ち帰るかを選択する（Ｓ1008）。購入方法３で商品を発注することが選択された場合、アプリケーションは、ユーザＩＤ、商品コード、店舗情報などを中央サーバに送付する（Ｓ1009）。ユーザが店頭で購入する購入方法１を選択した場合は、アプリケーションは、特段の処理は発生しない。アプリケーションは任意のタイミングで終了することができる、起動した状態で次の商品コードの取り込みを引き続き行うこともできる。なお、発注の際に中央サーバに送る情報は、ここでは、ユーザＩＤ，商品コード、店舗情報としたが、一部の情報は、中央サーバとのセッションの中で情報を保持しておいても良く、その場合は、あらためて送付する必要はなくなる。

　図１４に、ユーザが購入方法１を選択した場合のレジにおけるユーザ端末の動作と、レジの動作について示す。スマートホンは、アプリケーションを起動して（Ｓ1101）、レジ端末に対してユーザＩＤを送付する（Ｓ1102）。これは、現在、店頭購入処理している商品内容とユーザＩＤとを中央サーバ上でひもづけるために行う処理である。一方、レジ端末は、ユーザＩＤを受領後（Ｓ1105）、ユーザが購入した商品情報一式を店舗情報と共に中央サーバに送付して処理を終了する（Ｓ1106、Ｓ1107）。このように構成することで、本システムを通じて発注されなかった商品についても、ユーザごとに購入品目録を作成することができる。このことのメリットは、ユーザが将来、一定の期間内に行った買い物の一式の金額を家計簿として記録したいと考えた場合に、中央サーバにアクセスすることで、必要な情報を得ることができるということや、後日、過去に購入した商品を本システムで発注したいと考えたときに、履歴情報から同商品を検索することができるといったことが挙げられる。

　図１５は、図１４とは異なる動作パターンである。図１５の例では、ユーザ端末は、ユーザＩＤをレジ端末に送付後（Ｓ1202）、レジ端末から購入商品情報や店舗情報を受け取る（Ｓ1203）。その後、ユーザ端末は、中央サーバにユーザＩＤとともに購入商品情報や店舗情報を送付する（Ｓ1204）。レジ端末は、ユーザＩＤを受信後（Ｓ1207）、購入商品情報や店舗情報をユーザ端末に送信する（Ｓ1208）。この際に、ユーザＩＤは、レジ端末が情報を送付する際に相手先を間違えないように認証用コードとして用いられる。ユーザ端末とレジ端末が有線や十分に近距離でしか成立しない通信路で情報を授受する場合は、必ずしもユーザＩＤのやり取りはここでは必要はない。

　図１４の例では、レジ端末に中央サーバとの情報やり取りのための通信路を用意して、通信用のアプリケーションを搭載する必要があるのに対して、図１５の例では、レジ端末は、ユーザ端末に対して購入商品情報と店舗情報を送付するだけでよいため、機能の追加が限定的で良いというメリットがある。

　図１６に、中央サーバが商品情報や代替商品情報を取得する際の動作について示す。中央サーバは、ユーザ端末からユーザＩＤ，商品コード、店舗情報を受信する（Ｓ1302）。受信したユーザＩＤに基づいて、ユーザデータベースから当該ユーザの商品制約情報を取得する（Ｓ1303）。また、受信した店舗情報に基づいて店舗位置データベースから当該情報がどの店舗から送られているかを判断し、店舗コードを取得する。さらに、当該店舗コードと商品コードに対応する商品データベースのエントリを選択する（S1304,S1305）。

　引き続き、選択した商品データベースのエントリから、代替商品情報を取得する（Ｓ1306）。中央サーバは、選択した商品データベースのエントリの商品カテゴリーと同一の商品カテゴリーの商品を商品データベースから特定する。特定した商品のうち、発売時期の近い順に、代替商品候補優先度を付与してもよい。また、中央サーバは、商品データベースから、S1304で選択した商品データベースのエントリの商品カテゴリーと同一カテゴリーで、商品名が類似している商品を、代替商品としても良い。商品名の類似は、文字列間の部分一致数に基づいて判断しても良いし、別途、類義語辞典を作成して、それを元に、文字列間の類似性を判断しても良い。商品名ではなく、原材料の共通数に基づいて類似性を判断しても良い。その際に、ユーザの過去の購入品や代替品提示に対する応答の情報を参酌して提示する情報を判断してもよい。端的な例では、以前にユーザが代替品として拒否する旨の入力を行ったものがあれば、それに基づいて、いかに類似性が高くても、その商品は提示しないなどである。

　また、ユーザが選択した商品及びS1306で取得した代替商品の提供可能な時期を、商品提供時期ＤＢから取得する（S1307）。店舗で提供されている商品に限って（ないし優先的に）提示対象にすることで、小売業者は、店頭在庫を優先的に販売することが出来るようにすることが出来る。商品情報送信時にメニューやボタンで選択したり、ユーザ属性設定時などに設定した、ユーザが要望する期間内に倉庫も含めて提供することの出来ない商品の場合は、提示を控えるといった、制限の仕方をしてもよい。よって、類似の商品制約情報を入力していたとしても、ユーザごとに、ユーザが訪問している店舗や、訪問している日時、中央サーバへのアクセスのタイミングなどによって、提示される代替商品は必ずしも同一にはならない。

　次に、選択した商品データベースの原材料リストやカロリーと受信した商品制約情報などとに基づいて、ユーザ端末から受信した商品コードに対する商品がユーザ端末から受信した商品制約情報を満足か否かを判定する（S1308）。

　中央サーバは、ユーザ端末から受信した商品コードに対する商品がユーザ端末から受信した商品制約情報を満足する場合は、選択商品は商品制約情報を満足にする商品であることを意味するコードを商品コードに付与して、代替品情報（代替商品の商品コード、代替商品の優先順位など）、店舗情報，商品提供時期情報と共にユーザ端末に送付する(S1309)。もし、商品制約情報を満足しない場合は、ユーザが商品コードの取得などを通じて中央サーバに提示した（または、引き続き代替商品のクリックないしタップなどを通じてさらなる情報の取得を指示した）ユーザ選択商品は商品制約情報を満足しない商品であることを意味するコードを商品コードに付与して、代替商品情報（代替商品の商品コード、代替商品の優先順位など）、店舗識別情報、商品提供時期情報と共にユーザ端末に送付する(S1311)。受け取った結果をどのように表示するかはユーザ端末の設定に依存する。制約情報を満足しない商品を表示しないようにしてもよいし、制約情報を満足するものとしないものを大きさや色や表示場所を分けることでユーザに提示しても良い。制約情報を満足しない商品を提示するようにすると、ユーザ自身が制約情報を緩和するなどのより精密な設定をする際の情報源にもなり、また一方で、ユーザ自身の制約を満足しないものの、ユーザの周辺の人の制約に照らせば問題ない場合などにおいて、新たな発見的買い物の機会を与えることになる。

　図１７は、購入方法３において、中央サーバがユーザ端末から発注を受け付けて、中央倉庫サーバへ情報伝達する際の中央サーバの処理フローを示している。中央サーバは、ユーザ端末から、ユーザＩＤ，商品コード、店舗情報を受信し（S1402）、ユーザＩＤに基づいて、ユーザデータベースから当該ユーザの商品制約情報を取得する(S1403)。また、受信した店舗情報と店舗位置データベースから当該情報がどの店舗から送られているかを判断し、当該店舗に対応する商品データベースのエントリを選択する(S1404)。引き続き、商品コードと選択した商品データベースと前記の商品制約情報から、代替商品情報を取得する（Ｓ1406）。また、各商品の提供可能な時期を、商品提供時期ＤＢから取得する(S1407)。ユーザ端末から受信した商品コードに対応する商品がユーザの商品制約情報の条件に適合する場合は、ユーザデータベースから発送先や決済情報等を取得し（Ｓ1409）、店舗情報、商品情報、発送先情報を中央倉庫サーバへ送付する（Ｓ1411）。ユーザから受信した商品コードに対応する商品がユーザの商品制約情報の条件に適合しない場合は、商品コードにＮＧコードを付与し、代替品情報を店舗情報と共にユーザ端末に送付する（Ｓ1410）。図１４の変形として、商品データベースから代替商品の情報を得る処理を、ユーザ端末から受信した商品コードに対応する商品がユーザの商品制約情報の条件を満足するかどうかの判定でＮＧであった場合のみに実施するようにしても良い。

　図１８は、購入方法３において、中央サーバが、中央倉庫からユーザに商品が配達された後に、店舗への売上を計上する処理についてのフローである。中央サーバは、中央倉庫サーバから商品の配達完了情報を受信する（Ｓ1502）。配達完了情報には、ユーザＩＤや配達が完了した商品のリストなどが含まれる。本実施例では、ユーザはクレジットカードや電子マネーなどで決済することを前提としているが、配達時に現金で支払うようにこうしても良く、その場合は、ユーザデータベースにクレジットカード情報などを含まず、前記の配達完了情報に、支払確定情報、支払金額情報、支払い日時などの情報を含めるようにするとよい。以下、クレジットカードでの決済を想定して記述する。ユーザへの配達が完了したことをもって、中央サーバは、ユーザの支払を確定させる（Ｓ1503）。すなわち、クレジット会社への請求を確定させる。そこで請求確定が成功したら、中央サーハは、店舗への売上加算処理を行う（Ｓ1504）。どの店舗への売上加算処理を行うかは、先にユーザ端末から受信したユーザＩＤと商品情報と共に店舗情報に基づいて確定した店舗とする。店舗情報から店舗が確定できない場合は、あらかじめ決めた店舗に加算しても良いし、店舗名なしとして、金額を積み上げても良い。ここでは、店舗へは売上として加算しているが、すべてを本店などの特定店舗の売上としたり、中央サーバの売上としておき、各店舗へはリベートという形で決済する方法をとることも可能である。

　図１９に、中央サーバが商品データベースを作成する際のフローを示す。中央サーバは、各店舗向けの商品を選定し、また初期在庫数を決定する(S1602)。店舗毎に決定した商品に関する商品コードを店舗コードを対応づけて商品データベースに格納する。商品データベースには、商品名や原材料情報その他の各種属性情報、バーコード情報や画像特徴量情報などを計算した結果も保存する。

　また、中央サーバは、決定した商品情報を発注数と共に倉庫サーバに送付し、倉庫から各店舗に商品を送付する(S1603)。

　商品の選定はメーカーサーバが行っても良い。店舗ごとに、メーカーサーバが取扱商品を決定して、決定した取扱商品及び在庫数に関する情報を中央サーバに送付する。中央サーバは、Ｓ１６０２での決定し、商品データベースに格納した商品情報や在庫数を、メーカサーバから受信した商品情報及び在庫数で置き換える。

　図２０に、中央サーバが商品データベースを更新する際のフローを示す。商品データベースの更新要求は、図１に示すメーカサーバや倉庫サーバから発せられる。商品データベースの更新情報を引き続き受信して、中央サーバは自身の商品データベースを最新の状態に更新する。

　図２１は、中央倉庫サーバが商品を卸業者に発注する際のフローについて説明する。倉庫サーバは、中央サーバから、商品情報を発注数と共に受信し、その情報に基づいて商品卸業者に商品の発注を行う。商品が到着したら、中央サーバへ商品データベースの更新要求を送信する。また、商品データベースの更新情報を送付する。

　図２２は、購入方法２及び購入方法３において、中央倉庫サーバが、ユーザに商品を発送する際の動作について示したものである。中央倉庫サーバは、逐次、商品情報、発送先情報、（箱やラベルの記載上の）発送元となる店舗情報などを受信し（Ｓ1902）、発送待ち情報として記録する。その際に、必要であれば、商品の取り置き処理などを併せて行う。ユーザごとの商品発送開始条件が満足されない限り、情報の受付状態を継続する（Ｓ1903）。情報の受付は、ユーザの一回の発送単位ごとに管理されており、一つの発送単位が発送開始条件に達した場合は、必要に応じて、新たな情報受付を開始することで、常に情報の待ち受け状態を作ることができる。これらの情報は、配達商品データベースとして、管理される。商品の発送開始条件が満足されれば、中央倉庫サーバは、当該ユーザについて、商品情報、店舗情報に従った商品梱包を行うための情報を出力する（Ｓ1904）。梱包が完了したら、発送先情報に基づいて商品が発送される。これに伴って、商品在庫情報などが変化するため、中央倉庫サーバは、商品データベースの更新要求と更新情報の送付を中央サーバに対して行う（Ｓ1906）。ユーザに配達を完了した旨の情報を受け付けると、倉庫サーバは、ユーザ受領情報を中央サーバに対して送信する（Ｓ1907）。

　図２３に、商品パッケージの例を示す。この例の商品は、乳製品飲料という名前の商品であり、商品５０１には、商品名記載部５０２、原材料名記載部５０３が備えられている。原材料名記載部５０３は、多くの商品では、本図に示すように、商品パッケージの側面や背面に記載されており、図６に示す陳列棚６０１の様子からもわかるように、商品を一旦棚から取出さなければ、目視で確認することはできない。原材料名記載部５０３の例を５０４に記載した。原材料名記載部には、商品の名称や使用している原材料名、内容量、賞味期限、保存方法、製造者の情報が記載されていることが一般的である。例えば、日本では、原材料名の部分に、主要なアレルゲンに関する記載をすることが義務付けられており、本記載例でも、「（大豆を含む）」といった表記が見られる。一方で、「生乳」など、記載から明らかに乳アレルギー患者には不適切であることが分かる場合は、特段の追加の注意喚起の記載が無いことも多い。本例から分かることは、原材料名の表記を見れば、本製品は商品名は「乳製品飲料」でありながら、大豆アレルギー患者にとっても必ずしも摂取が適当ではないということである。実際に商品を選択する上で、逐一これらの表記を確認することに多大な労力が必要とされることは明らかである。

　図２４に、商品の陳列例を示す。本例では、商品棚６０１に商品６０２をはじめとする複数の商品が収められている。また、商品６０２に対して値札６０３が対応づいて取り付けられているように、各商品について対応する値札が取り付けられていることが普通である。値札６０３を拡大表示したものが６０３ａである。本値札例６０３ａでは、商品名、商品バーコード、および商品金額が記載されている。さらに商品カテゴリーなど、様々な情報が記載されている場合もあるが、ここではそのすべてを列挙はしない。商品棚に付けられる値札の大きさは限られているため、最低限、前記の情報を記すことが多い。

　ユーザは、ユーザ端末を把持して入出力部に表示される情報に基づいて操作を行う。その表示画像の一例を図２５に示す。ユーザが、ユーザ端末２５０１にインストールされているアプリケーションを起動すると、ユーザ端末は、背面カメラ４０５を使用して、商品棚２５０２に収められている商品を撮影するモードに切り替わる。この撮影モードでは、リアルタイムに、背面カメラが捉えている画像が更新されており、ユーザは、ユーザ端末の向きを変更することで、所望の商品を撮影することができる。この図では、ユーザ端末を横に傾けた状態で使用しているが、もちろんユーザ端末の向きは、本発明を実施する上での妨げにはならない。

　図２６に、ユーザ端末で撮影した画像の例を示す。ユーザ端末の入出力部７０１には、現在カメラが捉えている範囲の画像７０４が表示される。ここでは、値札に記載されているバーコードを画像から読み取って、ユーザが注目している商品を特定する場合について述べる。画像７０４は、現時点では、入出力部７０１に対して傾いた状態で撮影されている。ユーザ端末のアプリケーションは、画像に対して入出力部７０１の垂直方向にラインスキャンを行い、画像からバーコードらしい部分を見つけて、情報を読み取るとする。すなわち、現在のスキャンラインを７０３とすると、このスキャンラインは、入出力部の最下部から、画像の１ラインごとにバーコードの有無を検査して、順次最上部までスキャンする。もちろん、１ラインごとである必要はなく、数ラインごとに処理をしても良い。この方式では、値札のバーコードが入出力部に対して水平に撮影されていることが望ましい。しかし、ユーザは、入出力部に表示されている画像を頼りにユーザ端末の傾きを調整することが必要であることに気づかない、ないしは水平になっているかどうかの判断基準がなくうまく傾きを調整できないことがある。そこで、本実施例では、ユーザ端末のアプリケーションは、ガイドとなるマーカライン７０２を入出力部の中ほどに表示する。これに従うと、ユーザは、撮影している画像に含まれる水平ラインとマーカラインとが平行になるようにユーザ端末の傾きを調整すればよくなるため、撮影対象７０４ａとユーザ端末との相対的な傾きの微調整を行いやすくなる。

　図２６では、ユーザがアプリケーションの画像処理方法に合わせる方式を提示した。一方で、アプリケーション側でユーザが撮影した画像に応じてバーコードのスキャン方向を選択することもできる。図２７にその例を示す。図２７では、入出力部８０１に、画像８０２が傾いて撮影されている。この時、アプリケーションは、Ｈｏｕｇｈ変換などの画像処理技術によって、主要な線分を画像から抽出する。特に、図２７の例では、水平方向の直線８０３を主たる抽出対象とした場合を示している。画像８０２には、多くの線分が含まれているが、これらの平均的な傾きを計算することで、値札に記載されているバーコードの向きが高い確率で推定可能である。その推定結果のスキャンラインを８０４として示している。この傾きのスキャンラインで、画像８０２の右下から左上間で走査することで、バーコードを抽出することができる。この例で、主に水平に近い線分のみを抽出対象として、垂直に近い線分を抽出しなかったのは、ユーザと商品棚が正対したときに、ほとんどの場合で、バーコードが撮影画像中で水平な方向に位置するという知見からそのようにしている。もしバーコードが異なる方向に設置されることが想定される場合、垂直に近い線分のみを抽出するようにしても良いし、水平や垂直の制限に関わらずに線分を抽出して、各方向にスキャンラインを設定して順次走査するように構成してもよい。

　以上は、値札にバーコードが記載されていることを利用した商品特定方法についての説明である。ユーザから撮影できる範囲に商品のバーコードが記載されていない場合には、画像認識技術を用いた商品の特定手段を用いることができる。それを図９に示す。

　図２８では、入出力部９０１に、ガイド枠９０２を表示している。アプリケーションは、ガイド枠９０２内部の画像を処理して、特徴的な点９０３を複数抽出する。抽出された特徴点を入出力部９０１に表示することでユーザに提示しても良いし、特徴点まではユーザに提示しないようにしてもよい。もちろん、ユーザがそれを選択できるようにしても良い。抽出された特徴点群は、ガイド枠内の位置情報を含めた画像特徴９０３として、切り出される。アプリケーションは、この画像特徴と、あらかじめ商品情報とひもづけて作成しておいたテンプレート９０５とを比較して、類似性が高ければ、その商品であると判断する。これらのテンプレート情報は、各商品についてあらかじめ作成しており、それを中央サーバが保持するかユーザ端末が保持するテンプレートデータベース９０５に格納しておく。テンプレートデータベースが中央サーバに保持されている場合は、ユーザ端末は、前記の特徴点情報を中央サーバに送付して、上記の類似性判定を中央サーバで行う。ユーザ端末がテンプレートデータベースを持つ場合は、ユーザ端末内で前記の特徴点を類似する商品情報に、ユーザ端末内で変換する。テンプレートデータベースの作成方法は、様々に考えられる。すでに述べたように、あらかじめすべての対象商品について撮影を行い、画像特徴を記録する方法や、ユーザが撮影した画像がテンプレートデータベースのどれにもマッチしない場合に、新たな製品であるとして、ユーザに情報の入力を促す方法でもよい。また、画像の特徴点の計算方法も様々であり、ここで述べた方法以外にも、商品画像同士の類似性を評価する方法が考えられる。画像の撮影向き（回転）や大きさ（拡大縮小）に対して強い特徴量を用いれば、より安定した商品識別が可能になる。

　このようにして撮影した画像からユーザが注視している商品を特定することで、ユーザは簡便に商品を指定することができる。これらの処理をユーザ端末上で行っても良いし、その一部を中央サーバなどで行っても良い。どちらで行うかを、通信路の容量の多寡に応じて決めれば、よりユーザに待ち時間などのストレスを与えにくいシステムを作ることができる。

　このようにして商品情報を中央サーバに伝達すると、本実施例のシステムは、中央－ＤＢから当該商品の情報とともに代替品の情報をユーザ端末に送付する。代替品の選定は、ユーザ端末上でアプリケーションが起動した際に中央サーバにセッション情報と共に送付されるように構成しても良いし、商品情報を中央サーバに送る際に逐一ないし適当な間隔で送っても良い。

　本明細書では、ユーザの商品制約条件として、食物アレルギーを想定して説明を行ったが、必ずしも食物アレルギーに限られるわけではない。たとえば、特定のメーカの製品であることや、特定の製造方法で製造されていることや、特定の価格以上ないし価格未満であることや、特定のユーザ層の購入割合が高いことや、特定のカロリー未満であることや、特定の原材料を含むことや、特定の種類数の原材料しか使用していないことや、特定の時期にのみ販売されていることなど、ユーザの嗜好に応じて様々に設定され得るものである。

101：ユーザ端末
102：ネットワーク
103：中央サーバ
104：中央サーバに接続されたデータベース
105,107：メーカサーバ
106.108：メーカサーバに接続されたデータベース
109：倉庫サーバ
110：倉庫サーバに接続されたデータベース
201：インターネット
202：中央サーバ
203：イントラネット
302,401,2501：ユーザ端末
501：商品パッケージ
601,2502：商品陳列棚
603：商品の値札
2601：ユーザ端末に搭載されている表示装置に表示された画像
2602：ユーザが選択した商品の詳細情報表示部
2603：あとで配送することを指定するためのボタン表示
2604：代替品情報の表示部

Claims (15)

1. 　商品を特定するための商品情報を取得する第一のセンサと店舗情報を取得するための第二のセンサとを備えるユーザ端末と、ネットワークを介して接続される中央サーバを含む発注情報制御システムであって、
   　前記中央サーバは、
   　商品の商品情報を保持する商品データベースを備え、
   　前記ネットワークを介して、前記第一のセンサで取得した商品情報と、前記第二のセンサで取得した前記ユーザ端末が前記商品情報と取得した店舗を識別するための店舗情報を前記ユーザ端末から受信し、
   　前記商品データベースを参照して前記ユーザ端末から受信した商品情報に関連する商品の属性情報と、前記受信した店舗情報と、に基づいて、前記受信した店舗情報に応じた代替商品情報を取得し、
   　前記取得した代替商品情報を前記ユーザ端末に送信することを特徴とする発注情報制御システム
2. 　前記ユーザ端末上で動作するプログラムは、
   　前記中央サーバから受信する代替商品情報を該ユーザ端末上に表示させることを特徴とする発注情報制御システム。
3. 　請求項１に記載の発注情報制御システムであって、
   　前記中央サーバは、
   　店舗と商品の組毎に、該商品の提供時期または提供場所を記憶した商品提供時期データベースを備え、
   　前記中央サーバは、前記ユーザ端末から受信した店舗情報、商品情報、及び前記商品データベースに基づいて、前記代替商品情報を取得することを特徴とする発注情報制御システム
4. 　請求項３に記載の発注情報制御システムであって、
   　前記中央サーバは、
   　前記ユーザ端末から、注文商品の商品コード及び前記店舗情報を含む商品発注情報を受信し、
   　該商品の配送が完了すると、前記注文商品の売上金額を前記店舗情報に対応する店舗の売上金額として計上することを特徴とする発注情報制御システム。
5. 　請求項４に記載の発注情報制御システムであって、
   　前記中央サーバは、
   　ユーザを識別するユーザ識別子及び該ユーザの商品制約情報を備えるユーザデータベースを備え、
   　前記商品データベースは、さらに、商品の商品名、商品カテゴリー、商品属性情報を記憶し、
   　前記ユーザ端末から受信するユーザ識別子に対応する商品制約情報、前記ユーザ端末から受信する商品情報、前記商品データベースに記憶された商品の商品名、商品カテゴリー、商品属性情報に基づいて、前記商品制約情報を満たす代替商品情報を取得することを特徴とする発注情報制御システム。
6. 　請求項４に記載の発注情報制御システムであって、
   　前記中央サーバは、前記代替商品情報とともに、各代替商品の提供場所、提供時期を前記ユーザ端末に送信し、
   　前記プログラムは、
   　前記代替商品情報とともに、各代替商品の提供場所、提供時期を表示させることを特徴とする発注情報制御システム。
7. 　請求項６に記載の発注情報制御システムであって、
   　前記店舗情報は、
   　前記第一のセンサが前記商品情報を取得した位置の位置コード、前記第一のセンサが前記商品情報を取得した店舗のゲートの通過ゲート番号、前記第一のセンサが前記商品情報を取得したとき接続可能範囲にあった無線ネットワークのアクセスポイントのＭＡＣアドレスのリストのいづれかであることを特徴とする発注情報制御システム。
8. 　ユーザ端末が商品を発注する発注情報制御方法であって、
   　前記ユーザ端末はネットワークを介して中央サーバと接続され、
   　前記中央サーバは、商品の商品情報を保持する商品データベースを備え、
   　前記中央サーバは、
   　前記ネットワークを介して、ユーザ端末から商品情報と、前記ユーザ端末が前記商品情報と取得した店舗を識別する店舗情報と、を前記ユーザ端末から受信し、
   　前記商品データベースを参照して前記ユーザ端末から受信した商品情報に関連する商品の属性情報と、前記受信した店舗情報と、に基づいて、前記受信した店舗情報に応じた代替商品情報を取得し、
   　前記取得した代替商品情報を前記ユーザ端末に送信することを特徴とする発注情報制御方法。
9. 　前記ユーザ端末は、
   　前記商品情報を該ユーザ端末が備える第一のセンサで取得し、前記店舗情報を該ユーザ端末が備える第二のセンサで取得し、
   　前記中央サーバから受信する前記代替商品情報を該ユーザ端末の画面上に表示させることを特徴とする請求項８に記載の発注情報制御方法。
10. 　前記中央サーバは、
    　店舗と商品の組毎に、該商品の提供時期または提供場所を記憶した商品提供時期データベースを備え、
    　前記中央サーバは、前記ユーザ端末から受信した店舗情報、商品情報、及び前記商品データベースに基づいて、前記代替商品情報を取得することを特徴とする請求項９に記載の発注情報制御方法。
11. 　請求項１０に記載の発注情報制御方法あって、
    　前記中央サーバは、
    　前記ユーザ端末から、注文商品の商品コード及び前記店舗情報を含む商品発注情報を受信し、
    　該商品の配送が完了すると、前記注文商品の売上金額を前記店舗情報に対応する店舗の売上金額として計上することを特徴とする発注情報制御方法。
12. 　請求項１１に記載の発注情報制御方法であって、
    　前記中央サーバは、
    　ユーザを識別するユーザ識別子及び該ユーザの商品制約情報を備えるユーザデータベースを備え、
    　前記商品データベースは、さらに、商品の商品名、商品カテゴリー、商品属性情報を記憶し、
    　前記ユーザ端末から受信するユーザ識別子に対応する商品制約情報、前記ユーザ端末から受信する商品情報、前記商品データベースに記憶された商品の商品名、商品カテゴリー、商品属性情報に基づいて、前記商品制約情報を満たす代替商品情報を取得することを特徴とする発注情報制御方法。
13. 　請求項１２に記載の発注情報制御方法であって、
    　前記中央サーバは、前記代替商品情報とともに、各代替商品の提供場所、提供時期を前記ユーザ端末に送信し、
    　前記ユーザ端末は、
    　前記代替商品情報とともに、各代替商品の提供場所、提供時期を画面上に表示することを特徴とする発注情報制御方法。
14. 　請求項１３に記載の発注情報制御方法であって、
    　前記店舗情報は、
    　前記第一のセンサが前記商品情報を取得した位置の位置コード、前記第一のセンサが前記商品情報を取得した店舗のゲートの通過ゲート番号、前記第一のセンサが前記商品情報を取得したとき接続可能範囲にあった無線ネットワークのアクセスポイントのＭＡＣアドレスのリストのいづれかであることを特徴とする発注情報制御方法。
15. 　ユーザ端末を
    　該ユーザ端末が備える第１のセンサが商品情報を取得する手段と、
    　該ユーザ端末が備える第２のセンサが、該ユーザ端末が前記商品情報と取得した店舗を識別する店舗情報を取得する手段と、
    　中央サーバに前記商品情報と前記店舗情報を送信する送信手段と、
    　前記商品情報に関連する商品の属性情報と、前記受信した店舗情報と、に基づいて、前記中央サーバは前記店舗情報に応じて取得した代替商品情報を受信する受信する手段と、
    　前記受信した代替商品情報を表示する表示手段として機能させるための商品発注プログラム。
    
    　

Images