JP7616708B2 - 酒類の情報管理システム及び管理方法 - Google Patents

Description

本発明は、酒類の情報管理システム及び管理方法に関する。

本技術分野の背景技術として、特開２００３－１６３５１号公報（特許文献１）がある。この公報には、「ユーザの希望商品を購入できる販売店への案内を行える商品購入支援システム等を提供する。商品情報管理サーバ１０が販売店毎に用意された店舗サーバ５０から送信される商品管理情報によって在庫の有無などを把握している。ナビゲーション装置２０は、ユーザから検索対象となる商品特定情報を受け付けると、その商品特定情報が商品情報管理サーバ１０へ送信され、商品情報管理サーバ１０において、その商品の購入が可能な販売店に関する販売店情報をナビゲーション装置２０へ送信する。ナビゲーション装置２０では販売店の位置を地図上に表示できるためユーザは購入可能な販売店の位置が分かる。また、必要ならばその販売店までの経路案内も指示できる。これにより、せっかく販売店まで出向いたのに在庫切れで購入できない、といった不都合が解消される。」と記載されている。

また、特開２００３－８５４２２号公報（特許文献２）がある。この公報には、「ユーザが、購入したい特定の商品を、今、どこの店にどの程度の在庫が保有されているかと言う情報を、即時に入手して、前記の特定商品を、所望の販売業者に於いて、確実に購入する事が出来る商品在庫状況確認システム及び商品在庫状況確認方法を提供する。特定の販売業者に於ける特定の商品の在庫情報をユーザに提供する事を業務とする事業体２と、事業体２から在庫情報を受ける事を希望するユーザ４とが、通信回線５を介して互いに接続可能に配置されている通信システム１００に於いて、事業体２は、複数の販売業者６からリアルタイムで受信している特定の商品に関する在庫情報に基づき商品別在庫情報データベース８を作成し、ユーザ４からの要求に応答して、所定の商品の販売業者別在庫情報をユーザ４に提供する商品在庫状況確認システム１００。」と記載されている。

特開２００３－１６３５１号公報 特開２００３－８５４２２号公報

前記特許文献１には、販売店毎に用意された店舗サーバから商品管理情報を受信し、在庫管理を行う商品購入支援システムが記載されている。しかし、特許文献１の商品購入支援システムでは、在庫管理のために膨大な数ある販売店すべてにサーバを設置する必要があり、管理が煩雑となる。

特許文献２には、複数の販売業者から受信している在庫情報に基づき商品別在庫情報データベースを作成し、所定の商品の販売業者別在庫情報をユーザに提供する商品在庫状況確認システムが記載されている。しかし、特許文献２の商品在庫状況確認システムにおいても、在庫管理のために膨大な数ある販売業者すべてにシステムを設置する必要があり、管理が煩雑となる。

そこで、本発明は、飲食店や小売店に商品を卸す流通業者の販売実績情報を活用した商品の管理システム及び管理方法を提供する。例えば、レストランや居酒屋・酒屋で販売される酒類の銘柄等を管理する仕組みを提供する。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、情報管理システムであって、統合管理サーバは、店舗に商品を販売する複数の流通企業の複数の流通企業端末から、それぞれ販売実績情報を受け付けるデータ整形手段と、前記店舗に販売される酒類の銘柄を前記複数の流通企業に対して共通に管理するための銘柄マスタ情報を、受け付けた前記それぞれの販売実績情報に基づいて更新するデータ突合手段と、ユーザ端末から画像関連情報を受信した場合に、受信した画像関連情報を解析し、前記銘柄マスタ情報に登録されている酒類の銘柄に対応する特徴情報との比較を行うことにより酒類の銘柄を特定し、特定された酒類の銘柄に関する情報をユーザ端末に送信する銘柄判定手段と、を有し、ユーザ端末は、送信された酒類の銘柄に関する情報を表示する表示手段を有することを特徴とする。

本発明によれば、飲食店や小売店に商品を卸す流通業者の販売実績情報等に基づいた幅広い商品の管理を提供することができる。また他には例えば、膨大な数ある飲食店や小売店それぞれに在庫管理システムを導入することなく、流通業者の販売実績情報等に基づいて、飲食店や小売店での取扱銘柄等の情報を管理することができる。また他には例えば、流通業者の情報を用いて、ユーザに幅広い商品や酒類の銘柄に関する情報を提供することが可能となる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

全体の管理システム１の構成図の例である 統合管理サーバ１０１のハードウェア構成の例である。 ユーザ端末１０３のハードウェア構成の例である。 流通企業端末１０２のハードウェア構成の例である。 店舗端末１０４のハードウェア構成の例である。 メーカ端末１０５のハードウェア構成の例である。 ユーザマスタテーブル７００の例である。 銘柄マスタテーブル８００の例である。 店舗マスタテーブル９００の例である。 ユーザ別登録銘柄テーブル１０００の例である。 店舗別取扱銘柄テーブル１１００の例である。 銘柄解析テーブル１２００の例である。 流通企業商品テーブル１３００の例である。 流通企業店舗テーブル１４００の例である。 流通企業担当者テーブル１５００の例である。 流通企業販売実績テーブル１６００の例である。 銘柄マスタ紐付けテーブル１７００の例である。 店舗マスタ紐付けテーブル１８００の例である。 データ整形処理フローの例である。 流通企業販売実績テーブル１６００に対するデータ突合処理フローの例である。 データ解析処理フローの例である。 銘柄登録処理フローの例である。 銘柄判定処理フローの例である。 銘柄解析処理フローの例である。 銘柄スキャン処理フローの例である。 登録一覧画面２６００の例である。 登録一覧画面の別の表示２７００の例である。 地図上に選択された銘柄のお酒を飲める店を表示する画面の例である。 銘柄登録画面の例である。 銘柄登録処理で銘柄の付加情報を表示する画面の例である。 銘柄スキャン画面の例である。 銘柄スキャン画面の別の表示例である。 銘柄スキャン画面の別の表示例である。 銘柄解析テーブル１２００の人気度の判定を説明する図である。 銘柄解析テーブル１２００の希少度の判定を説明する図である。

近年、ユーザが飲んだお酒の銘柄を登録して管理するアプリ（アプリケーション）が使われている。
しかしながら、これらのアプリは、ワイン向けアプリ、日本酒向けアプリ、ウィスキー向けアプリなど、特定のカテゴリの酒類にのみ対応しており、カテゴリを超えて銘柄を登録することができず、ワインも日本酒もたしなむユーザなど、幅広いカテゴリのお酒をたしなむユーザにとっては、カテゴリごとに異なるアプリを起動して管理する必要があり、不便であった。
また、これらのアプリでは、ユーザが実際に飲んだ銘柄を登録することができるが、ユーザが飲みたいと思った銘柄について、簡単にその情報を登録もしくは確認することができなかった。

そこで、本実施例においては、ユーザが飲んだ銘柄や飲みたいと思った銘柄を、酒類のカテゴリによらず簡易に登録可能とし、また飲んだ銘柄や飲みたい銘柄として登録した酒類の情報について、様々な方法で表示することを可能とする。
例えば、飲んだ銘柄や飲みたい銘柄をスキャン表示し、また飲みたい銘柄を飲める店舗を地図やリストで表示することを可能とする。

以下、実施例を図面を用いて説明する。
図１は、全体の管理システム１の構成図の例である。
管理システム１は、複数の流通企業端末１０２、複数のユーザ端末１０３、複数の店舗端末１０４、複数のメーカ端末１０５、複数のその他業者端末１０６を備え、それぞれがネットワークを介して統合管理サーバ１０１に接続されている。なお、ネットワークは有線、無線を問わず、それぞれの端末はネットワークを介して情報を送受信することができる。

管理システム１のそれぞれの端末や統合管理サーバ１０１は、例えば、スマートフォン、タブレット、携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末でもよいし、メガネ型や腕時計型、着衣型などのウェアラブル端末でもよい。また、据置型または携帯型のコンピュータや、クラウドやネットワーク上に配置されるサーバでもよい。あるいは、これらの複数の端末の組合せであってもよい。例えば、１台のスマートフォンと１台のウェアラブル端末との組合せが論理的に一つの端末として機能し得る。またこれら以外の情報処理端末であってもよい。

流通企業端末１０２は、例えば流通企業Ｐ、流通企業Ｑ、流通企業Ｒがそれぞれ備える端末である。流通企業は、飲食店や小売店などの店舗に酒類などの商品を卸しており、それぞれの企業が販売先店舗や販売商品や販売実績を管理している。本明細書においては、特に酒類の管理について記載をするが、商品は酒類に限られるものではなく、食べ物や食材などでも同様の構成で発明を実施することが可能である。酒類以外の商品で本発明を実施する場合には、酒類の銘柄の特定は、その商品の種類や内容を特定することとなる。

ユーザ端末１０３は、酒類などの商品を飲食店や小売店から購入するユーザが所有または利用する機器である。ユーザが「飲んだ」「飲みたい」酒類などの商品情報を登録し管理する。本発明を酒類以外の商品で実施する場合には、ユーザが「飲んだ・食べた・購入した」情報や・「飲みたい・食べたい・買いたい・欲しい」情報を登録して管理することとなる。

店舗端末１０４は、流通業者の商品販売先である飲食店、小売店などが備える端末である。メーカ端末１０５は、商品を製造・販売するメーカ企業が備える端末である。その他業者端末１０６は、酒類やその他商品の製造から飲食店・小売店への販売までの流通過程に関与する業者が備える端末である。

統合管理サーバ１０１は、複数の流通企業端末１０２から、販売先店舗や販売商品や販売実績に関する情報を受信し、共通のフォ－マットに整形し、管理する。また、ユーザ端末１０３から酒類などの商品の画像関連情報を受信し、商品名等を判別し、商品の関連情報と共にユーザ端末１０３に送信する。

管理システム１のそれぞれの端末や統合管理サーバ１０１は、それぞれオペレーティングシステムやアプリケーション、プログラムなどを実行するプロセッサと、ＲＡＭ（Random Access Memory）等の主記憶装置と、ＩＣカードやハードディスクドライブ、ＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶装置と、ネットワークカードや無線通信モジュール、モバイル通信モジュール等の通信制御部と、タッチパネルやキーボード、マウス、音声入力、カメラ部の撮像による動き検知による入力などの入力装置と、モニタやディスプレイ等の出力装置とを備える。なお、出力装置は、外部のモニタやディスプレイ、プリンタ、機器などに、出力するための情報を送信する装置や端子であってもよい。

主記憶装置には、各種プログラムやアプリケーションなど（モジュール）が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することで統合管理システム１の各機能要素が実現される。なお、なお、これらの各モジュールは集積化する等によりハードウェアで実装してもよい。また、各モジュールはそれぞれ独立したプログラムやアプリケーションでもよいが、１つの統合プログラムやアプリケーションの中の一部のサブプログラムや関数などの形で実装されていてもよい。
本明細書では、各モジュールが、処理を行う主体（主語）として記載をしているが、実際には各種プログラムやアプリケーションなど（モジュール）を処理するプロセッサが処理を実行する。

補助記憶装置には、各種データベース（ＤＢ）が記憶されている。「データベース」とは、プロセッサまたは外部のコンピュータからの任意のデータ操作（例えば、抽出、追加、削除、上書きなど）に対応できるようにデータ集合を記憶する機能要素（記憶部）である。データベースの実装方法は限定されず、例えばデータベース管理システムでもよいし、ＸＭＬなどのテキストファイルでもよい。

図２は、統合管理サーバ１０１のハードウェア構成の例である。
統合管理サーバ１０１は、例えばクラウド上に配置されたサーバで構成される。
主記憶装置２０１には、データ整形モジュール２１１、データ突合モジュール２１２、ユーザデータ管理モジュール２１３、銘柄判定モジュール２１４、データ解析モジュール２１５等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ２０３が実行することで統合管理サーバ１０１の各機能要素が実現される。

データ整形モジュール２１１は、各流通企業端末１０２から受信した、商品情報、店舗情報、販売実績情報等を、流通企業データの受領ＤＢ２２４に格納する。また、データ整形モジュール２１１は、各流通企業端末１０２から受信した情報を共通の統一したフォーマットに整形し、流通企業データの整形ＤＢ２２３に格納する。

データ突合モジュール２１２は、流通企業データの整形ＤＢ２２３に格納する情報と、企業横断マスタＤＢ２２２の情報とを突合する。企業横断マスタＤＢ２２２の銘柄マスタテーブル８００、店舗マスタテーブル９００に対応する商品情報・店舗情報がある場合には、マスタのＩＤを流通企業データの整形ＤＢ２２３のテーブルに格納する。
一方、企業横断マスタＤＢ２２２に対応する情報がない場合には、流通企業データの整形ＤＢ２２３の情報に基づいて、新たなレコードを企業横断マスタＤＢ２２２に追加する。

ユーザデータ管理モジュール２１３は、ユーザ端末１０３から受け付けた、ユーザの情報、「飲んだ」「飲みたい」銘柄に関する情報等を、ユーザ別登録銘柄テーブル１０００に記憶し、管理する。
銘柄判定モジュール２１４は、ユーザ端末１０３から受信した画像または画像に関する情報に基づき、画像に移っている酒類の銘柄を判定する。
データ解析モジュール２１５は、企業横断マスタＤＢ２２２や流通企業データの整形ＤＢ２２３に格納された情報を解析することにより、ユーザや流通企業等に有用な情報を生成し、ユーザ端末１０３や流通企業端末１０２等に提供する。

補助記憶装置２０２は、解析データＤＢ２２１、企業横断マスタＤＢ２２２、流通企業データの整形ＤＢ２２３、流通企業データの受領ＤＢ２２４等のデータベースを備える。
流通企業データの受領ＤＢ２２４は複数の流通企業端末１０２から受信した、商品情報
、店舗情報、担当者情報、販売実績情報などを格納している。流通企業データの整形ＤＢ２２３は、各流通企業端末１０２から受信した、商品情報、店舗情報、販売実績情報等を、共通の統一したフォーマットに整形した情報を格納する。

企業横断マスタＤＢ２２２は、統合管理サーバ１０１で管理する商品情報、店舗情報、ユーザ情報のマスタ情報を格納する。
流通企業端末１０２から受領した商品情報、店舗情報、販売実績情報は、各流通企業によってそのフォーマットやＩＤやキー情報が異なっているため、通常複数の流通企業端末１０２の情報はそのままの状態では流通企業を跨いだ比較や処理・分析をすることができない。本実施例では、これらの情報のフォーマットをデータ整形モジュール２１１の処理により整形し、共通のフォーマットに整えて企業横断マスタＤＢ２２２に保存することで、複数の流通企業の販売実績情報等をまとめて処理・分析・利用することが可能となる。
解析データＤＢ２２１は、企業横断マスタＤＢ２２２や流通企業データの整形ＤＢ２２３の情報を解析した情報を格納する。

図３は、ユーザ端末１０３のハードウェア構成の例である。
ユーザ端末１０３は、酒類などの商品を飲食店や小売店から購入するユーザが使用する端末である。
主記憶装置３０１には、銘柄登録モジュール３１１、銘柄スキャンモジュール３１２、一覧表示モジュール３１３等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ３０３が実行することでユーザ端末１０３の各機能要素が実現される。

これらのモジュールは一つの「酒類情報管理アプリ」にサブモジュールとして組み込まれており、ユーザはスマートフォンなどの端末に酒類情報管理アプリをインストールすることで、これらの各モジュールの機能を利用できるようになる。

銘柄登録モジュール３１１は、ユーザからの「飲みたい」「飲んだ」銘柄やコメントなどの登録を行う。
銘柄スキャンモジュール３１２は、カメラ部３０７により取得された画像情報を処理し、統合管理サーバ１０１の銘柄判定モジュール２１４と連携して、撮影画像上に酒類の情報を重畳して表示する。例えばＡＲ（Augmented Reality：拡張現実）の機能を用いて、表示してもよい。
一覧表示モジュール３１３は、ユーザにより登録された銘柄情報や、統合管理サーバ１０１から送られてきたおすすめ情報等を表示する。

補助記憶装置３０２に、ユーザ端末データ３２１が記憶されており、ユーザからの「飲みたい」「飲んだ」銘柄やコメント、評価などが格納されている。

図４は、流通企業端末１０２のハードウェア構成の例である。
流通企業端末１０２は、酒類などの商品を飲食店や小売店に卸す流通企業が使用する端末である。
主記憶装置４０１には、販売実績管理モジュール４１１、商品管理モジュール４１２、顧客店舗管理モジュール４１３、統合管理サーバ連携モジュール４１４等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ４０３が実行することで流通企業端末１０２の各機能要素が実現される。

販売実績管理モジュール４１１は、流通企業の販売実績を販売実績データ４２１に登録し、管理する。
商品管理モジュール４１２は、流通企業で販売・管理される商品の商品名や酒類の銘柄名を流通企業マスタ４２２に登録、管理する。なお、このマスタＤＢは必須ではなく、商品や店舗の情報をすべて販売実績データの中に書き込んで管理するという構成でもよい。
顧客店舗管理モジュール４１３は、流通企業が商品・酒類を販売する先の顧客の情報を流通企業マスタ４２２に登録、管理する。

統合管理サーバ連携モジュール４１４は、補助記憶装置４０２に記憶されている販売実績データ４２１や流通企業マスタ４２２の商品情報や顧客店舗情報を定期的に、もしくは情報の更新があるたびに、統合管理サーバ１０１に送信する。その他任意のタイミングで送信することとしてもよい。またアプリケーションのような形ではなく、単にＷｅｂブラウザ経由で統合管理サーバにアクセスして統合管理サーバと連携することにより、Ｗｅｂブラウザの機能を用いて情報を送付するという形にしてもよい。

補助記憶装置４０２には、流通企業の販売実績データ４２１や商品情報や顧客店舗情報などを記憶する流通企業マスタ４２２が記憶されている。これらの情報は、基本的には図１の企業Ｐ、企業Ｑ、企業Ｒ等の流通企業ごとに異なるフォーマットやＩＤ情報、キー情報により管理されている。

流通企業の顧客店舗への販売の記録である販売実績情報には、合わせて何を売ったかという商品の情報や、誰に売ったかという顧客店舗の情報が含まれるが、これらの商品情報や店舗情報は、販売実績情報の中に直接記載されていてもよいし、別に商品情報や店舗情報を他のマスタとして管理し、ＩＤ情報等により販売実績情報と対応付けて管理されていてもよい。図４の例では、販売実績は販売実績データ４２１に、これらの商品や店舗のマスタ情報は別の流通企業マスタ４２２の中で管理されている一例である。すべてを一つの情報として流通企業マスタ４２１で管理しても構わない。

従って、本明細書においては「販売実績情報」というときには、いわゆる販売の記録である販売実績情報だけでなく、それに付随するマスタ情報である「商品情報」や「店舗情報」も含むものとして記載する。但し、文脈によっては商品情報・店舗情報・販売実績情報と分けて記載する場合もある。この場合であっても「販売実績情報」というときにはその中に商品情報や店舗情報を合わせて持っていたり、含んでいたりしてもよい。

図５は、店舗端末１０４のハードウェア構成の例である。
店舗端末１０４は、飲食店や小売店など、流通企業から酒類や商品を購入し、ユーザに販売する店舗で使われる端末である。
主記憶装置５０１には、在庫管理モジュール５１１、商品管理モジュール５１２、統合管理サーバ連携モジュール５１３等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ５０３が実行することで店舗端末１０４の各機能要素が実現される。

在庫管理モジュール５１１は、飲食店や小売店などの店舗企業が販売する商品・酒類の在庫・販売情報を在庫データ５２１に登録し、管理する。
商品管理モジュール５１２は、店舗企業が販売する商品の商品名や酒類の銘柄名を商品データ５２２に登録し、管理する。

統合管理サーバ連携モジュール５１３は、補助記憶装置５０２に記憶されている在庫データ５２１や商品データ５２２を定期的に、もしくは情報の更新があるたびに、統合管理サーバ１０１に送信する。

在庫データ５２１に更新があり在庫切れになっている場合には、統合管理サーバ連携モジュール５１３が統合管理サーバ１０１と連携し、解析ＤＢの店舗別取扱銘柄テーブル１１００の取扱切れリスクを「取扱終了確定」など、最新の情報に書き換えることができる。
また、統合管理サーバ連携モジュール５１３は、統合管理サーバ１０１から送られてくる銘柄情報や、解析情報などを出力する。アプリケーションのような形ではなく、単にＷｅｂブラウザ経由で統合管理サーバにアクセスして統合管理サーバと連携することにより、Ｗｅｂブラウザの機能を用いて情報を送受信するという形にしてもよい。
補助記憶装置には、飲食店や小売店の在庫データが格納されている。

図６は、メーカ端末１０５のハードウェア構成の例である。
メーカ端末１０５は、酒類などの商品を製造・販売する企業が使用する端末である。
主記憶装置６０１には、在庫管理モジュール６１１、商品管理モジュール６１２、統合管理サーバ連携モジュール６１３等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ６０３が実行することでメーカ端末１０５の各機能要素が実現される。

在庫管理モジュール６１１は、メーカ企業が生産・販売する商品・酒類の在庫・販売情報を在庫データ６２１に登録し、管理する。
商品管理モジュール６１２は、メーカ企業が生産・販売する商品の商品名や酒類の銘柄名を商品データ６２２に登録し、管理する。

統合管理サーバ連携モジュール６１３は、補助記憶装置６０２に記憶されている商品データ６２２を定期的に、もしくは情報の更新があるたびに、統合管理サーバ１０１に送信する。その他任意のタイミングで送信することとしてもよい。またアプリケーションのような形ではなく、単にＷｅｂブラウザ経由で統合管理サーバにアクセスして統合管理サーバと連携することにより、Ｗｅｂブラウザの機能を用いて情報を送付するという形にしてもよい。

統合管理サーバ１０１で管理されている銘柄マスタテーブル８００の内容が、不正確もしくは更新が必要な場合には、統合管理サーバ連携モジュール６１３が統合管理サーバ１０１と連携して、銘柄マスタテーブル８００の内容を書き換えることができる。
補助記憶装置６０２には、メーカ企業が生産・販売する商品の商品名や酒類の銘柄名および、その商品・銘柄に関連する情報や画像などが商品データ６２２として記憶されている。

図示しないが、その他業者端末１０６もメーカ端末１０５と端末と同様のハードウェア構成になっている。
その他業者端末１０６は、酒類などの商品の流通に関与する企業が使用する端末である。
主記憶装置には、在庫管理モジュール、商品管理モジュール、統合管理サーバ連携モジュール等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することでその他業者端末１０６の各機能要素が実現される。

図７～図９は、統合管理サーバ１０１の補助記憶装置２０２の企業横断マスタＤＢ２２２に記憶される各種テーブルの例である。
図７は、ユーザマスタテーブル７００の例である。
ユーザマスタテーブル７００は、ユーザ端末１０３を使用するユーザの情報を記憶している。
ユーザマスタテーブル７００は、管理システム全体で統一して使用されるマスタユーザＩＤ７０１の他、ユーザ名７０２、国籍７０３、性別７０４、生年月日７０５などの情報を有する。また、これら以外にも各ユーザがユーザ端末１０３のアプリケーションを利用するためのログインパスワードや住所情報、クレジットカード情報などの決済情報などを記憶していてもよい。

図８は、企業横断マスタＤＢ２２２に記憶されている銘柄マスタテーブル８００の例である。
銘柄マスタテーブル８００は、管理システム１で管理される酒類の銘柄及びその関連情報を管理するためのテーブルである。なお、図８は酒類を例として記載をしているが、これに限られるものではなく、その他の飲料や食品等でも実施が可能である。
銘柄マスタテーブル８００は、管理システム全体で統一して使用されるマスタ銘柄ＩＤ８０１の他、銘柄名８０２、カテゴリ８０３、親ブランド名８０４、ブランド名８０５、メーカ８０６、原産国８０７、地域８０８、蔵・醸造所８０９、原材料８１０、ラベル画像８１１、特徴情報８１２などの関連情報を記憶する。

特徴情報８１２は、それぞれの銘柄の画像から抽出された特徴情報であり、例えば、ボトルの形状、色、ラベルの形状、色、ラベルに記載されたロゴや文字の内容、形状、色、もしくは、これらの情報から特徴点を抽出した座標情報や位置情報、これらの情報のすべてまたは一部に特定のアルゴリズムで処理を施して抽出された数値情報やデータなどが考えられる。但しこれらに限定されるものではなく、酒類の銘柄を特定する際に比較対象になる情報であればよい。

銘柄マスタテーブル８００の情報は、流通企業端末１０２から受信する商品情報や販売実績情報に基づいて統合管理サーバ１０１のデータ突合モジュール２１２により追加、更新されるが、流通企業端末１０２の統合管理サーバ連携モジュールを介して流通企業端末１０２が自ら更新を行ってもよい。また、メーカ端末１０５の統合管理サーバ連携モジュール６１３を介してメーカ端末１０５が自ら更新を行ってもよい。

図９は企業横断マスタＤＢ２２２に記憶されている店舗マスタテーブル９００の例である。
店舗マスタテーブル９００は、管理システム１で管理される飲食店や小売店などの店舗情報及びその関連情報を管理するためのテーブルである。
店舗マスタテーブル９００は、管理システム全体で統一して使用されるマスタ店舗ＩＤ９０１の他、カテゴリ９０２、店舗名９０３、業態９０４、住所９０５、位置９０６、電話番号９０７などの関連情報を記憶する。

カテゴリ９０２は、店舗が飲食店か小売店を示す。業態９０４は飲食店等のジャンル等を示す。位置９０６は、緯度経度など地図上で店舗の位置を特定するための情報を示す。

店舗マスタテーブル９００の情報は、流通企業端末１０２から受信する店舗情報や販売実績情報に基づいて統合管理サーバ１０１のデータ突合モジュール２１２により追加、更新されるが、流通企業端末１０２の統合管理サーバ連携モジュール４１４を介して流通企業端末１０２が自ら更新を行ってもよい。また、店舗端末１０４の統合管理サーバ連携モジュール５１３を介して店舗端末１０４が自ら更新を行ってもよい。

図１０～図１２は、統合管理サーバ１０１の補助記憶装置２０２の解析データＤＢ２２１に記憶される各種テーブルの例である。
図１０は、ユーザ別登録銘柄テーブル１０００の例である。
ユーザ別登録銘柄テーブル１０００は、各ユーザ端末１０３から送られてきた酒類の銘柄を「飲みたい」または「飲んだ」情報や、評価、コメントなどを管理するためのテーブルである。

ユーザ別登録銘柄テーブル１０００は、マスタユーザＩＤ１００１、登録日１００２、マスタ銘柄ＩＤ１００３、位置付け１００４、評価コメント１００５、評価点１００６、登録場所１００７、投稿画像１００８、登録手段１００９、有効フラグ１０１０などの情報を有する。
マスタユーザＩＤ１００１とマスタ銘柄ＩＤ１００３には、企業横断マスタＤＢ２２２で管理されているユーザマスタテーブル７００と銘柄マスタテーブル８００で管理されているマスタのＩＤが記憶される。

位置付け１００４は、ユーザ端末１０３により登録されるその銘柄を「飲んだ」・「飲みたい」ことを示す情報、またはシステムがユーザの好み等によりレコメンデーションを行い登録される「おすすめ」が記憶される。

登録場所１００７は、飲食店／外／家など、情報を登録した場所が記憶される。飲食店の場合は店舗マスタテーブル９００の値が初期登録される。
登録手段１００９は、情報を登録した手段が記憶される。ユーザによるカメラスキャン経由、ユーザによるアプリ直接入力経由、システムの自動登録などが記憶される。

有効フラグ１０１０は、重複する情報などの無効データを管理するためのフラグである。例えば、ユーザＢが銘柄ＡＡ００２を２０１８年５月２３日に「飲みたい」と登録し（１０１１）、同じ銘柄ＡＡ００２を２０１８年６月６日に「飲んだ」場合には（１０１２）、「飲みたい」情報は古い情報であるため、有効フラグにＦＡＬＳＥを立てる。ＦＡＬＳＥが登録されている情報はその後の表示処理で画面に表示しない、などの処理を行うことができる。

なお、ユーザ別登録銘柄テーブル１０００と同様の情報はユーザ端末１０３のユーザ端末データ３２１にも記憶されており、ユーザ端末１０３の一覧表示モジュール３１３は、ユーザ端末データ３２１に基づいて登録した情報を、ユーザ端末１０３に表示することができる。

図１１は、店舗別取扱銘柄テーブル１１００の例である。
店舗別取扱銘柄テーブル１１００は、流通企業端末１０２から送られてきた販売実績データをもとに作成された、各店舗別にどの銘柄のお酒を置いてあるかを管理するためのテーブルである。

店舗別取扱銘柄テーブル１１００は、マスタ店舗ＩＤ１１０１、マスタ銘柄ＩＤ１１０２、登録手段１１０３、登録日１１０４、更新日１１０５、累積購買回数１１０６、平均購買頻度１１０７、取扱切れリスク１１０８などを記憶する。
マスタ店舗ＩＤ１１０１とマスタ銘柄ＩＤ１１０２には、企業横断マスタＤＢ２２２で管理されている店舗マスタテーブル９００と銘柄マスタテーブル８００で管理されているマスタのＩＤが記憶される。

登録手段１１０３は、「流通販売実績」「店舗申告」「ユーザ投稿」等が記載されている。流通企業端末１０２から受信した販売実績を整形した流通企業販売実績テーブル１６００に基づく情報には「流通販売実績」が記憶される。
店舗端末１０４の統合管理サーバ連携モジュール５１３による情報の登録・更新には、「店舗申告」が記憶される。
ユーザ端末１０３の銘柄登録モジュール３１１や銘柄スキャンモジュール３１２による情報の登録・更新には、「ユーザ投稿」が記憶される。

登録日１１０４には、情報が最初に登録された日付が記憶される。例えば、流通販売実績による登録では最古購買実績日、店舗申告による登録では申告日、ユーザ投稿による登録では初回投稿日が記憶される。
更新日１１０５には、各銘柄の情報が更新された日付が記憶される。例えば流通販売実績による登録では最新購買実績日、店舗申告による登録では最新申告日、ユーザ投稿による登録では最新投稿日が記憶される。

累積購買回数１１０６には、登録日１１０４から更新日１１０５までの累積の購買回数が記憶される。但し、別の実施形態として、購買した回数ではなく購買した酒類の本数で管理してもよい。
なお、累積での購買の「量」が分かれば良いのであって、上記の例だけに限定されるものではない、例えばこの他にも、累計の容量として「リットル」で管理したり樽の数で管理したりするなどでもよい。

平均購買頻度１１０７には、累積購買回数１１０６を登録日１１０４から更新日１１０５までの経過期間で割ったものが記載される。別の例として、回数ではなく累積購買数量１１０６を本数で管理する場合には、累積購買頻度１１０７は一月当たりの購買本数になる。但し、前述のとおり月当たりの購買容量（リットル／月）等でもよい。

取扱切リスク１１０８は、店舗での各銘柄の取扱い切れのリスクを表示する。取扱切れのリスクは、例えば平均購買頻度１１０７および最新の情報が登録されてからの経過期間に基づいて算出・評価される。

図１２は、銘柄解析テーブル１２００の例である。
銘柄解析テーブル１２００は、各銘柄の評価や人気度、希少度を記憶するためのテーブルである。
銘柄解析テーブル１２００は、マスタ銘柄ＩＤ１２０１、平均評価１２０２、飲みたい人の割合１２０３、飲んだ人の割合１２０５、飲食店の取扱率１２０７、小売店の取扱率１２０８などを記憶し、これらの値から人気度１２０４や希少度１２０６、１２０８、１２１０を計算し合わせて記憶する。

図１３～図１８は流通企業データの整形ＤＢ２２３に記憶される各種テーブルの例である。
流通企業各社（図１の企業Ｐ、企業Ｑ、企業Ｒ）はそれぞれ各社独自のフォーマットや順番、内容で商品や顧客店舗、販売実績を管理している。これらの流通企業端末１０２から受領したそれぞれの情報を、データ整形モジュール２１１が整形して、共通のフォーマットにしたものが、図１３～図１６として流通企業データの整形ＤＢ２２３に記憶されている。各社の情報を共通のフォーマットのテーブルに格納することで、複数の流通企業の情報を統合した各種データ解析を行うことが可能となる。解析済みデータは解析データＤＢ２２１に記憶され、ユーザ端末１０３他に提供される。

流通企業データの整形ＤＢ２２３に記憶されている共通のフォーマットにした販売実績情報（販売実績と対応付けられている商品情報や店舗情報、担当者情報を含んでもよい）は、まとめて共通販売実績情報と呼ぶこともある。共通販売実績情報というときには、流通企業データの整形ＤＢ２２３に記憶される図１３～図１６のような各種テーブルをすべて含む概念である。

図１３は、流通企業商品テーブル１３００の例である。
流通企業商品テーブル１３００は、各流通企業の取扱う商品および商品に関連する情報を管理するためのテーブルである。
流通企業商品テーブル１３００は、企業ＩＤ１３０１、商品ＩＤ１３０２、商品名１３０４、メーカ１３０５、カテゴリ１３０６等の商品に関する情報を記憶する。

企業ＩＤ１３０１は、図１の流通企業である企業Ｐ、企業Ｑ、企業Ｒなどを特定するＩＤである。
商品ＩＤ１３０２は、流通企業側で管理されているＩＤである。統合管理サーバ１０１の企業横断マスタＤＢ２２２の銘柄マスタテーブル８００のマスタ銘柄ＩＤ８０１とは、銘柄マスタ紐付けテーブル１７００により紐付けされている。

図１４は、流通企業店舗テーブル１４００の例である。
流通企業店舗テーブル１４００は、各流通企業の取引先の飲食店や小売店などの店舗および店舗に関連する情報を管理するためのテーブルである。
流通企業店舗テーブル１４００は、企業ＩＤ１４０１、店舗ＩＤ１４０２、店舗名１４０４、業態１４０５、住所１４０６、電話番号１４０７、担当者ＩＤ１４０８などの店舗に関する情報を記憶する。

店舗ＩＤ１４０２は、流通企業側で管理されているＩＤである。統合管理サーバ１０１の企業横断マスタＤＢ２２２の店舗マスタテーブル９００のマスタ店舗ＩＤ９０１とは、店舗マスタ紐付けテーブル１８００により紐付けされている。

図１５は、流通企業担当者テーブル１５００の例である。
流通企業担当者テーブル１５００は、各流通企業の取引先の担当者の情報を管理するためのテーブルである。
流通企業担当者テーブル１５００は、企業ＩＤ１５０１、担当者ＩＤ１５０２、担当者名１５０３、認証情報１５０４等の担当者に関連する情報を記憶する。

各担当者は、ここに記録された認証情報１５０４に基づいて、統合管理サーバ連携モジュール４１４にログインし、統合管理サーバ１０１との間でデータの送受信を行ったり、解析結果を受領したり、企業横断マスタＤＢ２２２の情報を書き換えたりする。

図１６は、流通企業販売実績テーブル１６００の例である。
流通企業販売実績テーブル１６００は、各流通企業の販売実績を管理するためのテーブルである。
流通企業販売実績テーブル１６００は、企業ＩＤ１６０１、受注日１６０２、商品ＩＤ１６０３、マスタ銘柄ＩＤ１６０４、店舗ＩＤ１６０５、マスタ店舗ＩＤ１６０６、受注数量１６０７、受注額１６０８、有効フラグ１６０９などの販売実績に関連する情報を記憶する。

受注日１６０２には、商品を受注した日付が記載され、基本的には本販売実績テーブルは、受注が発生するたびにレコードを追記していく。
企業ＩＤ１６０１や商品ＩＤ１６０３は流通企業側で管理されているＩＤであり、マスタ銘柄ＩＤ１６０４には、同じ商品と紐づけられた統合管理サーバ１０１の企業横断マスタＤＢ２２２の銘柄マスタテーブル８００のマスタ銘柄ＩＤ８０１が格納される。また、マスタ店舗ＩＤ１６０６には、同じ店舗と紐づけられた統合管理サーバ１０１の企業横断マスタＤＢ２２２の店舗マスタテーブル９００のマスタ店舗ＩＤ９０１が格納される。

なお、商品ＩＤ１６０３とマスタ銘柄ＩＤ１６０４は両方を持っていなければならないわけではなく、図１７の銘柄マスタ紐付けテーブル１７００のような対応付けがなされていればいずれかの情報のみでもよい。
同様に、店舗ＩＤ１６０５とマスタ店舗ＩＤ１６０６は両方を持っていなければならないわけではなく、図１８の店舗マスタ紐付けテーブル１８００のような対応付けがなされていればいずれかの情報のみでもよい。
有効フラグ１６０９は、レコードの有効無効を記憶するフラグである。受注取り消しなど無効なデータにはＦＡＬＳＥが記憶される。

図１７は、銘柄マスタ紐付けテーブル１７００の例である。
銘柄マスタ紐付けテーブル１７００は、企業横断マスタＤＢ２２２に格納される流通企業商品テーブル１３００の各企業ごとに使用される各社固有の商品ＩＤ１３０２と、銘柄マスタテーブル８００のマスタ銘柄ＩＤ８０１と、を対応付けて記憶している。
この銘柄マスタ紐付けテーブル１７００の情報をたどることにより、データ突合処理２０００の際に流通企業販売実績テーブルの商品ＩＤ１６０３と対応付けてマスタ銘柄ＩＤ１６０４を記憶することができる。

図１８は、店舗マスタ紐付けテーブル１８００の例である。
店舗マスタ紐付けテーブル１８００は、企業横断マスタＤＢ２２２に格納される流通企業店舗テーブル１４００の各企業ごとに使用される各社固有の店舗ＩＤ１４０２と、店舗マスタテーブル９００のマスタ店舗ＩＤ９０１と、を対応付けて記憶している。
この店舗マスタ紐付けテーブル１８００の情報をたどることにより、データ突合処理２０００の際に流通企業販売実績テーブルの店舗ＩＤ１６０５と対応付けてマスタ店舗ＩＤ１６０６を記憶することができる。

図１９～図２５は管理システム１で実施される各種処理のフローを示す。
図１９は統合管理サーバ１０１のデータ整形モジュール２１１が実施するデータ整形処理フロー１９００の例である。

データ整形モジュール２１１は、流通企業端末１０２から販売実績情報や商品情報、顧客店舗情報などの物流データを受領する（ステップ１９１０）。受領したデータは、流通企業各社（図１の企業Ｐ、企業Ｑ、企業Ｒ）それぞれ独自のフォーマットや順番、内容により商品や顧客店舗、販売実績が記憶されている。
当該モジュールは、受領したデータを流通企業データの受領ＤＢ２２４に格納する（ステップ１９２０）。

当該モジュールは、受領したデータのカラムを並べ替えたり、情報を置き替えたりすることにより、流通企業データの整形ＤＢ２２３の流通企業商品テーブル１３００、流通企業店舗テーブル１４００、流通企業販売実績テーブル１６００等の各社共通のフォーマット（テーブル構造）に整形する（ステップ１９３０）。つまり、これらの各種テーブル構造に合致するように、受領したデータを新たなレコードとして追加する。

そして、当該モジュールは、整形済みのデータを流通企業データの整形ＤＢ２２３に格納する（ステップ１９４０）。
その後、データ突合モジュール２１２が突合処理を行う。突合処理では整形済みの各テーブルのレコードに対し、データ突合処理を行い、名寄せをすることで、企業横断マスタＤＢ２２２のマスタＩＤが挿入される（ステップ１９５０）。

図２０は、流通企業端末１０２から受信した情報を整形した流通企業販売実績テーブル１６００に対して、企業横断マスタＤＢ２２２の情報を突合するデータ突合処理フロー２０００の例である。

データ突合モジュール２１２は、流通企業データの整形ＤＢ２２３の流通企業販売実績テーブル１６００と、企業横断マスタＤＢ２２２の銘柄マスタテーブル８００の情報とを突合する（ステップ２０１０）。この際、銘柄マスタ紐付けテーブル１７００も併せて参照される。

当該モジュールは、流通企業販売実績テーブル１６００の商品と対応するマスタ銘柄ＩＤが存在するかどうかを確認する。つまり、商品ＩＤ１６０３に関連付けられた流通企業商品テーブル１３００の商品に、銘柄マスタテーブル８００で管理される銘柄に対応するものがあるかどうかを判定する（ステップ２０２０）。

例えば、流通企業商品テーブル１３００の商品名やメーカ名、カテゴリなどの商品に関連する情報で銘柄マスタテーブル８００を検索し、類似する商品・銘柄があればそのマスタ銘柄ＩＤを取得する。この判定は、銘柄名が完全に一致する場合だけでなく、類似度が高いものがあればそれを取得することとしてよい。また、テーブルのキーワード検索による一致や類似の検索で類似の商品・銘柄を特定してもよいし、ＡＩや機械学習、ディープラーニングによる反復演算等により、銘柄マスタテーブル８００の情報と、流通企業商品テーブル１３００の情報とを突合し、類似するものを抽出してもよい。

なお、流通企業商品テーブル１３００のような流通企業の商品マスタ情報は必須の構成ではなく、流通企業で管理されている商品の情報がそのまま販売実績情報に記入されている場合もある。このような場合には、販売実績情報に記入された商品に関する情報と、銘柄マスタテーブル８００の情報とを突合する。
また、銘柄マスタ紐付けテーブル１７００のような対応情報を持つ場合には、商品ＩＤ１６０３の情報が既に銘柄マスタ紐付けテーブル１７００に登録されているか確認するだけでよい。

対応するマスタ銘柄ＩＤが存在した場合には、データ突合モジュール２１２は、流通企業販売実績テーブル１６００の該当レコードに、マスタ銘柄ＩＤの値を挿入する（ステップ２０４０）。

対応するマスタ銘柄ＩＤが存在しなかった場合には、データ突合モジュール２１２は、銘柄マスタテーブル８００に新たなマスタ銘柄ＩＤを追加し（ステップ２０３０）、流通企業商品テーブル１３００の該当する商品情報を対応付けて格納する（ステップ２０３５）。
また、当該モジュールは、マスタ情報として不足する情報があれば、メーカ端末１０５に問い合わせを行う、もしくはインターネットを検索する等の処理により、不足する情報を取得・補完し、銘柄マスタテーブル８００に格納してもよい。

当該モジュールは、ラベル画像についても同様に取得・格納し、ラベル画像等に基づいて、商品や銘柄を特定するために使用される特徴情報を生成し、合わせて格納してもよい。
特徴情報は、例えば銘柄の全体画像やラベル画像から抽出された特徴情報であり、例えば、ボトルの形状、色、ラベルの形状、色、ラベルに記載されたロゴや文字の内容、形状、色、もしくは、これらの情報から特徴点を抽出した座標情報や位置情報、これらの情報のすべてまたは一部に特定のアルゴリズムで処理を施して抽出された数値情報やデータなどが考えられる。但しこれらに限定されるものではなく、酒類の銘柄を特定する際に比較対象になる情報であればよい。

データ突合モジュール２１２は、追加された新たなマスタ銘柄ＩＤを流通企業販売実績テーブル１６００に記憶する（ステップ２０４０）。
また、銘柄マスタ紐付けテーブル１７００のような対応情報を持つ場合には、追加された新たなマスタ銘柄ＩＤを商品ＩＤ１７０４と対応付けて記憶する。

次に、データ突合モジュール２１２は、流通企業ＤＢ２２３の流通企業販売実績テーブル１６００と、マスタＤＢ２２２の店舗マスタテーブル９００の情報とを突合する（ステップ２０５０）。この際、店舗マスタ紐付けテーブル１８００も併せて参照される。
当該モジュールは、流通企業販売実績テーブル１６００の店舗と対応するマスタ店舗ＩＤが存在するかどうかを確認する。つまり、店舗ＩＤ１６０５に関連付けられた流通企業店舗テーブル１４００の店舗に、店舗マスタテーブル９００で管理される店舗に対応するものがあるかどうかを判定する（ステップ２０６０）。

例えば、流通企業店舗テーブル１４００の店舗名や業態、住所、電話番号などの店舗に関連する情報で店舗マスタテーブル９００を検索し、類似する店舗があればそのマスタ店舗ＩＤを取得する。この判定は、店舗名が完全に一致する場合だけでなく、類似度が高いものがあればそれを取得することとしてよい。また、テーブルのキーワード検索による一致や類似の検索で類似の店舗を特定してもよいし、ＡＩや機械学習、ディープラーニングによる反復演算等により、店舗マスタテーブル９００の情報と、流通企業店舗テーブル１４００の情報とを突合し、類似するものを抽出してもよい。

なお、流通企業店舗テーブル１４００のような流通企業の店舗マスタ情報は必須の構成ではなく、流通企業で管理されている店舗の情報がそのまま販売実績情報に記入されている場合もある。このような場合には、販売実績情報に記入された店舗に関する情報と、銘柄マスタテーブル９００の情報とを突合する。
また、店舗マスタ紐付けテーブル１８００のような対応情報を持つ場合には、店舗ＩＤ１６０５の情報が既に店舗マスタ紐付けテーブル１８００に登録されているか確認するだけでよい。

対応するマスタ店舗ＩＤが存在した場合には、データ突合モジュール２１２は、流通企業販売実績テーブル１６００の該当レコードに、マスタ店舗ＩＤの値を挿入する（ステップ２０８０）。

対応するマスタ店舗ＩＤが存在しなかった場合には、データ突合モジュール２１２は、店舗マスタテーブル９００に新たなマスタ店舗ＩＤを追加し（ステップ２０７０）、流通企業店舗テーブル１４００の該当する店舗情報を対応付けて格納する（ステップ２０７５）。
また、当該モジュールは、マスタ情報として不足する情報があれば、店舗端末１０４に問い合わせを行う、もしくはインターネットを検索する等の処理により、不足する情報を取得・補完し、店舗マスタテーブル９００に格納してもよい。

データ突合モジュール２１２は、追加された新たなマスタ店舗ＩＤを流通企業販売実績テーブル１６００に記憶する（ステップ２０８０）。
また、店舗マスタ紐付けテーブル１８００のような対応情報を持つ場合には、追加された新たなマスタ店舗ＩＤを店舗ＩＤ１８０４と対応付けて記憶する。

なお、データ突合モジュール２１２は、流通企業端末１０２等と連携し、流通企業販売実績テーブルのレコードに記憶された受注が有効かどうかを判別する。
受注が有効であれば有効フラグ１６０９をＴＲＵＥに設定し、受注が有効でなければ有効フラグをＦＡＬＳＥに設定する
この処理により、正式に受注が有効な取引の情報のみを後のデータ解析等で使用することができる。

図２１は、流通企業販売実績テーブル１６００に基づいて各店舗別に取り扱っている酒類の銘柄の状況を解析し、解析データＤＢ２２１の店舗別取扱銘柄テーブル１１００を生成するデータ解析処理フロー２１００の例である。
統合管理サーバ１０１のデータ解析モジュール２１５は、流通企業販売実績テーブル１６００から、解析対象のマスタ店舗ＩＤを有するレコードの情報をすべて取得する（ステップ２１１０）。

当該モジュールは、取得されたレコードの情報にマスタ銘柄ＩＤが同一のものがあれば、受注回数を累積購買回数に加算する（ステップ２１２０）。図１１の店舗別取扱銘柄テーブル１１００の例では、店舗Ｋで取扱われている銘柄一覧が生成され、それぞれの銘柄の累積購買回数１１０６が計算されている。
なお、店舗別取扱銘柄テーブル１１００にすでに登録日・更新日が格納されている場合には、差分の購買回数のみをカウントすればよいため、この最新の更新日以降の受注回数を累積購買回数に加算する。

当該モジュールは、累積購買回数に受注回数が加算されたレコードの受注日１６０２の
情報で、店舗別取扱銘柄テーブル１１００の更新日１１０５をアップデートする（ステップ２１３０）。
当該モジュールは、すべての流通企業について処理が完了したかを判定する（ステップ２１４０）。すべての流通企業について処理が完了していない場合には、流通企業販売実績テーブル１６００の企業ＩＤ１６０１すべてについて処理が終わるまで同様の処理を繰り返す（ステップ２１５０）。この処理により、複数の流通企業Ｐ、Ｑ、Ｒから取得した商品情報、店舗情報、販売実績情報などの物流データを統合した、店舗Ｋに対する取扱銘柄のリストを生成することが可能となる。

なお、店舗別取扱銘柄テーブル１１００の情報を、上記のような流通販売実績に基づいて生成した場合には、データ解析モジュール２１５は、登録手段１１０３に「流通販売実績」を設定する。
登録手段１１０３には、店舗端末１０４の統合管理サーバ連携モジュール５１３によりデータが登録・更新された場合には、「店舗申告」が設定される。ユーザ端末１０３の銘柄登録モジュール３１１や銘柄スキャンモジュール３１２によりデータが登録・更新された場合には、「ユーザ投稿」が設定される。

続いて、データ解析モジュール２１５は、累積購買回数１１０６を登録日１１０４から更新日１１０５の間の経過時間で割ることにより、平均購買頻度１１０７を計算する（ステップ２１６０）。登録日１１０４から更新日１１０５までの間の経過時間ではなく、登録日１１０４から現在までの経過時間を用いてもよい。

データ解析モジュール２１５は、平均購買頻度１１０７と更新日１１０５（つまり前回受注日）から現在までの経過時間に基づいて、取扱切リスク１１０８を算出・記憶する（ステップ２１７０）。例えば、平均購買頻度１１０７の逆数(つまり銘柄１回分の注文の消費に費やす月数)と、経過時間を比較することで取扱切リスク１１０８を計算する。
例えば、以下のような判定により取扱い切れのリスクを決定することができる。
経過期間が１回分の注文の消費に係る月数を超えている場合には、取扱切リスクを高とする。
経過期間が同月数の半分未満の場合にはリスク低とする。
経過期間が同月数の半分以上だが同月数を超えていない場合にはリスク中とする。
また、別途１年以上経過している場合にはリスク高とする。

なお、取扱切リスク１１０８は、店舗端末１０４の統合管理サーバ連携モジュール５１３により、更新することが可能であり、店舗側で当該お酒の銘柄を消費し切っていると判定した場合には、「取扱終了確定」に書き換えることができる。

データ解析モジュール２１５は、すべてのマスタ店舗ＩＤ１６０４について処理が完了したかを判定する（ステップ２１８０）。すべての店舗について処理が完了していない場合には、流通企業販売実績テーブル１６００のマスタ店舗ＩＤすべてについて処理が終わるまで同様の処理を繰り返す（ステップ２１９０）。この処理により、複数の流通企業Ｐ、Ｑ、Ｒから取得した商品情報、店舗情報、販売実績情報などの物流データ（販売実績情報）を統合して、店舗ごとに取扱銘柄のリストを生成することが可能となり、また取扱切れリスクを推計し表示することができる。

図２２は、ユーザ端末１０３の銘柄登録モジュール３１１が酒類に関するユーザの情報を登録する銘柄登録処理フロー２２００の例である。
図２９は銘柄登録処理の際にディスプレイに表示される画面２９００の例である。
酒類情報管理アプリがユーザから銘柄登録の指示を受け付けると、銘柄登録モジュール３１１が処理を開始する。例えば図２９の画面例における画面中央下のプラスマーク２９０１がタップされると銘柄登録モジュール３１１が起動し、処理を開始する。

銘柄登録モジュール３１１は、図２９の画面下の「飲んだ銘柄を登録」ボタン２９０２及び「飲みたい銘柄を登録」ボタン２９０３を表示し、ユーザからの「飲んだ銘柄登録」または「飲みたい銘柄登録」の選択を受け付ける（ステップ２２１０）。画面の背景にはカメラ部３０７が撮像している画像２９０４が表示されている（ステップ２２２０）。
ボタンの選択は、それぞれのボタンがタップされることを検知して選択受付としてもよいし、図２９のプラスマークをタップして各ボタンを表示し、左右のボタンの方向にフリックやスワイプすることを検知して、左右いずれかのボタンの選択受付としてもよい。

銘柄登録モジュール３１１は、表示されている画像を解析し、お酒に関連する部分を検出しハイライト表示する（ステップ２２３０）。例えば、お酒のボトルの形状、色彩、ラベルの形状、色彩、などを検出することで当該部分をお酒の候補としてハイライト表示する。
当該モジュールは、ユーザからの画像取込指示を受け付ける（ステップ２２４０）。例えば、図２９の画面中央下のプラスマーク２９０１の画像取込ボタンのタップや、ハイライト部分２９０５や２９０６のタップなどを画像取込指示と判断する。

当該モジュールは、銘柄判定のために選択された部分の画像を切り抜き、画像情報を統合管理サーバ１０１へ送信する（ステップ２２５０）。
図２９のように複数のお酒が画面上に写っており、ハイライト部分が複数ある場合であって、プラスマーク２９０１のタップによる画像取込指示を受け付けた場合には、複数のハイライト部分の画像を切り抜き、その後にユーザから画像の選択を受け付ければよい。
複数のハイライト部分から一つのハイライト部分がタップされた場合には、当該ハイライト部分の画像を切り抜けばよい。

なお、切り抜く画像は、お酒の銘柄を判別するのに十分な情報であればよく、例えばラベル部分の画像だけでもよいし、ラベルの中のロゴや名前などの一部分であってもよいし
、ボトル全体の画像でもよい。回線の容量を気にしなくて良い等の場合には、切り抜くことなく撮影画像をそのまま統合管理サーバ１０１に送信してもよい。

画像の送付を受けた統合管理サーバ１０１の銘柄判定モジュール２１４は、受領した画像に写っているお酒の銘柄を判定し、判定結果及び判定された銘柄に関連する付加情報をユーザ端末１０３に送付する（ステップ２２６０）。
ユーザ端末１０３の銘柄登録モジュール３１１は、受領した判定結果及び付加情報をディスプレイ３０５等に表示する（ステップ２２７０）。

当該モジュールは、ユーザから飲んだ銘柄についての評価やコメント、登録場所の店舗名の選択など関連情報の入力を受け付ける（ステップ２２８０）。
当該モジュールは、撮影された画像、判定された銘柄ＩＤまたは銘柄名等の銘柄を特定する情報、銘柄に関連する例えば評価、コメント、店舗名等の情報を合わせてユーザ記憶装置のユーザ端末データ３２１および統合管理サーバ１０１の解析ＤＢのユーザ別登録銘柄テーブル１０００に記憶する（ステップ２２９０）。

当該モジュールは、「飲んだ銘柄を登録」２９０２が選択された場合には、ユーザ別登録銘柄テーブル１０００の「位置付け」１００４として「飲んだ」を設定し、「飲みたい銘柄を登録」２９０３が選択された場合には、「位置付け」１００４として「飲みたい」を設定する。
「登録場所」１００７には、銘柄登録を行った場所のＧＰＳ情報などから特定した場所や店舗名や店舗ＩＤ等が記憶される。店舗名や店舗ＩＤはＧＰＳにより取得された位置情報を店舗マスタテーブル９００の位置情報９０６と比較することで取得することができる。まだ未登録の店舗については、位置情報のみ記憶するか、ユーザに記入してもらってもよい。

図２３は、統合管理サーバ１０１の銘柄判定モジュール２１４が実行する銘柄判定処理フロー２３００の例である。
銘柄判定モジュール２１４は、ユーザ端末１０３からお酒に関する部分の画像関連情報を受信する（ステップ２３１０）。
当該モジュールは、画像関連情報の中の特徴情報を抽出する（ステップ２３２０）。

特徴情報は、例えば、ボトルの形状、色、ラベルの形状、色、ラベルに記載されたロゴや文字の内容、形状、色、もしくは、これらの情報から特徴点を抽出した座標情報や位置情報、これらの情報のすべてまたは一部に特定のアルゴリズムで処理を施して抽出された数値情報やデータなどが考えられる。但しこれらに限定されるものではなく、酒類の銘柄を特定する際に比較対象になる情報であればよい。

当該モジュールは、銘柄マスタテーブル８００の特徴情報８１２との比較を行い、類似する特徴情報を持つ銘柄があるかどうかを判定する（ステップ２３３０）。
類似する特徴情報が見つからない場合には、該当する銘柄情報がない旨の判定結果を生成する（ステップ２３４０）。

類似する特徴情報が見つかった場合には、最も類似する特徴情報を持つレコードの銘柄を特定する（ステップ２３５０）。
特定した銘柄に対応する銘柄マスタテーブル８００の情報を付加情報として取得する（ステップ２３６０）。また、特定した銘柄のマスタ銘柄ＩＤを持つ銘柄解析テーブル１２００の情報を付加情報として取得してもよい。

銘柄判定モジュール２１４は、判定結果及び付加情報を特定された銘柄に関する情報としてユーザ端末１０３に送信する（ステップ２３７０）。判定結果としては特定した銘柄名やマスタ銘柄ＩＤ等の銘柄を特定する情報や、該当する銘柄がない場合にはその旨が送信される。

なお、本管理システム１では、お酒のボトルの写真だけでなく、雑誌の記事や、メールやインターネットで配信されるテキスト情報などに含まれる酒類に関する情報も「飲みたい銘柄を登録」ボタンで取り込み、飲みたい銘柄として登録することができる。

例えば図３３の例のような雑誌の記事の場合には、雑誌の記事の関連する部分を撮影することで、この画像３３０４を統合管理サーバ１０１の銘柄判定処理でＯＣＲ等の文字認識処理を施し、認識されたテキスト中のお酒に関する銘柄名や、カテゴリ、ブランド名、メーカ、蔵・醸造所等の情報を検出する。
検出されたお酒に関する内容が記載された部分は、３３０６の下線や破線枠のようにユーザ端末の画像３３０４の上に重ねてハイライトして表示することができる。

検出されたお酒に関する内容は、銘柄マスタテーブル８００と照合することで、銘柄を特定する。
特定された銘柄に関する情報は、３３０５のようにユーザ端末の画像３３０４の上に重ねて表示することができる。

ユーザから銘柄登録ボタン３３０１、「飲んだ銘柄を登録」ボタン３３０２、「飲みたい銘柄を登録」ボタン３３０３などの選択を受け付けると、「飲んだ」「飲みたい」の情報と共に、特定された銘柄情報を登録する。

なお、ＯＣＲ処理や、画像の中のお酒に関する内容の検出を統合管理サーバ１０１ではなく、ユーザ端末１０３側で実施してしまってもよい。この場合、ユーザ端末は、銘柄判定のために検出された部分の画像だけを統合管理サーバ１０１に送信してもよいし、ＯＣＲ処理後のテキスト情報のみを画像の代わりに送信してもよい。

メールやインターネットで配信されるテキスト情報の場合は、ユーザ端末１０３の銘柄登録モジュール３１１は、お酒に関する部分のテキストの選択を受け付け、もしくはテキスト情報全体を、画像の代わりに統合管理サーバ１０１に送信する。
統合管理サーバ１０１の銘柄判定モジュール２１４は送信されたテキストの文字列中のお酒に関する銘柄名や、カテゴリ、ブランド名、メーカ、蔵・醸造所等の情報を、銘柄マスタテーブル８００と照合することで、飲みたい銘柄を特定して登録する。
これらの画像やテキストの照合・類似度判定にはＡＩ、機械学習、ディープラーニング等の反復計算を用いることもできる。

なお、本実施例では、画像の切り抜きまでをユーザ端末１０３で行い、切り抜かれた画像からの特徴情報抽出および銘柄マスタテーブル８００との比較を統合管理サーバ１０１で行うこととしたが、特徴情報の抽出までをユーザ端末１０３の銘柄登録モジュール３１１が実施し、統合管理サーバ１０１の銘柄判定モジュール２１４は、抽出・送付された特徴情報と銘柄マスタテーブル８００の特徴情報とを比較する、という構成にしてもよい。

つまり、統合管理サーバ１０１は画像関連情報を受信して、銘柄判定モジュールにより判定処理を行うが、この画像関連情報としては、撮像されている画像全体、その画像から切り抜かれた部分画像、これらの画像のすべてまたは一部を処理することにより抽出された特徴情報、画像を解析することで得られた文字列情報、などをすべて含む。

画像の一部抽出や特徴抽出などの前処理をできる限りユーザ端末１０３側で実施することで、統合管理サーバ１０１に送信するデータ量を減少させることができる。
なお、ユーザ端末１０３のマシンスペックが高い場合には、銘柄判定処理のすべてをユーザ端末１０３の中で実施する構成としてもよい。この場合には、図８の銘柄マスタテーブルのラベル画像８１１や特徴情報８１２のような判定のために比較する情報はユーザ端末１０３の補助記憶手段３０２に記憶させておけばよい。

また、メジャーな銘柄についての銘柄情報や比較情報はユーザ端末１０３に記憶しておき、ユーザ端末１０３の銘柄判定モジュールで銘柄判定及び表示を行うことで、メジャーな酒類の銘柄についてはユーザ端末１０３で処理を完結する。一方メジャーな酒類の銘柄として判定できず判定銘柄がでてこなかったものについては、統合管理サーバ１０１に問い合わせて、統合管理サーバの銘柄判定モジュールで銘柄判定処理を行う、というハイブリッド構成としてもよい。

図２４は、統合管理サーバ１０１のデータ解析モジュール２１５が実施する銘柄解析処理フロー２４００の例である。
データ解析モジュール２１５は、ユーザ別登録銘柄テーブル１０００から、解析を行いたい銘柄のマスタ銘柄ＩＤ１００３を有するレコードの情報をすべて取得する（ステップ２４１０）。

当該モジュールは、その銘柄について評価を行った全ユーザの平均評価値を計算し、銘柄解析テーブル１２００の平均評価に記憶する（ステップ２４２０）。

次に、当該モジュールは、ユーザ別登録銘柄テーブル１０００のすべてのユーザの情報を確認し、位置付け１００４に「飲みたい」が記憶されているその銘柄を飲みたいユーザの数を総計する。そしてその値を全ユーザ数で割ることで、その銘柄を飲みたい人の割合を計算し、計算結果を銘柄解析テーブル１２００の飲みたい人の割合１２０３に記憶する（ステップ２４３０））。

次に、当該モジュールは、飲みたい人の割合からその銘柄についての「人気度」を計算する（ステップ２４３５））。
人気度は、例えば飲みたい人の割合が大きい順に並べた場合の分布から分類することができる。例えば図３４の例のように「飲みたい」が記憶されている銘柄の中から銘柄数が均等になるように３分割で「高」「中」「低」の３つに分けて登録する（３４０１、３４０２、３００３）。「飲みたい」が全く登録されていない銘柄３４０４については、人気度「低」としてもよいし、情報無しとして人気度「－」を設定してもよい。
なお、縦軸は、飲みたい人の割合だけではなく、「飲みたい人」に「飲んだ人の評価」を掛け合わせた指数を縦軸として人気度を計算してもよい。

次に、当該モジュールは、すべてのユーザの情報を確認し、位置付け１００４に「飲んだ」が記憶されているその銘柄を飲んだユーザの数を総計する。そしてその値を全ユーザ数で割ることで、その銘柄を飲んだ人の割合を計算し、計算結果を銘柄解析テーブル１２００の飲んだ人の割合１２０５に記憶する（ステップ２４４０）。

次に、当該モジュールは、飲んだ人の割合からその銘柄についての「希少度」を計算する（ステップ２４４５）。
希少度は、例えば飲んだ人の割合が大きい順に並べた場合の分布から分類することができる。例えば図３５の例のように、「飲んだ」が記憶されている銘柄の中から、その飲んだ人の総数が均等になるように３分割で「低」「中」「高」の３つに分けて希少度１として登録する（３５０１、３５０２、３５０３）。
この場合に、飲んだ人の数が極端に少ない場合には、希少度が高いわけではなく、情報が登録されていないだけの可能性が高いため、飲んだ人の数が所定の数や割合以下（例えば１００人や０．１％）以下の場合は（３５０６）、希少度の評価対象外３５０４として図１２の銘柄解析テーブル１２００の希少度に「－」を記憶する。

次に、当該モジュールは、店舗別取扱銘柄テーブル１１００から解析を行いたい銘柄のマスタ銘柄ＩＤを有するレコードの情報をすべて取得する（ステップ２４５０）。
当該モジュールは、このマスタ銘柄ＩＤのお酒を、所定の期間以降（例えば直近１年間）に購入した飲食店舗数を総計する。そしてその値を全飲食店の店舗数で割ることで、直近１年間での飲食店の取扱率を計算し、計算結果を銘柄解析テーブル１２００の飲食店の取扱率に記憶する（ステップ２４６０）。

当該モジュールは、飲食店の取扱率からその銘柄についての「希少度」を計算する（ステップ２４６５）。
希少度は、図３５の例と同様に飲食店の取扱率が大きい順に並べた場合の分布から例え
ば３段階で「低」「中」「高」の３つに分けて希少度２として登録する。
この場合に、飲食店の取扱率が極端に少ない場合には、希少度が高いわけではなく、情報が登録されていないだけの可能性もあるため、このお酒を取り扱う飲食店の数が所定の数や割合（例えば１０店舗や０．１％）以下の場合は、希少度の評価対象外として図１２の銘柄解析テーブル１２００に「－」を記憶する。

なお、この例では、直近１年間での飲食店の取扱率を使用したが、所定の期間は他の期間でもよく、直近１月間とすれば、直近１月間での飲食店の取扱率を計算することができる。また今までの全期間としてもよい。
また、これらの情報を切り替えて表示できることとすれば、直近１年間、半年、１月それぞれでの飲食店の取扱率や希少度を期間ごとに表示することも可能となる。

次に、当該モジュールは、このマスタ銘柄ＩＤのお酒を、所定の期間以降（例えば直近１年間）に購入した小売店舗数を総計する。そしてその値を全小売店の店舗数で割ることで、直近１年間での小売店の取扱率を計算し、計算結果を銘柄解析テーブル１２００の小売店の取扱率に記憶する（ステップ２４７０）。

当該モジュールは、小売店の取扱率からその銘柄についての「希少度」を計算する（ステップ２４７５）。
希少度は、図３５の例と同様に小売店の取扱率が大きい順に並べた場合の分布から例えば３段階で「低」「中」「高」の３つに分けて希少度３として登録する。
この場合に、小売店の取扱率が極端に少ない場合には、希少度が高いわけではなく、情報が登録されていないだけの可能性もあるため、このお酒を取り扱う小売店の数が所定の数や割合（例えば１０店舗や０．１％）以下の場合は、希少度の評価対象外として図１２の銘柄解析テーブル１２００に「－」を記憶する。

なお、この例では、直近１年間での小売店の取扱率を使用したが、所定の期間は他の期間でもよく、直近１月間とすれば、直近１月間での小売店の取扱率を計算することができる。また今までの全期間としてもよい。
また、これらの情報を切り替えて表示できることとすれば、直近１年間、半年、１月それぞれでの小売店の取扱率や希少度を期間ごとに表示することも可能となる。

なお、店舗別取扱銘柄テーブル１１００において、各店舗が飲食店か小売店かは、店舗マスタテーブル９００をマスタ店舗ＩＤ９０１をキーにして検索し、対応するカテゴリ９０２の情報を見ることで判別できる。

人気度や希少度の分類は、各銘柄を飲みたい人、飲んだ人、取り扱う飲食店、小売店などの数の分布や偏差によって分類してもよいし、単純に上位１０銘柄を人気度や希少度「高」として分類するなどとしてもよい。

データ解析モジュール２１５は、すべてのマスタ銘柄ＩＤ１００３について処理が終わるまで、銘柄解析処理を繰り返す。当該処理がすべて終わると、図１２の銘柄解析テーブル１２００が更新される。

図２５は、ユーザ端末１０３の銘柄スキャンモジュール３１２が実行する銘柄スキャン処理フロー２５００の例である。
図３１～図３３は銘柄スキャン処理の際にユーザ端末１０３のディスプレイ３０５に表示される画面の例である。
酒類情報管理アプリがユーザから銘柄スキャンの指示を受け付けると、銘柄スキャンモジュール３１２が処理を開始する（ステップ２５１０）。例えば図３１の画面例における画面右上の「銘柄スキャン」ボタン３１１０がタップされると銘柄スキャンモジュール３１２が起動し、処理を開始する。

銘柄スキャンモジュール３１２は、図３１のようにカメラ部３０７の撮像画像３１１１をディスプレイ３０５に表示する（ステップ２５２０）。
当該モジュールは、画像を解析し、お酒に関する部分を検出する（ステップ２５３０）。例えば、お酒のボトルの形状、色彩、ラベルの形状、色彩、などを検出することで当該部分をお酒の候補として検出する。
当該モジュールは、銘柄判定のために検出した画像情報を統合管理サーバ１０１に送信する(ステップ２５４０)。

統合管理サーバ１０１の銘柄判定モジュール２１４は、受信した画像情報を解析し、写っている酒類の銘柄を判定し、判定結果及び付加情報をユーザ端末１０３に返信する（ステップ２５５０）。

銘柄スキャンモジュール３１２は判定結果及び付加情報を受領する（ステップ２５６０）。
当該モジュールは、ディスプレイの画像上のステップ２５３０で検出したお酒に関する部分の上に、受領した情報を重畳表示する（ステップ２５７０）。
この際、すべての受信情報を表示するのではなく、ユーザに有益な情報のみを表示する。例えばユーザが過去に飲んだことのある銘柄に関する情報や人気度「高」の銘柄の情報、希少度「高」の銘柄の情報などのみを表示する。

当該モジュールは、何を表示するかを設定する画面を表示することも可能である。設定画面において例えば、
例１：人気度について人気度「中」「高」の銘柄を表示する。
例２：希少度について希少度「高」の銘柄を表示する。
例３：平均評価が４．５以上のものを表示する。
という設定を登録したり、変更したりすることが可能である。

このような表示する内容の設定が予めなされている場合には、統合管理サーバ１０１の銘柄判定モジュール２１４は、受信した画像情報に対応する銘柄の情報すべてをユーザ端末１０３に返信するのではなく、設定された内容に対応する銘柄情報及び付加情報のみを返信することができる。例えば上記の１つ目の設定例では、画面に写っている画像情報で特定された銘柄情報のうち、人気度が「中」「高」の銘柄の情報のみをユーザ端末１０３に返信する。

このように、ユーザ端末１０３の設定情報に応じた情報のみを返却することで、統合管理サーバ１０１から受信するデータの容量を減少させ、表示までの処理の速度を上げることができる。

図３１は、銘柄スキャン処理の際の画面の例３１００であり、陳列棚の上に並んだ種類をスキャンしている場合の表示である。
陳列されている酒類のボトルのうち、例えばラベル部分がすべてお酒に関する部分の画像として検出され、統合管理サーバ１０１に送られて銘柄判定される。このうち最終的な結果としては、３１０１、３１０３、３１０５の部分に対応する銘柄が有用な情報を持っており、これらについてのみ情報を表示している例である。

３１０１はユーザが登録した飲んだ銘柄に関する部分が、３１０３はユーザが登録した飲みたい銘柄に関する部分が、３１０５はアプリが推薦するおすすめの銘柄が、それぞれ区別可能な状態でハイライトされている。

３１０１のラベル画像が解析され、特定された銘柄に対応する付加情報として過去にそのユーザが飲んだ回数、及びユーザの評価情報が表示されている。
ユーザが過去に飲んだことのある回数は、ユーザ別登録銘柄テーブル１０００の銘柄が特定されたマスタ銘柄ＩＤを持つ全レコードについて、「位置づけ」１００４に「飲んだ」が記憶されているものの数を累積し、「飲んだ」が記憶されているすべての銘柄の全レコードの数で割ることで、今までに「飲んだ」が登録されたお酒の中で、どれくらいの割合で当該特定された銘柄のお酒を飲んでいるのかを計算することができる。

これを図３４と同様に、「飲んだ」全銘柄中の分布と比較することで、どれくらいの回数飲んでいるかを計算し、表示する。
なお、解析データＤＢ２２１のユーザ別登録銘柄テーブル１０００と同様の情報は、ユーザ端末１０３のユーザ端末データ３２１にも格納されているため、ユーザ端末１０３側で処理して表示してもよい。

ユーザの評価は、評価点１００６を、ユーザ別登録銘柄テーブル１０００かユーザ端末１０３のユーザ端末データ３２１から取得して表示する。
この他、ユーザが評価コメント１００５をつけている場合には、この評価コメント１００５及びその登録日１００２をユーザ別登録銘柄テーブル１０００かユーザ端末１０３のユーザ端末データ３２１から取得して、その全文もしくは省略した一部を表示してもよい。

３１０４には、ユーザが登録した飲みたい銘柄に関する情報が表示されている。
ユーザが「飲みたい」銘柄を登録している場合に、評価コメント１００５及びその登録日１００２をユーザ別登録銘柄テーブル１０００かユーザ端末１０３のユーザ端末データ３２１から取得して、その全文もしくは省略した一部を表示する。

全ユーザの平均評価は、銘柄解析テーブル１２００の平均評価１２０２のうち、特定された銘柄のマスタ銘柄ＩＤ１２０１に対応するものを付加情報として取得する。銘柄スキャンモジュール３１２は統合管理サーバ１０１から当該付加情報を受信して平均評価の値を３１０４に表示する。

３１０６には、酒類情報管理アプリまたは統合管理サーバ１０１が推薦するおすすめ銘柄に関する情報が表示されている。
人気度や希少度は、銘柄解析テーブル１２００の人気度、希少度１、希少度２、希少度３等の情報（１２０４、１２０６、１２０８、１２１０）のうち、特定された銘柄のマスタ銘柄ＩＤに対応するものを付加情報として取得する。
銘柄スキャンモジュール３１２は統合管理サーバ１０１から当該付加情報を受信して人気度や希少度を３１０６に表示する。
希少度としては、希少度１（飲んだ人の少ないもの）、希少度２（飲食店の取扱率の低いもの）、希少度３（小売店の取扱率の低いもの）のうち、すべてを表示してもよいし、そのうちの一部を表示したり、加重平均を取るなどしてその全部または一部を統合して表示してもよい。

このように、銘柄に関する情報や、人気度、希少度等を複数の流通企業の商品情報や顧客店舗情報、販売実績などの物流データから求めることで、物流データの更新のタイミングでタイムリーに更新し続けることができる。
また、複数の流通企業から受信した物流データを用いることで、販売店や小売店での取扱い割合を希少度としてユーザに提示することができる。

なお、付加情報の表示は、図３１のように特定した銘柄の切り抜き部分もしくはその近傍をハイライト表示し（３１０１、３１０３、３１０５））、その付近に付加情報を表示する（３１０２、３１０４、３１０６）。
銘柄判定スピードが遅いと、撮影している画像が動いてしまう場合があるが、銘柄スキャンモジュール３１２が、切り抜き部分の画面中の位置をトラックし続ければ対応可能である。つまり画面が動いた場合であっても、トラックした移動後の切り抜き部分の位置に、判定結果及び付加情報を表示すればよい。

なお、ユーザ端末１０３であるスマートフォンは、銘柄登録処理の場合は通常ボトルに対して正面から撮影することが多く、この場合ボトルの上方向（口の方向）とスマートフォンの上方向は、ともに同じ方向を向いて一致していることが多い。
しかしながら、銘柄スキャン処理では、スマートフォンを上向きでスキャンする場合だけでなく、図３１のように横向きにしてスキャンすることもありえる。またこの際、スマートフォンの右方向を上にして撮影するか、左方向を上にして撮影するかはユーザの好みにより異なる。図２９の銘柄登録の例ではスマートフォンの下方向にプラスマークが出ており、図３１はスマートフォンを左に倒して（右方向を上にして）撮影したものである。

このように、スマートフォンの向きが撮影のたびに異なっている状態で、画像の一部を切り抜き、統合管理サーバ１０１の銘柄判定モジュール２１４により銘柄判定を行うことになると、切り抜きされた画像がどちらの方向を向いている画像かが分からず、判定の精度が悪くなる、もしくはスピードが遅くなる恐れがある。

銘柄判定に使用される銘柄マスタのラベル画像８１１や特徴情報８１２は、通常ラベルの文字がそのまま読める方向で登録されている。つまり、ボトルの口がある方向が上になる状態のラベル画像やそこから抽出された特徴情報が登録されている。
例えば、撮影の向きが分からないと、同じ画像について画像のどちらの方向が元のボトルの上下左右の方向なのかが分からないため、９０度ずつ画像を回転させながら特徴情報の一致を確認することとなり、最大で４倍時間がかかる可能性がある。

このような問題を解消するため、銘柄スキャン処理では、撮影した際に合わせてユーザ端末１０３のジャイロから取得した３次元方向情報を合わせて統合管理サーバ１０１に送信してもよい。通常ボトルは口を上にして陳列されていることが多いため、画像を撮影した時のジャイロの重力に対する反対方向（上方向）が、画像の上方向（ボトルの口の方向）であるとして、特徴情報との類似判定を実施する。

別の方法としては、ボトル全体の画像も取得しておき、ボトルの形状から画像の上方向を判別してもよい。この場合ボトルの口の方向が画像の上方向であるとして、切り抜かれた画像の特徴情報の類似判定を実施する。

なお、銘柄スキャン処理では、複数の切り抜き画像について、銘柄判定を実施することになるが、１つ目の画像について特徴情報の類似判断時に、銘柄を特定できた方向を画面の上方向であるとして、それ以降の切り抜き画像については、その方向が画面の上方向であるとして処理を行うこともできる。
このように、方向の情報と共に画像の判定処理を行うことで、画像の判定制度や速度を上げることができる。

図３２は銘柄スキャン処理の際の別の画面３２００の例である。図３１の一部の銘柄のボトルをタップした場合に、表示されるその銘柄に関する情報を表示する例である。
銘柄スキャンモジュール３１２は、画面中のすべてのお酒を検知してその情報を表示することができるため、図３１でハイライトされているものは当然として、それ以外のハイライトされていない銘柄についても、ユーザからのタップによる銘柄の選択を検知すると、その銘柄を特定した情報および付加情報を表示できる。

表示される情報としては、ユーザ別登録銘柄テーブル１０００やユーザ端末データ３２１、銘柄解析テーブル１２００、銘柄マスタテーブル８００等に格納されている情報を付加情報として取得して、表示することができる（３２０２）。

図３３は、ボトルやラベルだけではなく、雑誌に記載された文字列に対して銘柄スキャン処理を実行した場合の画面３３００の例である。
例えば雑誌の記事の場合には、雑誌の記事の撮影画像を統合管理サーバ１０１に送信し、統合管理サーバ１０１の銘柄判定処理でＯＣＲ等の文字認識処理を施し、検出されたテキスト中のお酒に関する銘柄名や、カテゴリ、ブランド名、メーカ、蔵・醸造所等の情報を、銘柄マスタテーブル８００と照合することで、飲みたい銘柄を特定する。
特定された銘柄及びその付加情報を取得することで、雑誌記事画像上にそのお酒の情報を表示する（３３０５）。店舗のお酒のメニューの表示であっても、同様にスキャン処理することができる。

その後図３３の画面中央下のプラスマーク３３０１を押す、もしくは選択ハイライト部分のタップを検知することで、銘柄登録モジュール３１１が起動し、ここから「飲んだ銘柄を登録」ボタン３３０２「飲みたい銘柄を登録」ボタン３３０３の選択を受け付けることで、「飲んだ」「飲みたい」銘柄として登録することができる。
なお、図３１、図３２の例でも、同様に「飲んだ」「飲みたい」銘柄を登録することが可能である。

本実施形態では、お酒の陳列棚や、雑誌記事、店舗メニューなどを簡単にスキャンすることで、物流データから取得した銘柄情報を表示することが可能となり、またそこから特定された銘柄を「飲んだ」「飲みたい」銘柄として登録しておくことが可能となる。

図２６は、登録一覧画面２６００の例である。
図２６の画面左下の「投稿一覧」２６０１がタップされる等により、酒類情報管理アプリがユーザから投稿一覧表示の指示を受け付けると、ユーザ端末１０３の一覧表示モジュール３１３が起動する。
一覧表示モジュール３１３は、ユーザ端末１０３の補助記憶装置３０２に格納されているユーザ端末データ３２１から対応する情報を取得し、表示する。
ユーザ端末データ３２１は、統合管理サーバ１０１の解析データＤＢ２２１のユーザ別登録銘柄テーブル１０００にも格納されており、このデータから情報を取得してもよい。

２６０２には、登録されている銘柄名が表示される。当該モジュールは、ユーザ端末１０３のユーザ端末データ３２１に記憶されている情報、もしくは統合管理サーバ１０１のユーザ別登録銘柄テーブル１０００に記憶されているマスタ銘柄ＩＤ１００３に対応付けられている銘柄マスタテーブル８００の銘柄名８０２の情報を、銘柄名として表示する。
２６０３には、ユーザ名が表示されている。当該モジュールは、ユーザ端末１０３のユーザ端末データ３２１に記憶されている情報、もしくは統合管理サーバ１０１のユーザマスタテーブル７００に記憶されているユーザ名７０２の情報を、ユーザ名として表示する。

２６０４には、ユーザの投稿したコメントが表示されている。当該モジュールは、ユーザ端末１０３のユーザ端末データ３２１に記憶されている情報、もしくは統合管理サーバ１０１のユーザ別登録銘柄テーブル１０００に記憶されている評価コメント１００５を表示する。

２６０５には、ＳＮＳ機能が表示されている。本酒類情報管理アプリはＳＮＳ機能を有し、他のユーザの投稿やコメントに「いいね」や「コメント」や「飲みたい」をつけることができる。この投稿一覧２６００は、ユーザ端末１０３を使用しているユーザだけでなく、アプリを利用する他のユーザの投稿も併せて表示することもできる。

２６０６には、投稿日が表示されている。一覧表示モジュール３１３は、ユーザ端末１０３のユーザ端末データ３２１に記憶されている情報、もしくは統合管理サーバ１０１のユーザ別登録銘柄テーブル１０００に記憶されている投稿日１００２を表示する。

２６０７には、ユーザのつけた評価が表示されている。当該モジュールは、ユーザ端末１０３のユーザ端末データ３２１に記憶されている情報、もしくは統合管理サーバ１０１のユーザ別登録銘柄テーブル１０００に記憶されている評価コメント１００５を表示する。

２６０８には、登録されているお酒に関する詳細情報が表示されている。当該モジュールは、ユーザ端末１０３のユーザ端末データ３２１に記憶されている情報、もしくは統合管理サーバ１０１のユーザ別登録銘柄テーブル１０００に記憶されているマスタ銘柄ＩＤに対応付けられている銘柄マスタテーブル８００の情報を、詳細情報として表示する。

２６０９には、登録されているお酒に関する投稿画像が表示されている。当該モジュールは、ユーザ端末１０３のユーザ端末データ３２１に記憶されている情報、もしくは統合管理サーバ１０１のユーザ別登録銘柄テーブル１０００に記憶されている投稿画像１００８を、詳細情報として表示する。

これら以外にも、ユーザ別登録銘柄テーブル１０００や、ユーザマスタテーブル７００、銘柄マスタテーブル８００、銘柄解析テーブル１２００等の各種テーブルの情報を表示してもよい。

図２７は、登録一覧画面の別の表示２７００の例である。
図２７の画面左下の「銘柄一覧」２７０１がタップされる等により、酒類情報管理アプリがユーザから銘柄一覧表示の指示を受け付けると、ユーザ端末１０３の一覧表示モジュール３１３が起動する。
一覧表示モジュール３１３は、ユーザ端末１０３の補助記憶装置３０２に格納されているユーザ端末データ３２１から対応する情報を取得し、表示する。
ユーザ端末データ３２１は、統合管理サーバ１０１の解析データＤＢ２２１のユーザ別登録銘柄テーブル１０００にも格納されており、このデータから情報を取得してもよい。

当該モジュールは、２７０２の「飲んだ」ボタンの選択を受け付けると、ユーザ別登録銘柄テーブル１０００の位置付け１００４が「飲んだ」である銘柄に関する情報を取得し、飲んだ酒類の一覧リストを表示する。

２７０５～２７０７には、図２６と同様に登録されているお酒に関する詳細情報が表示されている。当該モジュールは、ユーザ端末１０３のユーザ端末データ３２１に記憶されている情報、もしくは統合管理サーバ１０１のユーザ別登録銘柄テーブル１０００に記憶されている情報を詳細情報として表示する。
これら以外にも、ユーザ別登録銘柄テーブル１０００や、ユーザマスタテーブル７００、銘柄マスタテーブル８００、銘柄解析テーブル１２００等の各種テーブルの情報を表示してもよい。

当該モジュールは、２７０３の「飲みたい」ボタンの選択を受け付けると、ユーザ別登録銘柄テーブル１０００の位置付け１００４が「飲みたい」である銘柄に関する情報を取得し、飲んだ酒類の一覧リストを表示する。

当該モジュールは、２７０３の「おすすめ」ボタンの選択を受け付けると、ユーザ別登録銘柄テーブル１０００の位置付け１００４が「おすすめ」である銘柄に関する情報を取得し、飲んだ酒類の一覧リストを表示する。
おすすめ情報としては、ユーザの過去に飲んだ銘柄に関連するお酒など、ユーザの嗜好に添った銘柄が登録されている。他には、嗜好に添った銘柄のうち人気度・希少度の高いお酒の情報などを登録・表示してもよい。

図２８は、地図上に選択された銘柄のお酒を飲める店を表示する画面２８００の例である。
一覧表示モジュール３１３は、図２６の２６１０や図２７の２７０８等の「飲めるお店」を表示する選択を受け付けると、図２８のような飲めるお店一覧を地図上に表示する。
飲めるお店一覧の情報は、一覧表示モジュール３１３が、統合管理サーバ１０１に問い合わせ、統合管理サーバ１０１のデータ解析モジュール２１５が、解析データＤＢ２２１の店舗別取扱銘柄テーブル１１００から、当該銘柄を取り扱う店舗の情報を抽出することで生成できる。

表示される店舗名、住所、地図上の位置情報、電話番号などは、対応するマスタ店舗ＩＤに対応付けられた店舗マスタテーブル９００の店舗名９０３、住所９０５、位置９０６、電話番号９０７などから取得する
一覧表示モジュール３１３は、位置９０６に記載された座標の位置に、これらの取得した情報を表示する（２８０４）。

また、２８０１、２８０２のように取扱切れリスクが見えるように表示してもよい。取扱切れリスクは店舗別取扱銘柄テーブル１１００の取扱切リスク１１０８の情報を取得することで表示することができる。
取扱切れリスク１１０８では、「高」「中」「低」「取扱終了確定」があり、これらのすべての情報を地図上に表示してもよいが、図２８の例のように「取扱終了確定」については、表示しないという構成をとることもできる。

なお、図２８の例のでは地図上に飲めるお店を配置しているが、地図ではなく一覧としてリスト表示を行ってもよい。この場合に、ユーザ端末１０３のＧＰＳから取得した現在地と住所９０５や位置９０６とを比較して、現在地から距離が近い順に店舗リストを表示することもできる。

図２９は、銘柄登録画面の例である。説明は図２２の銘柄登録処理フローの中で説明を行った。

図３０は、銘柄登録処理で銘柄の付加情報を表示する画面の例である。
ハイライトされた画像部分のタップ等による選択を受け付けると、銘柄登録モジュール３１１は、特定された銘柄の付加情報を表示する（３００３）。
表示される情報としては、ユーザ別登録銘柄テーブル１０００やユーザ端末データ３２１、銘柄解析テーブル１２００、銘柄マスタテーブル８００等に格納されている情報を付加情報として取得して、表示することができる。

図３１は、銘柄スキャン画面の例である。
図３２は、銘柄スキャン画面の別の表示例である。
図３３は、銘柄スキャン画面の別の表示例である。
図３１～図３５の説明は図２５の銘柄スキャン処理フローの中で説明を行った。

図３４は、銘柄解析テーブル１２００の人気度の判定を説明する図である。
データ解析モジュール２１５は、すべての銘柄について「飲みたい人の割合」を計算し、銘柄解析テーブル１２００に「飲みたい人の割合」１２０３として記憶している。この「飲みたい人の割合」を縦軸とし、割合が多い順に各銘柄を並べる。横軸は各銘柄名である。
なお、縦軸は、飲みたい人の割合だけではなく、「飲みたい人」に「飲んだ人の評価」を掛け合わせた指数を縦軸として人気度を計算してもよい。
このグラフの分布から、飲みたい人の割合の値が大きい方から所定の範囲で人気度を「高」「中」「低」として銘柄を分類する。

例えば、ユーザ別登録銘柄テーブル１０００の位置づけに「飲みたい」が登録されている銘柄（つまり飲みたい人の割合が「０」でないもの）について、銘柄数を均等に３分割して、飲みたい人の割合が多い順に「高」「中」「低」としてもよい。
例えば「飲みたい」が登録されている銘柄が３００銘柄あると仮定すると、「高」「中」「低」に１００銘柄ずつが割り振られる。そして「飲みたい」が登録されていない銘柄は評価「低」にする。

他の例では、「飲みたい」が登録されている銘柄について、「飲みたい」人の数が均等になるように３分割して、人気度「高」「中」「低」としてもよい。
例えば図３４の例では、飲みたい人の割合が「０」でない部分について、「高」「中」「低」それぞれの棒グラフの総面積が均等になるように分類する。
なお、均等に３分割する以外にも所定の割合や方法で分類して評価してもよい。

図３５は、銘柄解析テーブル１２００の希少度の判定を説明する図である。
データ解析モジュール２１５は、すべての銘柄について「飲んだ人の割合」を計算し、銘柄解析テーブル１２００に記憶している。この「飲んだ人の割合」を縦軸とし、割合が多い順に各銘柄を並べる。横軸は各銘柄名である。
このグラフの分布から、飲んだ人の割合の値が大きい方から所定の範囲で希少度を「低」「中」「高」として銘柄を分類する。

この場合に、飲んだ人の数が極端に少ない場合には、希少度が高いわけではなく、情報が登録されていないだけの可能性が高いため、飲んだ人の数が所定の人数や割合（例えば１００人や０．１％）以下の場合は、考慮しない。
例えば、ユーザ別登録銘柄テーブル１０００の位置づけに「飲んだ」が登録されている銘柄で、飲んだ人が１００人より多いものについて、銘柄数を均等に３分割して、飲んだ人の割合が多い順に「低」「中」「高」としてもよい。
例えば「飲んだ」が登録されていて、「飲んだ」人が１００人より多い銘柄が３００銘柄あると仮定すると、希少度「低」「中」「高」に１００銘柄ずつが割り振られる。そして「飲んだ」人が１００人以下の銘柄は評価対象外として「－」にする。

他の例では、「飲んだ」が登録されている銘柄について、「飲んだ」人の数が均等になるように３分割して、希少度「低」「中」「高」としてもよい。
例えば図３５の例では、飲んだ人が０．１％より多い部分（もし１０万人ユーザがいる場合飲んだ人の割合が１００人より上）について、「低」「中」「高」それぞれの棒グラフの総面積が均等になるように分類する。

なお、均等に３分割する以外にも所定の割合や方法で分類して評価してもよい。
人気度や希少度の分類は、各銘柄を飲みたい人、飲んだ人、取り扱う飲食店、小売店などの数の分布や偏差によって分類してもよいし、単純に上位１０銘柄を人気度や希少度「高」として分類するなどとしてもよい。

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

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

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

１…管理システム、１０１…統合管理サーバ、１０２…流通企業端末、１０３…ユーザ端末、１０４…店舗端末、１０５…メーカ端末、２１１…データ整形モジュール、２１２…データ突合モジュール、２１３…ユーザデータ管理モジュール、２１４…銘柄判定モジュール、２１５…データ解析モジュール、２２１…解析データＤＢ、２２２…企業横断マスタＤＢ、２２３…流通企業データの整形ＤＢ、２２４…流通企業データの受領ＤＢ、３１１…銘柄登録モジュール、３１２…銘柄スキャンモジュール、３１３…一覧表示モジュール、３２１…ユーザ端末データ

Claims (14)

1. 統合管理サーバであって、
   店舗に商品を販売する複数の流通企業の複数の流通企業端末から、それぞれの販売実績情報を受け付けるデータ整形手段と、
   前記店舗に販売される酒類の商品を前記複数の流通企業に対して共通に管理するための商品マスタ情報であって、酒類の商品の共通識別情報を含む商品マスタ情報を、受け付けた前記それぞれの販売実績情報に基づいて更新するデータ突合手段と、
   ユーザ端末から受信した商品関連情報を解析し、前記商品マスタ情報に登録されている酒類の商品に対応する特徴情報との比較を行うことにより酒類の商品を特定し、特定された酒類の商品に関する情報をユーザ端末に送信する商品判定手段と、
   を有し、
   前記データ整形手段は、前記それぞれの販売実績情報から取得した情報を前記複数の流通企業端末に対して共通に管理するための共通販売実績情報であって、酒類の商品の共通識別情報を含む共通販売実績情報に記憶し、
   前記データ突合手段は、
   前記商品マスタ情報に登録されている酒類の商品が、前記共通販売実績情報に存在していた場合には、対応する酒類の商品を特定する共通識別情報を前記共通販売実績情報に記憶し、
   前記共通販売実績情報に記憶されている酒類の商品が前記商品マスタ情報に存在しなかった場合には、前記存在しなかった酒類の商品の共通識別情報を前記商品マスタ情報に追加する
   ことで前記商品マスタ情報を更新し、
   データを解析するデータ解析手段をさらに有し、
   前記データ解析手段は、前記複数の流通企業端末から受け付けた前記それぞれの販売実績情報に基づいて、所定の店舗における所定の商品の取扱切れリスクを求め、
   前記商品判定手段は、前記特定された酒類の商品に関する情報として、特定された酒類の商品の取扱切れリスクを示す情報を前記ユーザ端末に送信する
   ことを特徴とする統合管理サーバ。
2. 統合管理サーバであって、
   店舗に商品を販売する複数の流通企業の複数の流通企業端末から、それぞれの販売実績情報を受け付けるデータ整形手段と、
   前記店舗に販売される酒類の商品を前記複数の流通企業に対して共通に管理するための商品マスタ情報であって、酒類の商品の共通識別情報を含む商品マスタ情報を、受け付けた前記それぞれの販売実績情報に基づいて更新するデータ突合手段と、
   ユーザ端末から受信した商品関連情報を解析し、前記商品マスタ情報に登録されている酒類の商品に対応する特徴情報との比較を行うことにより酒類の商品を特定し、特定された酒類の商品に関する情報をユーザ端末に送信する商品判定手段と、
   を有し、
   前記データ整形手段は、前記それぞれの販売実績情報から取得した情報を前記複数の流通企業端末に対して共通に管理するための共通販売実績情報であって、酒類の商品の共通識別情報を含む共通販売実績情報に記憶し、
   前記データ突合手段は、
   前記商品マスタ情報に登録されている酒類の商品が、前記共通販売実績情報に存在していた場合には、対応する酒類の商品を特定する共通識別情報を前記共通販売実績情報に記憶し、
   前記共通販売実績情報に記憶されている酒類の商品が前記商品マスタ情報に存在しなかった場合には、前記存在しなかった酒類の商品に関する共通識別情報を前記商品マスタ情報に追加する
   ことで前記商品マスタ情報を更新し、
   前記商品判定手段は、前記複数の流通企業端末から受け付けた前記それぞれの販売実績情報に基づいて、前記特定された酒類の商品に関する情報として、特定された酒類の商品を取扱中である可能性が高い店舗を示す情報を前記ユーザ端末に送信する
   ことを特徴とする統合管理サーバ。
3. 請求項１又は２に記載の統合管理サーバであって、
   前記商品判定手段は、推薦する酒類の商品に関する情報を前記ユーザ端末に送信することを特徴とする統合管理サーバ。
4. 請求項２に記載の統合管理サーバであって、
   データを解析するデータ解析手段を有し、
   前記データ解析手段は、前記複数の流通企業端末から受け付けた前記それぞれの販売実績情報に基づいて、所定の店舗における所定の商品の取扱切れリスクを求め、
   前記商品判定手段は、前記特定された酒類の商品に関する情報として、特定された酒類の商品の取扱切れリスクを示す情報を前記ユーザ端末に送信する
   ことを特徴とする統合管理サーバ。
5. 請求項１に記載の統合管理サーバであって、
   前記商品判定手段は、前記複数の流通企業端末から受け付けた前記それぞれの販売実績情報に基づいて、前記特定された酒類の商品に関する情報として、特定された酒類の商品を取扱中である可能性が高い店舗を示す情報を前記ユーザ端末に送信する
   ことを特徴とする統合管理サーバ。
6. 請求項１又は４に記載の統合管理サーバであって、
   前記特定された酒類の商品を取扱中である可能性が高い店舗を示す情報は、前記ユーザ端末に表示される地図上の前記所定の店舗を示す情報と対応付けて表示される
   ことを特徴とする統合管理サーバ。
7. 請求項１～６のいずれか１項に記載の統合管理サーバであって、
   前記商品判定手段は、前記複数の流通企業端末から受け付けた前記それぞれの販売実績情報に基づいて、所定の店舗で取り扱っている酒類の商品に関する情報を前記ユーザ端末に送信する
   ことを特徴とする統合管理サーバ。
8. 請求項１～７のいずれか１項に記載の統合管理サーバであって、
   前記特定された酒類の商品に関する情報は、それぞれの商品の人気度、希少度、平均評価のうちの少なくとも１つである
   ことを特徴とする統合管理サーバ。
9. 請求項１～８のいずれか１項に記載の統合管理サーバであって、
   受信手段が、前記ユーザ端末のカメラ部から取得されたスキャン対象画像から検出された、酒類に関連する複数の部分画像を、前記ユーザ端末から受信し、
   前記商品判定手段は、前記複数の部分画像を前記商品関連情報として解析し、対応する複数の酒類の商品を特定し、特定された複数の酒類の商品に関する情報を前記ユーザ端末に送信し、
   送信された前記複数の酒類の商品に関する情報は、前記スキャン対象画像の上の前記複数の部分画像の位置と対応付けて表示される
   ことを特徴とする統合管理サーバ。
10. 請求項９に記載の統合管理サーバであって、
    前記スキャン対象画像は、酒類の複数のボトルが写った画像、酒類に関する記事が写った画像、又はメニューが写った画像、の少なくとも１つであり、
    前記スキャン対象画像の前記複数のボトルのラベル部分、前記記事に記載された文字列の部分、又は、前記メニューに記載された文字列の部分、の少なくとも１つが、前記複数の部分画像として検出される
    ことを特徴とする統合管理サーバ。
11. 統合管理サーバにより実行される管理方法であって、
    店舗に商品を販売する複数の流通企業の複数の流通企業端末から、それぞれの販売実績情報を受け付ける受付ステップと、
    前記それぞれの販売実績情報から取得した情報を前記複数の流通企業端末に対して共通に管理するための共通販売実績情報であって、酒類の商品の共通識別情報を含む共通販売実績情報に記憶する記憶ステップと、
    前記店舗に販売される酒類の商品を前記複数の流通企業に対して共通に管理するための商品マスタ情報であって、酒類の商品の共通識別情報を含む商品マスタ情報を、受け付けた前記それぞれの販売実績情報に基づいて更新する更新ステップと、
    ユーザ端末から受信した商品関連情報を解析し、前記商品マスタ情報に登録されている酒類の商品に対応する特徴情報との比較を行うことにより酒類の商品を特定する特定ステップと、
    特定された酒類の商品に関する情報をユーザ端末に送信する送信ステップと、
    を有し、
    前記更新ステップでは、
    前記商品マスタ情報に登録されている酒類の商品が、前記共通販売実績情報に存在していた場合には、対応する酒類の商品を特定する共通識別情報を前記共通販売実績情報に記憶し、
    前記共通販売実績情報に記憶されている酒類の商品が前記商品マスタ情報に存在しなかった場合には、前記存在しなかった酒類の商品の共通識別情報を前記商品マスタ情報に追加する
    ことで前記商品マスタ情報を更新し、
    前記複数の流通企業端末から受け付けた前記それぞれの販売実績情報に基づいて、所定の店舗における所定の商品の取扱切れリスクを求めるステップをさらに有し、
    前記送信ステップでは、前記特定された酒類の商品に関する情報として、特定された酒類の商品の取扱切れリスクを示す情報を前記ユーザ端末に送信する
    ことを特徴とする管理方法。
12. 統合管理サーバにより実行される管理方法であって、
    店舗に商品を販売する複数の流通企業の複数の流通企業端末から、それぞれの販売実績情報を受け付ける受付ステップと、
    前記それぞれの販売実績情報から取得した情報を前記複数の流通企業端末に対して共通に管理するための共通販売実績情報であって、酒類の商品の共通識別情報を含む共通販売実績情報に記憶する記憶ステップと、
    前記店舗に販売される酒類の商品を前記複数の流通企業に対して共通に管理するための商品マスタ情報であって、酒類の商品の共通識別情報を含む商品マスタ情報を、受け付けた前記それぞれの販売実績情報に基づいて更新する更新ステップと、
    ユーザ端末から受信した商品関連情報を解析し、前記商品マスタ情報に登録されている酒類の商品に対応する特徴情報との比較を行うことにより酒類の商品を特定する特定ステップと、
    特定された酒類の商品に関する情報をユーザ端末に送信する送信ステップと、
    を有し、
    前記更新ステップでは、
    前記商品マスタ情報に登録されている酒類の商品が、前記共通販売実績情報に存在していた場合には、対応する酒類の商品を特定する共通識別情報を前記共通販売実績情報に記憶し、
    前記共通販売実績情報に記憶されている酒類の商品が前記商品マスタ情報に存在しなかった場合には、前記存在しなかった酒類の商品の共通識別情報を前記商品マスタ情報に追加する
    ことで前記商品マスタ情報を更新し、
    前記送信ステップでは、前記複数の流通企業端末から受け付けた前記それぞれの販売実績情報に基づいて、前記特定された酒類の商品に関する情報として、特定された酒類の商品を取扱中である可能性が高い店舗を示す情報を前記ユーザ端末に送信する
    ことを特徴とする管理方法。
13. 請求項１２に記載の管理方法であって、
    前記複数の流通企業端末から受け付けた前記それぞれの販売実績情報に基づいて、所定の店舗における所定の商品の取扱切れリスクを求めるステップをさらに有し、
    前記送信ステップでは、前記特定された酒類の商品に関する情報として、特定された酒類の商品の取扱切れリスクを示す情報を前記ユーザ端末に送信する
    ことを特徴とする管理方法。
14. 請求項１１に記載の管理方法であって、
    前記特定された酒類の商品を取扱中である可能性が高い店舗を示す情報は、前記ユーザ端末に表示される地図上の前記所定の店舗を示す情報と対応付けて表示される
    ことを特徴とする管理方法。