知財求人 - 知財ポータルサイト「IP Force」
特開2024-7275商品情報管理サーバ、消費者端末、通信端末、商品情報提供方法およびプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024007275
(43)【公開日】2024-01-18
(54)【発明の名称】商品情報管理サーバ、消費者端末、通信端末、商品情報提供方法およびプログラム
(51)【国際特許分類】
G06Q 30/0251 20230101AFI20240111BHJP
【ＦＩ】
G06Q30/02 398
【審査請求】未請求
【請求項の数】12
【出願形態】ＯＬ
(21)【出願番号】P 2022108673
(22)【出願日】2022-07-05
(71)【出願人】
【識別番号】518272315
【氏名又は名称】株式会社彩いろり
(74)【代理人】
【識別番号】110003476
【氏名又は名称】弁理士法人瑛彩知的財産事務所
(72)【発明者】
【氏名】中西 健一
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049BB08
(57)【要約】
【課題】 売り手が自前で消費者の嗜好情報を収集せずとも、嗜好情報に基づく付加価値を提供可能な仕組みを提供する。
【解決手段】 商品情報管理サーバは、第１管理手段と商品情報提供手段を有する。第１管理手段は、消費者端末から送信される商品情報であって、消費者端末を使用する消費者が購入または消費した、もしくは消費者が購入または消費を希望する第１の商品の商品情報を管理する。商品情報提供手段は、消費者が店舗に訪問又はアクセスした場合に、第１の商品の商品情報、または第１の商品の商品情報に基づいて消費者の嗜好に合致すると推定された第２の商品の商品情報を消費者端末、または上記店舗を運営する事業者が管理するサーバに送信する。
【選択図】 図１
【解決手段】 商品情報管理サーバは、第１管理手段と商品情報提供手段を有する。第１管理手段は、消費者端末から送信される商品情報であって、消費者端末を使用する消費者が購入または消費した、もしくは消費者が購入または消費を希望する第１の商品の商品情報を管理する。商品情報提供手段は、消費者が店舗に訪問又はアクセスした場合に、第１の商品の商品情報、または第１の商品の商品情報に基づいて消費者の嗜好に合致すると推定された第２の商品の商品情報を消費者端末、または上記店舗を運営する事業者が管理するサーバに送信する。
【選択図】 図１
【特許請求の範囲】
【請求項1】
商品情報管理サーバであって、
消費者端末から送信される商品情報であって、前記消費者端末を使用する消費者が購入または消費した、もしくは前記消費者が購入または消費を希望する第１の商品の商品情報を管理する第１管理手段と、
前記消費者が店舗に訪問又はアクセスした場合に、前記第１の商品の商品情報、または前記第１の商品の商品情報に基づいて前記消費者の嗜好に合致すると推定された第２の商品の商品情報を前記消費者端末、または前記店舗を運営する事業者が管理するサーバに送信する商品情報提供手段と
を有する商品情報管理サーバ。
消費者端末から送信される商品情報であって、前記消費者端末を使用する消費者が購入または消費した、もしくは前記消費者が購入または消費を希望する第１の商品の商品情報を管理する第１管理手段と、
前記消費者が店舗に訪問又はアクセスした場合に、前記第１の商品の商品情報、または前記第１の商品の商品情報に基づいて前記消費者の嗜好に合致すると推定された第２の商品の商品情報を前記消費者端末、または前記店舗を運営する事業者が管理するサーバに送信する商品情報提供手段と
を有する商品情報管理サーバ。
【請求項2】
請求項１に記載の商品情報管理サーバであって、
前記第１管理手段は、前記第１の商品の商品情報を一元的に管理し、
前記店舗は、それぞれ異なる売り手により運営される複数の店舗のうちの一店舗である
ことを特徴とする商品情報管理サーバ。
前記第１管理手段は、前記第１の商品の商品情報を一元的に管理し、
前記店舗は、それぞれ異なる売り手により運営される複数の店舗のうちの一店舗である
ことを特徴とする商品情報管理サーバ。
【請求項3】
請求項１に記載の商品情報管理サーバであって、
前記商品情報提供手段は、前記消費者がオンライン店舗にアクセスし、所定の装飾モジュールが組み込まれた画面を表示する場合に、前記第１または第２の商品情報を前記消費者端末に送信する
ことを特徴とする商品情報管理サーバ。
前記商品情報提供手段は、前記消費者がオンライン店舗にアクセスし、所定の装飾モジュールが組み込まれた画面を表示する場合に、前記第１または第２の商品情報を前記消費者端末に送信する
ことを特徴とする商品情報管理サーバ。
【請求項4】
請求項１に記載の商品情報管理サーバであって、
前記店舗は実店舗であり、
前記商品情報提供手段は、前記消費者が前記店舗に訪問し、前記店舗が前記第１または第２の商品を取り扱っている場合に、前記第１または第２の商品の商品情報を前記消費者端末、または前記店舗を運営する事業者が管理するサーバに送信する
ことを特徴とする商品情報管理サーバ。
前記店舗は実店舗であり、
前記商品情報提供手段は、前記消費者が前記店舗に訪問し、前記店舗が前記第１または第２の商品を取り扱っている場合に、前記第１または第２の商品の商品情報を前記消費者端末、または前記店舗を運営する事業者が管理するサーバに送信する
ことを特徴とする商品情報管理サーバ。
【請求項5】
請求項１に記載の商品情報管理サーバであって、
複数の商品についての商品情報を管理する第２管理手段と、
前記消費者端末から送信された商品提案要求を受けて、前記管理された複数の商品情報の中から、前記消費者の嗜好または前記消費者により指定された抽出条件に基づいて商品情報を抽出し、前記消費者端末に送信する商品抽出手段と
をさらに有し、
前記商品提案要求は、商品販売画面に組み込まれた接客パーツを用いて前記消費者端末から送信され、
前記商品情報管理サーバから送信された商品情報は、前記消費者端末に表示される
ことを特徴とする商品情報管理サーバ。
複数の商品についての商品情報を管理する第２管理手段と、
前記消費者端末から送信された商品提案要求を受けて、前記管理された複数の商品情報の中から、前記消費者の嗜好または前記消費者により指定された抽出条件に基づいて商品情報を抽出し、前記消費者端末に送信する商品抽出手段と
をさらに有し、
前記商品提案要求は、商品販売画面に組み込まれた接客パーツを用いて前記消費者端末から送信され、
前記商品情報管理サーバから送信された商品情報は、前記消費者端末に表示される
ことを特徴とする商品情報管理サーバ。
【請求項6】
請求項１に記載の商品情報管理サーバであって、
複数の商品についての商品情報を管理する第２管理手段と、
前記消費者端末から送信された商品提案要求を受けて、前記管理された複数の商品情報の中から、指定された抽出条件に基づいて商品情報を抽出し、前記消費者端末に送信する商品抽出手段と
をさらに有し、
前記商品提案要求は、アプリケーションに組み込まれた接客パーツを用いて前記消費者端末から送信され、
前記商品情報管理サーバから送信された商品情報は、前記消費者端末に表示される
ことを特徴とする商品情報管理サーバ。
複数の商品についての商品情報を管理する第２管理手段と、
前記消費者端末から送信された商品提案要求を受けて、前記管理された複数の商品情報の中から、指定された抽出条件に基づいて商品情報を抽出し、前記消費者端末に送信する商品抽出手段と
をさらに有し、
前記商品提案要求は、アプリケーションに組み込まれた接客パーツを用いて前記消費者端末から送信され、
前記商品情報管理サーバから送信された商品情報は、前記消費者端末に表示される
ことを特徴とする商品情報管理サーバ。
【請求項7】
請求項１に記載の商品情報管理サーバであって、
通信端末から送信されたリワードプログラム情報を管理する第２管理手段と、
前記消費者が前記商品を購入または消費した場合に前記消費者端末から送信される実績情報を、その購入または消費した店舗を横断して、前記リワードプログラム情報と対応付けて管理する第３管理手段と
をさらに有する
ことを特徴とする商品情報管理サーバ。
通信端末から送信されたリワードプログラム情報を管理する第２管理手段と、
前記消費者が前記商品を購入または消費した場合に前記消費者端末から送信される実績情報を、その購入または消費した店舗を横断して、前記リワードプログラム情報と対応付けて管理する第３管理手段と
をさらに有する
ことを特徴とする商品情報管理サーバ。
【請求項8】
消費者端末であって、
前記消費者端末を使用する消費者が購入または消費した、もしくは前記消費者が購入または消費を希望する第１の商品の商品情報を商品情報管理サーバに送信する商品登録手段と、
前記消費者が店舗に訪問又はアクセスした場合に、前記商品情報、または前記商品情報に基づいて前記消費者の嗜好に合致すると推定された第２の商品の商品情報を前記商品情報管理サーバに対して要求して取得し、前記消費者に通知する商品情報取得手段と
を有し、
前記消費者端末から送信された前記第１または第２の商品の商品情報は、前記商品情報管理サーバにより管理される
を有することを特徴とする消費者端末。
前記消費者端末を使用する消費者が購入または消費した、もしくは前記消費者が購入または消費を希望する第１の商品の商品情報を商品情報管理サーバに送信する商品登録手段と、
前記消費者が店舗に訪問又はアクセスした場合に、前記商品情報、または前記商品情報に基づいて前記消費者の嗜好に合致すると推定された第２の商品の商品情報を前記商品情報管理サーバに対して要求して取得し、前記消費者に通知する商品情報取得手段と
を有し、
前記消費者端末から送信された前記第１または第２の商品の商品情報は、前記商品情報管理サーバにより管理される
を有することを特徴とする消費者端末。
【請求項9】
通信端末であって、
リワードプログラム情報を入力するための登録フォームを表示し、当該登録フォームに入力されたリワードプログラム情報を商品情報管理サーバに送信するリワードプログラム登録手段を有し、
前記通信端末から送信された前記リワードプログラム情報は、前記商品情報管理サーバにより管理され、
前記リワードプログラム情報は、消費者端末から送信される、商品の購入または消費の実績情報と、その購入または消費した店舗を横断して、対応付けて前記商品情報管理サーバにより管理される
ことを特徴とする通信端末。
リワードプログラム情報を入力するための登録フォームを表示し、当該登録フォームに入力されたリワードプログラム情報を商品情報管理サーバに送信するリワードプログラム登録手段を有し、
前記通信端末から送信された前記リワードプログラム情報は、前記商品情報管理サーバにより管理され、
前記リワードプログラム情報は、消費者端末から送信される、商品の購入または消費の実績情報と、その購入または消費した店舗を横断して、対応付けて前記商品情報管理サーバにより管理される
ことを特徴とする通信端末。
【請求項10】
商品情報提供方法であって、
第１管理手段が、消費者端末から送信される商品情報であって、前記消費者端末を使用する消費者が購入または消費した、もしくは前記消費者が購入または消費を希望する第１の商品の商品情報を管理するステップと、
商品情報提供手段が、前記消費者が店舗に訪問又はアクセスした場合に、前記第１の商品の商品情報、または前記第１の商品の商品情報に基づいて前記消費者の嗜好に合致すると推定された第２の商品の商品情報を前記消費者端末、または前記店舗を運営する事業者が管理するサーバに送信するステップと
を有する商品情報提供方法。
第１管理手段が、消費者端末から送信される商品情報であって、前記消費者端末を使用する消費者が購入または消費した、もしくは前記消費者が購入または消費を希望する第１の商品の商品情報を管理するステップと、
商品情報提供手段が、前記消費者が店舗に訪問又はアクセスした場合に、前記第１の商品の商品情報、または前記第１の商品の商品情報に基づいて前記消費者の嗜好に合致すると推定された第２の商品の商品情報を前記消費者端末、または前記店舗を運営する事業者が管理するサーバに送信するステップと
を有する商品情報提供方法。
【請求項11】
消費者端末を、請求項８に記載の各手段として機能させるためのプログラム。
【請求項12】
通信端末を、請求項９に記載の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、商品情報管理サーバ、消費者端末、通信端末、商品情報提供方法およびプログラムに関する。
【背景技術】
【0002】
本技術分野の背景技術を開示する文献として、特開２０１６－１８１１９６号公報（特許文献１）がある。この公報には、「多くの電子商取引（ＥＣ：Electronic Commerce）サイトでは、当該サイトに登録される会員に対してお薦め商品を紹介する。具体的には、当該会員の購入履歴や閲覧履歴を含む情報から、購入済み商品や閲覧済み商品を抽出し、抽出された商品に機能や形状が似た商品等を選出して、当該会員に対するお薦め商品として、当該会員が閲覧するポータルサイト等内に提示する。」と記載されている（段落０００２参照）。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１６－１８１１９６号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記の特許文献１には、会員の購入履歴や閲覧履歴に基づいて商品を抽出し、会員に提示することが記載されている。
売り手は消費者の嗜好情報に基づいて付加価値を提供するためには、当該消費者の嗜好情報を自前で収集する必要がある。
そこで本発明は、売り手が自前で消費者の嗜好情報を収集せずとも、嗜好情報に基づく付加価値を提供可能な仕組みを提供する。
売り手は消費者の嗜好情報に基づいて付加価値を提供するためには、当該消費者の嗜好情報を自前で収集する必要がある。
そこで本発明は、売り手が自前で消費者の嗜好情報を収集せずとも、嗜好情報に基づく付加価値を提供可能な仕組みを提供する。
【課題を解決するための手段】
【0005】
上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、商品情報管理サーバであって、消費者端末から送信される商品情報であって、前記消費者端末を使用する消費者が購入または消費した、もしくは前記消費者が購入または消費を希望する第１の商品の商品情報を管理する第１管理手段と、前記消費者が店舗に訪問又はアクセスした場合に、前記第１の商品の商品情報、または前記第１の商品の商品情報に基づいて前記消費者の嗜好に合致すると推定された第２の商品の商品情報を前記消費者端末、または前記店舗を運営する事業者が管理するサーバに送信する商品情報提供手段とを有する。
本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、商品情報管理サーバであって、消費者端末から送信される商品情報であって、前記消費者端末を使用する消費者が購入または消費した、もしくは前記消費者が購入または消費を希望する第１の商品の商品情報を管理する第１管理手段と、前記消費者が店舗に訪問又はアクセスした場合に、前記第１の商品の商品情報、または前記第１の商品の商品情報に基づいて前記消費者の嗜好に合致すると推定された第２の商品の商品情報を前記消費者端末、または前記店舗を運営する事業者が管理するサーバに送信する商品情報提供手段とを有する。
【発明の効果】
【0006】
本発明によれば、売り手が自前で消費者の嗜好情報を収集せずとも、嗜好情報に基づく付加価値を提供可能な仕組みを提供することができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【0007】
【発明を実施するための形態】
【0008】
以下、実施例を図面を用いて説明する。
１．実施例
本実施例は、事業者横断型の情報管理スキームである。
１－１．適用市場
この情報管理スキームの適用市場は、商品の数が膨大で、それら商品の造り手の数も膨大、かつ、それら商品の売り手、運び手、勧め手の数も膨大な業界である。具体的には当該適用市場は、酒類業界である。
１．実施例
本実施例は、事業者横断型の情報管理スキームである。
１－１．適用市場
この情報管理スキームの適用市場は、商品の数が膨大で、それら商品の造り手の数も膨大、かつ、それら商品の売り手、運び手、勧め手の数も膨大な業界である。具体的には当該適用市場は、酒類業界である。
【0009】
１－２．用語
以下の説明に登場する主な用語について説明する。
ＤＤとは、Digital Deviceの略称である。このＤＤは、ＰＣ、スマートフォン、ＨＤ、プロジェクタ、ＩｏＴ機器など、Digital Worldと連動する多様な機器の総称である。
ＤＡとは、Digital Applicationの略称である。このＤＡは、各ＤＤを介して提供される多様な２Ｄ（ＷＥＢサイト、ＥＣサイト、スマートフォンアプリ）、３Ｄ、ＡＲ、ＶＲアプリの総称である。
以下の説明に登場する主な用語について説明する。
ＤＤとは、Digital Deviceの略称である。このＤＤは、ＰＣ、スマートフォン、ＨＤ、プロジェクタ、ＩｏＴ機器など、Digital Worldと連動する多様な機器の総称である。
ＤＡとは、Digital Applicationの略称である。このＤＡは、各ＤＤを介して提供される多様な２Ｄ（ＷＥＢサイト、ＥＣサイト、スマートフォンアプリ）、３Ｄ、ＡＲ、ＶＲアプリの総称である。
【0010】
造り手とは、メーカ、輸入／卸業者（特定地域において対象商品に対する独占的な販売権を有する場合）である。
なお、酒類業界では、メーカとは、酒造メーカ（蔵、ワイナリ、ブリュワリ、蒸留所など）である。
売り手とは、メーカ、輸入／卸業者、飲食／小売業者、ＥＣ事業者である。
勧め手とは、メディア／コンテンツ事業者、関連団体／協会、関連資格保有者、消費者（ブログ、ＳＮＳへ投稿する人々）である。
事業者とは、造り手、売り手、勧め手の総称である。
なお、酒類業界では、メーカとは、酒造メーカ（蔵、ワイナリ、ブリュワリ、蒸留所など）である。
売り手とは、メーカ、輸入／卸業者、飲食／小売業者、ＥＣ事業者である。
勧め手とは、メディア／コンテンツ事業者、関連団体／協会、関連資格保有者、消費者（ブログ、ＳＮＳへ投稿する人々）である。
事業者とは、造り手、売り手、勧め手の総称である。
【0011】
なお、「造り手」、「売り手」、「勧め手」には、それぞれに該当する者から本スキームに関連する作業を受託した者も、それぞれ「造り手」、「売り手」、「勧め手」として解釈される。
【0012】
１－３．概要
本実施例に係る情報管理スキームは、銘柄ブランディングの横断展開スキーム、銘柄取扱情報の横断展開スキーム、消費者の意向・履歴に応じた価値提供スキームの３つに分けられる。図１は、これら３つのスキームのイメージ例を示す。
本実施例に係る情報管理スキームは、銘柄ブランディングの横断展開スキーム、銘柄取扱情報の横断展開スキーム、消費者の意向・履歴に応じた価値提供スキームの３つに分けられる。図１は、これら３つのスキームのイメージ例を示す。
【0013】
１－３－１．銘柄ブランディングの横断展開スキーム
まず、銘柄ブランディングの横断展開スキームは、造り手が整備した商品情報を売り手や勧め手などの事業者ＤＡに展開するスキームである。このスキームでは売り手や勧め手は、自身のＤＡにタグを設置しておくことで、商品マスタの連携などの密な連携を行うことなく、自身のＤＡ上に銘柄パーツとして商品情報を表示する。
なお売り手や勧め手は、密な連携を行って自身のＤＡにタグを設置することもできる。
まず、銘柄ブランディングの横断展開スキームは、造り手が整備した商品情報を売り手や勧め手などの事業者ＤＡに展開するスキームである。このスキームでは売り手や勧め手は、自身のＤＡにタグを設置しておくことで、商品マスタの連携などの密な連携を行うことなく、自身のＤＡ上に銘柄パーツとして商品情報を表示する。
なお売り手や勧め手は、密な連携を行って自身のＤＡにタグを設置することもできる。
【0014】
売り手等のＤＡ上に表示される銘柄パーツには、以下の情報が含まれる。
（１）基本情報（メーカ、カテゴリ、エリアなど）
（２）属性情報（特徴、製法、原材料など）
（３）イメージ（画像、動画、ＶＲ空間など）
（４）ＰＲコンテンツ（by 造り手、by 売り手）
（５）消費者レビュー
（６）コンテスト受賞履歴、メディア露出履歴
（７）飲める店／買える店マップ
（８）買えるＥＣ店リスト
このうち、（２）～（８）は任意であり、（５）～（８）は造り手が登録しなくてもよい。
（１）基本情報（メーカ、カテゴリ、エリアなど）
（２）属性情報（特徴、製法、原材料など）
（３）イメージ（画像、動画、ＶＲ空間など）
（４）ＰＲコンテンツ（by 造り手、by 売り手）
（５）消費者レビュー
（６）コンテスト受賞履歴、メディア露出履歴
（７）飲める店／買える店マップ
（８）買えるＥＣ店リスト
このうち、（２）～（８）は任意であり、（５）～（８）は造り手が登録しなくてもよい。
【0015】
上記スキームを実現する手段は以下の通りである。
（１）売り手、勧め手が銘柄パーツを組み込む手段
売り手は主に、商品／販売／在庫データを連携することで、事業者独自商品ＩＤに基づき自らのＤＡ内にパーツ読込用のタグを設置する。
一方、勧め手は主に、銘柄ごとにユニバーサル銘柄ＩＤを確認することで、ユニバーサル銘柄ＩＤに基づき自らのＤＡ内にパーツ読込用のタグを設置する。
（２）造り手が銘柄訴求情報を登録する手段
造り手は、当スキームの登録フォームに銘柄訴求情報を入力する。
（１）売り手、勧め手が銘柄パーツを組み込む手段
売り手は主に、商品／販売／在庫データを連携することで、事業者独自商品ＩＤに基づき自らのＤＡ内にパーツ読込用のタグを設置する。
一方、勧め手は主に、銘柄ごとにユニバーサル銘柄ＩＤを確認することで、ユニバーサル銘柄ＩＤに基づき自らのＤＡ内にパーツ読込用のタグを設置する。
（２）造り手が銘柄訴求情報を登録する手段
造り手は、当スキームの登録フォームに銘柄訴求情報を入力する。
【0016】
次に、上記スキームの便益について説明する。図２は、上記スキームの便益の例について説明する図である。
【0017】
同図に示すように、本スキームによれば、造り手は、デザインも含めて高い自由度で商品紹介ページを作成可能である。言い換えると、造り手は、テキスト情報のみならず、フェイス（静止画、動画）、レイアウトなどのデザイン面も含めてブランディングを展開できる。そして造り手は、作成したページ、情報を複数の売り手サイトにそのままの形で展開可能である。
加えて、売り手等は、商品の基本情報を整備する必要がなく、オリジナルの商品紹介パートも追加できる。さらに売り手等は、当該ページを自社ＥＣに組み込むことができ、ユーザの導線を外さない。
加えて、売り手等は、商品の基本情報を整備する必要がなく、オリジナルの商品紹介パートも追加できる。さらに売り手等は、当該ページを自社ＥＣに組み込むことができ、ユーザの導線を外さない。
【0018】
また、同図では記載を省略しているが、消費者は、気になった銘柄についての多様な情報をシームレスに把握できる。
また、同図では記載を省略しているが、本スキームは、特定の１社（ＡＰＩプロバイダ）が整備した情報や機能を第３者が組み込める形ではなく、多数の事業者／消費者が入力した情報を、多数の事業者／消費者が自身のＤＡに組み込める形である。この形式を更に詳述すれば、多数が入力した情報を単純に参照できる形ではなく、多数が入力した情報をユニバーサル銘柄マスタに紐づけて管理することで、多数が入力した情報を銘柄を起点として集約された／構造化された形で、多数が自身のＤＡに組み込める形である。
また、同図では記載を省略しているが、本スキームは、特定の１社（ＡＰＩプロバイダ）が整備した情報や機能を第３者が組み込める形ではなく、多数の事業者／消費者が入力した情報を、多数の事業者／消費者が自身のＤＡに組み込める形である。この形式を更に詳述すれば、多数が入力した情報を単純に参照できる形ではなく、多数が入力した情報をユニバーサル銘柄マスタに紐づけて管理することで、多数が入力した情報を銘柄を起点として集約された／構造化された形で、多数が自身のＤＡに組み込める形である。
【0019】
１－３－２．銘柄取扱情報の横断展開スキーム
銘柄取扱情報の横断展開スキームは、売り手の銘柄取扱情報を勧め手などの事業者ＤＡに展開するスキームである。このスキームでは勧め手は、自身のＤＡにタグを設置しておくことで、商品マスタの連携などの密な連携を行うことなく、自身のＤＡ上に銘柄パーツとして銘柄取扱情報を表示する。
なお勧め手は、密な連携を行って自身のＤＡにタグを設置することもできる。
銘柄取扱情報の横断展開スキームは、売り手の銘柄取扱情報を勧め手などの事業者ＤＡに展開するスキームである。このスキームでは勧め手は、自身のＤＡにタグを設置しておくことで、商品マスタの連携などの密な連携を行うことなく、自身のＤＡ上に銘柄パーツとして銘柄取扱情報を表示する。
なお勧め手は、密な連携を行って自身のＤＡにタグを設置することもできる。
【0020】
勧め手のＤＡ上に表示される銘柄取扱情報には、以下の情報が含まれる。
（１）対象銘柄を飲める飲食店、買える小売店マップ
（２）対象銘柄を買えるＥＣ店リスト
（１）対象銘柄を飲める飲食店、買える小売店マップ
（２）対象銘柄を買えるＥＣ店リスト
【0021】
上記スキームを実現する手段は以下の通りである。
（１）勧め手が銘柄パーツを組み込む手段
勧め手は主に、銘柄ごとにユニバーサル銘柄ＩＤを確認することで、ユニバーサル銘柄ＩＤに基づき自らのＤＡ内にパーツ読込用のタグを設置する。
（２）売り手が取扱情報を登録する手段
具体的には、売り手が取扱銘柄を直接登録する手段、売り手の商品／販売／在庫データを連携する手段、または売り手の仕入先の販売データを連携する手段がある。
（１）勧め手が銘柄パーツを組み込む手段
勧め手は主に、銘柄ごとにユニバーサル銘柄ＩＤを確認することで、ユニバーサル銘柄ＩＤに基づき自らのＤＡ内にパーツ読込用のタグを設置する。
（２）売り手が取扱情報を登録する手段
具体的には、売り手が取扱銘柄を直接登録する手段、売り手の商品／販売／在庫データを連携する手段、または売り手の仕入先の販売データを連携する手段がある。
【0022】
【0023】
図３に示すように、従来の誘客パーツは遷移先固定誘客パーツである。誘導先は多くとも複数であり固定されている。そのため消費者は、「この商品が欲しい」と「ここで買いたい」という２つの欲求を満たせないケースがある。メディアは、パーツ設置の際に、紹介商品のみでなく、遷移先も決めることになる。またメディアは、遷移先を自身で設定したい場合、パーツの作成からコストを負う必要がある。
【0024】
これに対して、本スキームの誘客パーツは遷移先可変型誘客パーツである。誘導先は無制限かつ可変である。そのため消費者は、自身のエリアや嗜好にあったＤＡを選択できる（自動的に絞り込ませることも可能）。メディアは、遷移先を指定せず、「この商品を紹介したい」欲求のみを満たす形でパーツを設置できる。またメディアは、遷移先を指定してパーツを設置することもできる。
【0025】
また図４に示すように、売り手はモールに参加すれば集客コストは安く済むが、デザインや機能の自由度は低い。売り手が独自ＥＣを展開すればデザインや機能の自由度は高いが、従前の誘客パーツでは集客コストが極めて高くなる。これに対して、売り手が本件の誘客パーツ（言い換えると、銘柄パーツ）を用いれば、デザインや機能の自由度が高く、集客コストは安く済む。
【0026】
また、同図では記載を省略しているが、売り手は、多くの勧め手を介して、自らの取扱銘柄に対する購買意欲が高い消費者を誘客できる。勧め手は、特定の売り手に縛られることなく、消費者にお勧め銘柄に対する行動を喚起できる。消費者は、気になった銘柄を飲める店、買える店をシームレスに把握できる。
【0027】
１－３－３．消費者の意向・履歴に応じた価値提供スキーム
消費者の意向・履歴に応じた価値提供スキームは、本スキームのサーバが消費者のプレファレンスを一元的に管理し、このプレファレンスに基づく付加価値サービスを売り手が提供可能にするスキームである。
消費者の意向・履歴に応じた価値提供スキームは、本スキームのサーバが消費者のプレファレンスを一元的に管理し、このプレファレンスに基づく付加価値サービスを売り手が提供可能にするスキームである。
【0028】
売り手により提供可能になるサービスには、以下のサービスが含まれる。
（１）来店客のプレファレンスに基づく商品通知
（２）消費者評価で蓄積された商品特性に基づく接客対応
（３）売り手を横断したリワードプログラム
（４）消費者のプレファレンスに基づく商品の自動選定、販売、配送プログラム
（１）来店客のプレファレンスに基づく商品通知
（２）消費者評価で蓄積された商品特性に基づく接客対応
（３）売り手を横断したリワードプログラム
（４）消費者のプレファレンスに基づく商品の自動選定、販売、配送プログラム
【0029】
上記スキームを実現する手段は以下の通りである。
（１）売り手が付加機能パーツを組み込む手段
売り手は、商品／販売／在庫データを連携することで、事業者独自商品ＩＤに基づき自らのＤＡ内にパーツ読込用のタグを設置する。
（２）消費者がプレファレンスを登録する手段
具体的には、銘柄パーツ上の「飲みたい」を押す手段、本スキームと連携したアプリで飲んだ評価を登録する手段、または本スキームを連携したＥＣで商品を購入する手段がある。
（１）売り手が付加機能パーツを組み込む手段
売り手は、商品／販売／在庫データを連携することで、事業者独自商品ＩＤに基づき自らのＤＡ内にパーツ読込用のタグを設置する。
（２）消費者がプレファレンスを登録する手段
具体的には、銘柄パーツ上の「飲みたい」を押す手段、本スキームと連携したアプリで飲んだ評価を登録する手段、または本スキームを連携したＥＣで商品を購入する手段がある。
【0030】
次に、上記スキームの便益について説明する。図５は、上記スキームの便益の例について説明する図である。
【0031】
同図に示すように、本スキームによれば、売り手は各消費者からプレファレンスを自前で収集する必要がない。また売り手は、自前で収集するより広範な消費者プレファレンスに基づき、よりよいＵＸ（user experience）を提供できる。
加えて消費者は、様々なＤＡで適切なＵＸ（欲しかった商品がリマインドされるなど）を享受できる。また消費者にとって、プレファレンス登録は単一箇所で済み、ＤＡに開示する情報は最小限で済む。
加えて消費者は、様々なＤＡで適切なＵＸ（欲しかった商品がリマインドされるなど）を享受できる。また消費者にとって、プレファレンス登録は単一箇所で済み、ＤＡに開示する情報は最小限で済む。
【0032】
また、同図では記載を省略しているが、売り手は、初めての消費者に対しても適切な提示、提案を行い、購買率を向上できる。また消費者は、初めて利用するお店でも、自身の意向や嗜好に応じた商品を把握できる。
【0033】
１－４．具体的なサービス内容
次に、上記の３つのスキームが提供する具体的なサービス内容について説明する。
１－４－１．銘柄ブランディングの横断展開スキーム
銘柄ブランディングの横断展開スキームは、以下のサービスを提供する。
（１）銘柄情報（基本情報、属性情報）
本スキームは、酒造メーカ向けに銘柄情報登録フォームを提供する。登録された銘柄情報は、「銘柄カード」や「銘柄ページ」に反映される。
（２）銘柄ブランディング（ＰＲページ）
本スキームは、酒造メーカ向けに、お酒に特化したブランディング展開サービスを提供する。登録されたコンテンツは、多様なデジタルメディアに展開できる。
次に、上記の３つのスキームが提供する具体的なサービス内容について説明する。
１－４－１．銘柄ブランディングの横断展開スキーム
銘柄ブランディングの横断展開スキームは、以下のサービスを提供する。
（１）銘柄情報（基本情報、属性情報）
本スキームは、酒造メーカ向けに銘柄情報登録フォームを提供する。登録された銘柄情報は、「銘柄カード」や「銘柄ページ」に反映される。
（２）銘柄ブランディング（ＰＲページ）
本スキームは、酒造メーカ向けに、お酒に特化したブランディング展開サービスを提供する。登録されたコンテンツは、多様なデジタルメディアに展開できる。
【0034】
（３）フェイスデザイン（静止画／動画）
本スキームは、酒造メーカ向けに「銘柄カード」のフェイスデザイン設定機能を提供する。酒造メーカは、「銘柄の顔」として、好みの静止画または動画を登録できる。
（４）３６０度商品画像
本スキームは、酒造メーカ向けに、３６０度商品画像の撮影、展開サービスを提供する。撮影画像は、他社ＥＣサイトなど様々なデジタルメディアに展開できる。
また本スキームは、飲食店向けに、メニュー作成に必要なお酒のラベルを取得できるサービスを提供する。
また本スキームは、お酒を販売するＥＣ事業者向けに、商品画像を組み込める機能を提供する。
本スキームは、酒造メーカ向けに「銘柄カード」のフェイスデザイン設定機能を提供する。酒造メーカは、「銘柄の顔」として、好みの静止画または動画を登録できる。
（４）３６０度商品画像
本スキームは、酒造メーカ向けに、３６０度商品画像の撮影、展開サービスを提供する。撮影画像は、他社ＥＣサイトなど様々なデジタルメディアに展開できる。
また本スキームは、飲食店向けに、メニュー作成に必要なお酒のラベルを取得できるサービスを提供する。
また本スキームは、お酒を販売するＥＣ事業者向けに、商品画像を組み込める機能を提供する。
【0035】
１－４－２．銘柄取扱情報の横断展開スキーム
銘柄取扱情報の横断展開スキームは、以下のサービスを提供する。
（１）商品起点の遷移先拡充
本スキームは、「銘柄カード」に、対象銘柄を「飲めるお店」「買えるお店」をマップ上で表示する機能を提供する。
この機能に伴い、本スキームは、飲食店や酒販店向けに、「銘柄カード」における「飲めるお店」、「買えるお店」として登録できる機能を提供する。また本スキームは、酒類卸事業者向けに、「銘柄カード」における「飲めるお店」、「買えるお店」に卸先を登録できるサービスを提供する。
銘柄取扱情報の横断展開スキームは、以下のサービスを提供する。
（１）商品起点の遷移先拡充
本スキームは、「銘柄カード」に、対象銘柄を「飲めるお店」「買えるお店」をマップ上で表示する機能を提供する。
この機能に伴い、本スキームは、飲食店や酒販店向けに、「銘柄カード」における「飲めるお店」、「買えるお店」として登録できる機能を提供する。また本スキームは、酒類卸事業者向けに、「銘柄カード」における「飲めるお店」、「買えるお店」に卸先を登録できるサービスを提供する。
【0036】
また本スキームは、「銘柄カード」に、対象銘柄を「買えるサイト」を表示する機能を提供する。この機能に伴い、本スキームは、お酒を販売するＥＣ事業者向けに、「銘柄カード」における「買えるサイト」として登録できる機能を提供する。
【0037】
（２）ユーザのコンテキストに応じた遷移先変更
本スキームは、「銘柄カード」における「買えるサイト」が、閲覧者のエリアに応じて最適化される機能を提供する。
また本スキームは、「銘柄カード」における「飲めるお店」、「買えるお店」、「買えるサイト」が、閲覧者の嗜好に基づき最適化される機能を提供する。
本スキームは、「銘柄カード」における「買えるサイト」が、閲覧者のエリアに応じて最適化される機能を提供する。
また本スキームは、「銘柄カード」における「飲めるお店」、「買えるお店」、「買えるサイト」が、閲覧者の嗜好に基づき最適化される機能を提供する。
【0038】
１－４－３．銘柄パーツの組込先拡充
銘柄ブランディングの横断展開スキームおよび銘柄取扱情報の横断展開スキームは、以下のサービスを提供する。
（１）売り手向け
本スキームは、お酒を販売するＥＣ事業者向けに「銘柄ページ」を提供する。ＥＣ事業者は、自前で銘柄情報を整備せずとも、自社ＥＣサイトに銘柄ページを組み込める。
この機能に伴い、本スキームは、お酒を販売するＥＣ事業者向けに、銘柄ページにおけるマップボタン、カートボタンの出力如何を設定できる機能を提供する。また本スキームは、お酒を販売するＥＣ事業者向けに、銘柄ページにおける「買えるサイト」の遷移先を登録、限定できる機能を提供する。
銘柄ブランディングの横断展開スキームおよび銘柄取扱情報の横断展開スキームは、以下のサービスを提供する。
（１）売り手向け
本スキームは、お酒を販売するＥＣ事業者向けに「銘柄ページ」を提供する。ＥＣ事業者は、自前で銘柄情報を整備せずとも、自社ＥＣサイトに銘柄ページを組み込める。
この機能に伴い、本スキームは、お酒を販売するＥＣ事業者向けに、銘柄ページにおけるマップボタン、カートボタンの出力如何を設定できる機能を提供する。また本スキームは、お酒を販売するＥＣ事業者向けに、銘柄ページにおける「買えるサイト」の遷移先を登録、限定できる機能を提供する。
【0039】
（２）勧め手向け（訴求機能は売り手向けと同じ）
本スキームは、メディア事業者やブロガー向けに「銘柄カード」を提供する。メディア事業者等は、自身のサイトに銘柄カードを組み込める。
この機能に伴い、本スキームは、メディア事業者やブロガー向けに、銘柄カードにおけるマップボタン、カートボタンの出力如何を設定できる機能を提供する。また本スキームは、メディア事業者やブロガー向けに、銘柄カードにおける「買えるサイト」の遷移先を登録、限定できる機能を提供する。
本スキームは、メディア事業者やブロガー向けに「銘柄カード」を提供する。メディア事業者等は、自身のサイトに銘柄カードを組み込める。
この機能に伴い、本スキームは、メディア事業者やブロガー向けに、銘柄カードにおけるマップボタン、カートボタンの出力如何を設定できる機能を提供する。また本スキームは、メディア事業者やブロガー向けに、銘柄カードにおける「買えるサイト」の遷移先を登録、限定できる機能を提供する。
【0040】
１－４－４．消費者の意向・履歴に応じた価値提供スキーム
消費者の意向・履歴に応じた価値提供スキームは、以下のサービスを提供する。
（１）来店客のプレファレンスに基づく商品通知
（１－１）ＥＣサイト向け
本スキームは、お酒を販売するＥＣ事業者向けに、ＥＣサイト訪問者が「飲みたい」に登録した銘柄を目立たせる機能を提供する。
また本スキームは、お酒を販売するＥＣ事業者向けに、ＥＣサイト訪問者が評価した実績に基づき、その訪問者にお勧めの商品を目立たせる機能を提供する。
消費者の意向・履歴に応じた価値提供スキームは、以下のサービスを提供する。
（１）来店客のプレファレンスに基づく商品通知
（１－１）ＥＣサイト向け
本スキームは、お酒を販売するＥＣ事業者向けに、ＥＣサイト訪問者が「飲みたい」に登録した銘柄を目立たせる機能を提供する。
また本スキームは、お酒を販売するＥＣ事業者向けに、ＥＣサイト訪問者が評価した実績に基づき、その訪問者にお勧めの商品を目立たせる機能を提供する。
【0041】
（１－２）飲食店、小売店向け
本スキームは、飲食店や酒販店向けに、お店の取扱銘柄のうち、来店者が「飲みたい」に登録した銘柄を来店者に通知するサービスを提供する。
また本スキームは、飲食店や酒販店向けに、お店の取扱銘柄のうち、来店者が評価した実績に基づくお勧めの銘柄を来店者に通知するサービスを提供する。
本スキームは、飲食店や酒販店向けに、お店の取扱銘柄のうち、来店者が「飲みたい」に登録した銘柄を来店者に通知するサービスを提供する。
また本スキームは、飲食店や酒販店向けに、お店の取扱銘柄のうち、来店者が評価した実績に基づくお勧めの銘柄を来店者に通知するサービスを提供する。
【0042】
（２）消費者評価で蓄積された商品特性に基づく接客対応
本スキームは、お酒を販売するＥＣ事業者向けに、消費者のニーズやリクエストに応じて商品を推薦する、銘柄推薦ＡＩを組み込めるサービスを提供する。
また本スキームは、酒造メーカや酒類卸事業者向けに、銘柄推薦ＡＩサービスを、自社営業担当者向けアプリに組み込めるサービスを提供する。
本スキームは、お酒を販売するＥＣ事業者向けに、消費者のニーズやリクエストに応じて商品を推薦する、銘柄推薦ＡＩを組み込めるサービスを提供する。
また本スキームは、酒造メーカや酒類卸事業者向けに、銘柄推薦ＡＩサービスを、自社営業担当者向けアプリに組み込めるサービスを提供する。
【0043】
（３）売り手を横断したリワードプログラム
本スキームは、酒造メーカ向けに、購入先に依存しないスタンプカード機能を提供する。酒造メーカは、購入先を問わずに消費者に対する販促企画を展開できるようになる。
また本スキームは、地方自治体向けに、購入先に依存しないお酒のスタンプカード機能を提供する。地方自治体は、購入先を問わずに地元銘柄の販促企画を展開できるようになる。
本スキームは、酒造メーカ向けに、購入先に依存しないスタンプカード機能を提供する。酒造メーカは、購入先を問わずに消費者に対する販促企画を展開できるようになる。
また本スキームは、地方自治体向けに、購入先に依存しないお酒のスタンプカード機能を提供する。地方自治体は、購入先を問わずに地元銘柄の販促企画を展開できるようになる。
【0044】
【0045】
本システムを構成する商品情報管理サーバ６１０は、酒類に関する情報を管理するサーバである。
消費者ＤＤ６２０は、酒類を飲用する消費者（以下の説明では、「ユーザ」とも呼ぶ。）が使用する端末である。この消費者ＤＤ６２０は、当スキームＤＡ６２１と事業者ＤＡ６２２を備える。当スキームＤＡ６２１の一部は、事業者ＤＡ６２２に組み込まれている。
消費者ＤＤ６２０は、酒類を飲用する消費者（以下の説明では、「ユーザ」とも呼ぶ。）が使用する端末である。この消費者ＤＤ６２０は、当スキームＤＡ６２１と事業者ＤＡ６２２を備える。当スキームＤＡ６２１の一部は、事業者ＤＡ６２２に組み込まれている。
【0046】
事業者ＤＤ６３０は、酒類を取り扱う事業者が使用する端末である。事業者ＤＤ６３０には、それぞれ異なる造り手により使用される複数の事業者ＤＤ６３０と、それぞれ異なる売り手または勧め手により使用される複数の事業者ＤＤ６３０がある。各事業者ＤＤ６３０は、当スキームＤＡ６３１を備える。
事業者サーバ６４０は、酒類を取り扱う事業者により管理されるサーバである。
事業者サーバ６４０は、酒類を取り扱う事業者により管理されるサーバである。
【0047】
商品情報管理サーバ６１０は、消費者ＤＤ６２０、事業者ＤＤ６３０および事業者サーバ６４０と有線または無線のネットワークを介して相互に接続され、このネットワークを介して情報を送受信することができる。
事業者サーバ６４０は、消費者ＤＤ６２０および事業者ＤＤ６３０と有線または無線のネットワークを介して相互に接続され、このネットワークを介して情報を送受信することができる。
なお、図６には消費者ＤＤ６２０、事業者ＤＤ６３０、事業者サーバ６４０が１つずつしか示されていないが、それぞれ複数、商品情報管理システム６００に含まれてよい。
事業者サーバ６４０は、消費者ＤＤ６２０および事業者ＤＤ６３０と有線または無線のネットワークを介して相互に接続され、このネットワークを介して情報を送受信することができる。
なお、図６には消費者ＤＤ６２０、事業者ＤＤ６３０、事業者サーバ６４０が１つずつしか示されていないが、それぞれ複数、商品情報管理システム６００に含まれてよい。
【0048】
商品情報管理システム６００の各構成機器は、例えば、スマートフォン、タブレット、携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末（モバイル端末）でもよいし、メガネ型や腕時計型、着衣型などのウェアラブル端末でもよい。また、各構成機器は、据置型または携帯型のコンピュータや、クラウドやネットワーク上に配置されるサーバでもよい。また、各構成機器は、機能としてはＶＲ（仮想現実：Virtual Reality）端末、ＡＲ（拡張現実：Augmented Reality）端末、ＭＲ（複合現実：Mixed Reality）端末でもよい。あるいは、各構成機器は、これらの複数の端末の組合せであってもよい。例えば、１台のスマートフォンと１台のウェアラブル端末との組合せが論理的に一つの端末として機能し得る。また、各構成機器は、これら以外の情報処理端末であってもよい。
【0049】
各構成機器は、それぞれオペレーティングシステムやアプリケーション、プログラムなどを実行するプロセッサと、ＲＡＭ（Random Access Memory）等の主記憶装置と、ＩＣカードやハードディスクドライブ、ＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶装置と、ネットワークカードや無線通信モジュール、モバイル通信モジュール等の通信制御部と、タッチパネルやキーボード、マウス、音声入力、カメラ部の撮像による動き検知による入力などの入力装置と、モニタやディスプレイ等の出力装置とを備える。なお、出力装置は、外部のモニタやディスプレイ、プロジェクタ、プリンタ、機器などに、出力するための情報を送信する装置や端子であってもよい。
【0050】
主記憶装置には、各種プログラムやアプリケーションなど（モジュール）が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することで全体システムの各機能要素が実現される。なお、これらの各モジュールは集積化する等によりハードウェアで実装してもよい。また、各モジュールはそれぞれ独立したプログラムやアプリケーションでもよいが、１つの統合プログラムやアプリケーションの中の一部のサブプログラムや関数などの形で実装されていてもよい。
【0051】
本明細書では、各モジュールが、処理を行う主体（主語）として記載をしているが、実際には各種プログラムやアプリケーションなど（モジュール）を処理するプロセッサが処理を実行する。
【0052】
補助記憶装置には、各種データベース（ＤＢ）が記憶されている。「データベース」とは、プロセッサまたは外部のコンピュータからの任意のデータ操作（例えば、抽出、追加、削除、上書きなど）に対応できるようにデータ集合を記憶する機能要素（記憶部）である。データベースの実装方法は限定されず、例えばデータベース管理システムでもよいし、表計算ソフトウェアでもよいし、ＸＭＬ、ＪＳＯＮなどのテキストファイルでもよい。
【0053】
１－５－１．商品情報管理サーバ６１０
図７は、商品情報管理サーバ６１０のハードウェア構成の例を示す。
商品情報管理サーバ６１０は、例えば、クラウド上に配置されたサーバで構成される。
本サーバの主記憶装置７０１には、認証モジュール７１１、データ連携モジュール７１２、組込タグ管理モジュール７１３、登録情報管理モジュール７１４、意向／履歴管理モジュール７１５、銘柄パーツ情報提供モジュール７１６、マップ情報提供モジュール７１７、ＥＣ情報提供モジュール７１８、商品情報提供モジュール７１９、銘柄提案モジュール７２０、リワードプログラム管理モジュール７２１、リワード管理モジュール７２２
プログラム管理モジュール７２３、商品選定モジュール７２４、投稿管理モジュール７２５、評価管理モジュール７２６、モデル生成モジュール７２７、補正モジュール７２８
嗜好推定モジュール７２９等のプログラムが記憶されている。これらのプログラムをプロセッサ７０３が実行することで商品情報管理サーバ６１０の各機能要素が実現される。
以下、各モジュールについて説明する。
図７は、商品情報管理サーバ６１０のハードウェア構成の例を示す。
商品情報管理サーバ６１０は、例えば、クラウド上に配置されたサーバで構成される。
本サーバの主記憶装置７０１には、認証モジュール７１１、データ連携モジュール７１２、組込タグ管理モジュール７１３、登録情報管理モジュール７１４、意向／履歴管理モジュール７１５、銘柄パーツ情報提供モジュール７１６、マップ情報提供モジュール７１７、ＥＣ情報提供モジュール７１８、商品情報提供モジュール７１９、銘柄提案モジュール７２０、リワードプログラム管理モジュール７２１、リワード管理モジュール７２２
プログラム管理モジュール７２３、商品選定モジュール７２４、投稿管理モジュール７２５、評価管理モジュール７２６、モデル生成モジュール７２７、補正モジュール７２８
嗜好推定モジュール７２９等のプログラムが記憶されている。これらのプログラムをプロセッサ７０３が実行することで商品情報管理サーバ６１０の各機能要素が実現される。
以下、各モジュールについて説明する。
【0054】
認証モジュール７１１は、消費者ＤＤ６２０のユーザまたは事業者ＤＤ７３０を使用する事業者の認証処理を実行する。
【0055】
データ連携モジュール７１２は、事業者サーバ６４０または事業者ＤＤ６３０との間で商品／販売／在庫データの連携処理を実行する。
この連携処理を通じて当該モジュールは、事業者サーバ６４０等から送信された商品を購入または消費可能な店舗に関する店舗情報を管理する。具体的には当該モジュールは、商品に関する商品情報と、商品を購入または消費可能な店舗の商品取扱情報と、店舗に関する店舗情報とを管理する。管理される商品取扱情報には、店舗の商品在庫情報が含まれる。
この連携処理を通じて当該モジュールは、事業者サーバ６４０等から送信された商品を購入または消費可能な店舗に関する店舗情報を管理する。具体的には当該モジュールは、商品に関する商品情報と、商品を購入または消費可能な店舗の商品取扱情報と、店舗に関する店舗情報とを管理する。管理される商品取扱情報には、店舗の商品在庫情報が含まれる。
【0056】
なお、商品取扱情報は、以下のいずれの方法で登録または更新される。
（１）店舗が使用する事業者ＤＤ６３０を介して商品ごとに手動登録する。
（２）店舗と連携した商品マスタ、売上データ、在庫データのうちのいずれかを商品情報管理サーバ６１０と連携する。
（３）店舗が商品を仕入れている事業者の売上データを商品情報管理サーバ６１０と連携する。
（１）店舗が使用する事業者ＤＤ６３０を介して商品ごとに手動登録する。
（２）店舗と連携した商品マスタ、売上データ、在庫データのうちのいずれかを商品情報管理サーバ６１０と連携する。
（３）店舗が商品を仕入れている事業者の売上データを商品情報管理サーバ６１０と連携する。
【0057】
組込タグ管理モジュール７１３は、商品の売り手または勧め手により予め設定された、商品パーツのボタン設定情報を管理する。ここで言う商品パーツとは、より具体的には銘柄パーツのことである。銘柄パーツには、カード形式の銘柄カードと、ページ形式の銘柄ページがある。
【0058】
登録情報管理モジュール７１４は、事業者ＤＤ６３０から送信された商品関連情報を管理する。管理される商品関連情報には、造り手により登録される銘柄訴求情報や、売り手により登録される取扱銘柄情報が含まれる。
【0059】
意向／履歴管理モジュール７１５は、消費者ＤＤ６２０から送信された商品情報を一元的に管理する。管理される商品情報は、消費者ＤＤ６２０のユーザが飲みたい銘柄の情報である。
また当該モジュールは、消費者ＤＤ６２０から送信された実績情報を管理する。管理される実績情報は、消費者ＤＤ６２０のユーザが飲んだ銘柄またはお気に入りの銘柄の情報である。当該モジュールは実績情報を、商品の購入または消費した店舗を横断して、リワードプログラム情報と対応付けて管理する。
また当該モジュールは、消費者ＤＤ６２０から送信された実績情報を管理する。管理される実績情報は、消費者ＤＤ６２０のユーザが飲んだ銘柄またはお気に入りの銘柄の情報である。当該モジュールは実績情報を、商品の購入または消費した店舗を横断して、リワードプログラム情報と対応付けて管理する。
【0060】
銘柄パーツ情報提供モジュール７１６は、商品パーツに関する情報を消費者ＤＤ６２０に送信する。
当該モジュールは、消費者ＤＤ６２０において所定のコードが組み込まれた画面が表示される場合に、商品関連情報を消費者ＤＤ６２０に送信する。ここで、所定のコードとは、商品パーツを表示するためのコードである。
当該モジュールは、消費者ＤＤ６２０において所定のコードが組み込まれた画面が表示される場合に、商品関連情報を消費者ＤＤ６２０に送信する。ここで、所定のコードとは、商品パーツを表示するためのコードである。
【0061】
マップ情報提供モジュール７１７は、消費者ＤＤ６２０から送信された情報要求を受けて、対象商品を取り扱う実店舗の店舗情報を消費者ＤＤ６２０に送信する。
その際、当該モジュールは、対象商品の在庫を有する店舗の店舗情報を送信可能である。また当該モジュールは、消費者ＤＤ６２０のユーザの現在位置に応じた店舗の店舗情報を送信可能である。また当該モジュールは、消費者ＤＤ６２０のユーザの嗜好に応じた店舗情報を送信可能である。
その際、当該モジュールは、対象商品の在庫を有する店舗の店舗情報を送信可能である。また当該モジュールは、消費者ＤＤ６２０のユーザの現在位置に応じた店舗の店舗情報を送信可能である。また当該モジュールは、消費者ＤＤ６２０のユーザの嗜好に応じた店舗情報を送信可能である。
【0062】
ＥＣ情報提供モジュール７１８は、消費者ＤＤ６２０から送信された情報要求を受けて、対象商品を取り扱うＥＣ店舗の店舗情報を消費者ＤＤ６２０に送信する。
その際、当該モジュールは、対象商品の在庫を有する店舗の店舗情報を送信可能である。また当該モジュールは、消費者ＤＤ６２０のユーザの現在位置に応じた店舗の店舗情報を送信可能である。また当該モジュールは、消費者ＤＤ６２０のユーザの嗜好に応じた店舗情報を送信可能である。
その際、当該モジュールは、対象商品の在庫を有する店舗の店舗情報を送信可能である。また当該モジュールは、消費者ＤＤ６２０のユーザの現在位置に応じた店舗の店舗情報を送信可能である。また当該モジュールは、消費者ＤＤ６２０のユーザの嗜好に応じた店舗情報を送信可能である。
【0063】
商品情報提供モジュール７１９は、消費者ＤＤ６２０のユーザが店舗に訪問又はアクセスした場合に、消費者ＤＤ６２０に商品情報を送信する。
ここで、消費者ＤＤ６２０のユーザが店舗に訪問又はアクセスした場合とは、具体的には、ユーザがオンライン店舗にアクセスし、商品の売り手により所定の装飾モジュールが組み込まれた画面を表示する場合である。または、当該場合とは、ユーザが実店舗に訪問し、当該店舗が対象商品を取り扱っている場合である。
当該モジュールにより消費者ＤＤ６２０に対して送信される商品情報は、ユーザが購入または消費した、もしくはユーザが購入または消費を希望する商品の情報、または、当該商品の情報に基づいてユーザの嗜好に合致すると推定された商品の情報である。
ここで、消費者ＤＤ６２０のユーザが店舗に訪問又はアクセスした場合とは、具体的には、ユーザがオンライン店舗にアクセスし、商品の売り手により所定の装飾モジュールが組み込まれた画面を表示する場合である。または、当該場合とは、ユーザが実店舗に訪問し、当該店舗が対象商品を取り扱っている場合である。
当該モジュールにより消費者ＤＤ６２０に対して送信される商品情報は、ユーザが購入または消費した、もしくはユーザが購入または消費を希望する商品の情報、または、当該商品の情報に基づいてユーザの嗜好に合致すると推定された商品の情報である。
【0064】
銘柄提案モジュール７２０は、消費者ＤＤ６２０から送信された商品提案要求を受けて、ユーザにより指定された抽出条件に基づいて商品情報を抽出し、消費者ＤＤ６２０に送信する。
【0065】
リワードプログラム管理モジュール７２１は、事業者ＤＤ６３０またはその他の通信端末から送信されたリワードプログラム情報を管理する。ここで言う、その他の通信端末とは、例えば、地方自治体の職員により使用される通信端末のことである。
【0066】
リワード管理モジュール７２２は、蓄積されたリワードを消化するための処理を実行する。
【0067】
プログラム管理モジュール７２３は、事業者ＤＤ６３０から受領したサブスクリプションプログラムに関する情報を事業者サブスクリプションプログラムテーブル３３００に登録する。
【0068】
商品選定モジュール７２４は、サブスクリプションプログラムに従って消費者ＤＤ６２０のユーザに配送される商品を選定する。
【0069】
投稿管理モジュール７２５は、消費者ＤＤ６２０から受信した投稿に関する情報をトランザクションＤＢ７４１に格納する。
【0070】
評価管理モジュール７２６は、複数の商品について、当該商品の評価を相対的に表す評価値を管理する。具体的には当該モジュールは、総合評価値と、複数の評価軸についての要素評価値を管理する。
【0071】
モデル生成モジュール７２７は、投稿銘柄テーブル１２００に蓄積された総合評価値と、銘柄特徴テーブル１７００に格納された適用値とに基づいて、嗜好モデルを生成する。
【0072】
補正モジュール７２８は、銘柄特徴テーブル１７００に格納された格納値に基づいて適用値を算出する。
【0073】
嗜好推定モジュール７２９は、銘柄特徴テーブル１７００に格納された適用値を嗜好モデルに入力して、各商品の総合評価値を推定する。
【0074】
次に、商品情報管理サーバ６１０の補助記憶装置７０２について説明する。
補助記憶装置７０２は、トランザクションＤＢ７４１、解析データＤＢ７４２、マスタＤＢ７４３、設定ＤＢ７４４、要素ＤＢ７４５、関係ＤＢ７４６等のデータベースを備える。各ＤＢを構成するテーブルについては後述する。
補助記憶装置７０２は、トランザクションＤＢ７４１、解析データＤＢ７４２、マスタＤＢ７４３、設定ＤＢ７４４、要素ＤＢ７４５、関係ＤＢ７４６等のデータベースを備える。各ＤＢを構成するテーブルについては後述する。
【0075】
１－５－２．消費者ＤＤ６２０
図８は、消費者ＤＤ６２０のハードウェア構成の例を示す。
消費者ＤＤ６２０は、例えば、スマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の端末で構成される。
本ＤＤの主記憶装置８０１には、認証モジュール８１１、意向／履歴登録モジュール８１２、銘柄パーツ表示モジュール８１３、マップ表示モジュール８１４、ＥＣリスト表示モジュール８１５、商品通知モジュール８１６、提案銘柄通知モジュール８１７、リワード利用モジュール８１８、投稿モジュール８１９、評価送信モジュール８２０、表示モジュール８２１等のプログラムが記憶されている。これらのプログラムをプロセッサ８０３が実行することで消費者ＤＤ６２０の各機能要素が実現される。
以下、各モジュールについて説明する。
図８は、消費者ＤＤ６２０のハードウェア構成の例を示す。
消費者ＤＤ６２０は、例えば、スマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の端末で構成される。
本ＤＤの主記憶装置８０１には、認証モジュール８１１、意向／履歴登録モジュール８１２、銘柄パーツ表示モジュール８１３、マップ表示モジュール８１４、ＥＣリスト表示モジュール８１５、商品通知モジュール８１６、提案銘柄通知モジュール８１７、リワード利用モジュール８１８、投稿モジュール８１９、評価送信モジュール８２０、表示モジュール８２１等のプログラムが記憶されている。これらのプログラムをプロセッサ８０３が実行することで消費者ＤＤ６２０の各機能要素が実現される。
以下、各モジュールについて説明する。
【0076】
認証モジュール８１１は、消費者ＤＤ６２０のユーザの認証処理を実行する。
【0077】
意向／履歴登録モジュール８１２は、ユーザが購入または消費した、もしくはユーザが購入または消費を希望する商品の商品情報を商品情報管理サーバ６１０に送信する。
また当該モジュールは、ユーザが商品を購入または消費した場合に、当該購入または消費の実績情報を商品情報管理サーバ６１０に送信する。
また当該モジュールは、ユーザが商品を購入または消費した場合に、当該購入または消費の実績情報を商品情報管理サーバ６１０に送信する。
【0078】
銘柄パーツ表示モジュール８１３は、売り手または勧め手により任意にコードが組み込まれた画面を表示する場合に、商品情報管理サーバ６１０から商品関連情報を取得して商品パーツを表示する。表示される商品パーツには、取得した商品関連情報と選択用のボタンが含まれる。
選択用のボタンには、実店舗に関する店舗情報を表示するための第１ボタンと、オンライン店舗に関する店舗情報を表示するための第２ボタンと、商品詳細情報を表示するための第３ボタンが含まれる。このうち、第３ボタンがユーザにより選択されると、当該モジュールは、商品の詳細情報をさらに有するように表示領域が拡大された商品パーツを表示する。
商品パーツに表示されるボタンは、売り手または勧め手により予め選択され、商品情報管理サーバ６１０から送信されるボタン設定情報により決定される。
選択用のボタンには、実店舗に関する店舗情報を表示するための第１ボタンと、オンライン店舗に関する店舗情報を表示するための第２ボタンと、商品詳細情報を表示するための第３ボタンが含まれる。このうち、第３ボタンがユーザにより選択されると、当該モジュールは、商品の詳細情報をさらに有するように表示領域が拡大された商品パーツを表示する。
商品パーツに表示されるボタンは、売り手または勧め手により予め選択され、商品情報管理サーバ６１０から送信されるボタン設定情報により決定される。
【0079】
マップ表示モジュール８１４は、商品パーツのマップボタンがユーザにより選択されると、商品情報管理サーバ６１０に対して情報要求を送信する。当該モジュールは、その情報要求に対して商品情報管理サーバ６１０から送信されてくる店舗の店舗情報をマップ上に表示する。
【0080】
ＥＣリスト表示モジュール８１５は、商品パーツのカートボタンがユーザにより選択されると、商品情報管理サーバ６１０に対して情報要求を送信する。当該モジュールは、その情報要求に対して商品情報管理サーバ６１０から送信されてくる店舗の店舗情報をリスト形式で表示する。
【0081】
商品通知モジュール８１６は、ユーザが店舗に訪問又はアクセスした場合に、商品情報を商品情報管理サーバ６１０に対して要求して取得し、当該ユーザに通知する。
ここで、ユーザが店舗に訪問又はアクセスした場合とは、具体的には、ユーザがオンライン店舗にアクセスし、商品の売り手により所定の装飾モジュールが組み込まれた画面を表示する場合である。または、当該場合とは、ユーザが実店舗に訪問し、当該店舗が対象商品を取り扱っている場合である。
ここで、ユーザが店舗に訪問又はアクセスした場合とは、具体的には、ユーザがオンライン店舗にアクセスし、商品の売り手により所定の装飾モジュールが組み込まれた画面を表示する場合である。または、当該場合とは、ユーザが実店舗に訪問し、当該店舗が対象商品を取り扱っている場合である。
【0082】
当該モジュールにより取得される商品情報は、ユーザが購入または消費した、もしくはユーザが購入または消費を希望する商品の情報、または、当該商品の情報に基づいてユーザの嗜好に合致すると推定された商品の情報である。
ユーザにより訪問またはアクセスされる店舗は、それぞれ異なる売り手により運営される複数の店舗のうちの一店舗である。
ユーザにより訪問またはアクセスされる店舗は、それぞれ異なる売り手により運営される複数の店舗のうちの一店舗である。
【0083】
提案銘柄通知モジュール８１７は、接客パーツを用いて提案要求を商品情報管理サーバ６１０に対して送信する。当該モジュールは、その提案要求に対して商品情報管理サーバ６１０から送信されてくる商品情報を表示する。
上記の接客パーツは、商品販売画面に組み込まれ、当該画面が消費者ＤＤ６２０において表示されている時に利用される。または、当該接客パーツは、アプリケーションに組み込まれ、当該アプリケーションが消費者ＤＤ６２０において実行されたときに利用される。
上記の接客パーツは、商品販売画面に組み込まれ、当該画面が消費者ＤＤ６２０において表示されている時に利用される。または、当該接客パーツは、アプリケーションに組み込まれ、当該アプリケーションが消費者ＤＤ６２０において実行されたときに利用される。
【0084】
リワード利用モジュール８１８は、蓄積されたリワードを利用するための処理を実行する。
【0085】
投稿モジュール８１９は、ユーザの入力操作に従って商品の投稿情報を生成し、商品情報管理サーバ６１０に送信する。
【0086】
評価送信モジュール８２０は、ユーザにより入力された商品の評価値を商品情報管理サーバ６１０に送信する。
【0087】
表示モジュール８２１は、各種情報を表示する。例えば当該モジュールは、商品の売り手により接客パーツが組み込まれた商品販売画面を表示する。
【0088】
次に、消費者ＤＤ６２０の補助記憶装置８０２について説明する。
補助記憶装置８０２は、消費者ＤＤデータ８３１を記憶する。この消費者ＤＤデータ８３１は、例えば、商品情報管理サーバ６１０から受信する各種データである。
補助記憶装置８０２は、消費者ＤＤデータ８３１を記憶する。この消費者ＤＤデータ８３１は、例えば、商品情報管理サーバ６１０から受信する各種データである。
【0089】
１－５－３．事業者ＤＤ６３０
図９は、事業者ＤＤ６３０のハードウェア構成の例を示す。
事業者ＤＤ６３０は、例えば、スマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の端末で構成される。
本ＤＤの主記憶装置９０１には、認証モジュール９１１、組込タグ設定モジュール９１２、情報登録モジュール９１３、コード表示モジュール９１４、リワードプログラム登録モジュール９１５、プログラム登録モジュール９１６等のプログラムが記憶されている。これらのプログラムをプロセッサ９０３が実行することで事業者ＤＤ６３０の各機能要素が実現される。
以下、各モジュールについて説明する。
図９は、事業者ＤＤ６３０のハードウェア構成の例を示す。
事業者ＤＤ６３０は、例えば、スマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の端末で構成される。
本ＤＤの主記憶装置９０１には、認証モジュール９１１、組込タグ設定モジュール９１２、情報登録モジュール９１３、コード表示モジュール９１４、リワードプログラム登録モジュール９１５、プログラム登録モジュール９１６等のプログラムが記憶されている。これらのプログラムをプロセッサ９０３が実行することで事業者ＤＤ６３０の各機能要素が実現される。
以下、各モジュールについて説明する。
【0090】
認証モジュール９１１は、事業者ＤＤ６３０を使用する事業者の認証処理を実行する。
【0091】
組込タグ設定モジュール９１２は、商品関連情報を任意の消費者閲覧用の画面に組み込むためのコードを、売り手または勧め手が利用可能なように取得する。
【0092】
情報登録モジュール９１３は、造り手が商品に関する商品情報を入力するための登録フォームを表示し、当該登録フォームに入力された商品関連情報を商品情報管理サーバ６１０に送信する。送信する商品関連情報には、商品に関する画像（例えば、商品パーツの背景画像）を含めることができる。
また当該モジュールは、売り手または勧め手により入力された商品に関する商品関連情報を商品情報管理サーバ６１０に送信する。
また当該モジュールは、造り手、売り手または勧め手により入力された店舗情報を商品情報管理サーバ６１０に送信する。なお、当該モジュールは、勧め手により入力された店舗情報については、勧め手により自身の媒体に商品パーツが組み込まれる場合に送信する。なお、ここで言う勧め手には、商品パーツが組み込まれた画面を制作および提供する任意の事業者が含まれる。
また当該モジュールは、売り手または勧め手により入力された商品に関する商品関連情報を商品情報管理サーバ６１０に送信する。
また当該モジュールは、造り手、売り手または勧め手により入力された店舗情報を商品情報管理サーバ６１０に送信する。なお、当該モジュールは、勧め手により入力された店舗情報については、勧め手により自身の媒体に商品パーツが組み込まれる場合に送信する。なお、ここで言う勧め手には、商品パーツが組み込まれた画面を制作および提供する任意の事業者が含まれる。
【0093】
コード表示モジュール９１４は、ＱＲコード（登録商標）入りのポップ広告を表示する。
【0094】
リワードプログラム登録モジュール９１５は、造り手または勧め手がリワードプログラム情報を入力するための登録フォームを表示し、当該登録フォームに入力されたリワードプログラム情報を商品情報管理サーバ６１０に送信する。
【0095】
プログラム登録モジュール９１６は、サブスクリプションプログラムを商品情報管理サーバ６１０に登録する。
【0096】
次に、事業者ＤＤ６３０の補助記憶装置９０２について説明する。
補助記憶装置９０２は、事業者ＤＤデータ９２１を記憶する。この事業者ＤＤデータ９２１は、例えば、商品情報管理サーバ６１０に送信する各種データである。
補助記憶装置９０２は、事業者ＤＤデータ９２１を記憶する。この事業者ＤＤデータ９２１は、例えば、商品情報管理サーバ６１０に送信する各種データである。
【0097】
【0098】
図１１は、投稿テーブル１１００の例を示す。
投稿テーブル１１００は、消費者ＤＤ６２０から受信した投稿情報を記憶する。当該テーブルは、投稿ＩＤ１１０１、ユーザＩＤ１１０２、投稿タイプ１１０３、銘柄数１１０４、タイトル１１０５等のフィールドを有する。これらのフィールドのうち、投稿タイプ１１０３には、投稿時における記入対象項目の選定基準を示す値が格納される。銘柄数１１０４には、投稿の対象が単一銘柄であるか、それとも複数銘柄であるかを示す値が格納される。
投稿テーブル１１００は、消費者ＤＤ６２０から受信した投稿情報を記憶する。当該テーブルは、投稿ＩＤ１１０１、ユーザＩＤ１１０２、投稿タイプ１１０３、銘柄数１１０４、タイトル１１０５等のフィールドを有する。これらのフィールドのうち、投稿タイプ１１０３には、投稿時における記入対象項目の選定基準を示す値が格納される。銘柄数１１０４には、投稿の対象が単一銘柄であるか、それとも複数銘柄であるかを示す値が格納される。
【0099】
図１２は、投稿銘柄テーブル１２００の例を示す。
投稿銘柄テーブル１２００は、消費者ＤＤ６２０から受信した銘柄に対する総合評価値を記憶する。当該テーブルは、投稿ＩＤ１２０１、銘柄番号１２０２、銘柄ＩＤ１２０３、総合評価（良し悪し）１２０４、総合評価（好き嫌い）１２０５、コメント１２０６等のフィールドを有する。これらのフィールドのうち、銘柄番号１２０２に格納される値は、投稿編集中に対象銘柄が変更される可能性があることを考慮し、投稿銘柄テーブル１２００と投稿評価テーブル１３００の間のキーとして利用される。また、総合評価（良し悪し）１２０４に格納される値と総合評価（好き嫌い）１２０５に格納される値は、それぞれ選択的に利用されてよい。
投稿銘柄テーブル１２００は、消費者ＤＤ６２０から受信した銘柄に対する総合評価値を記憶する。当該テーブルは、投稿ＩＤ１２０１、銘柄番号１２０２、銘柄ＩＤ１２０３、総合評価（良し悪し）１２０４、総合評価（好き嫌い）１２０５、コメント１２０６等のフィールドを有する。これらのフィールドのうち、銘柄番号１２０２に格納される値は、投稿編集中に対象銘柄が変更される可能性があることを考慮し、投稿銘柄テーブル１２００と投稿評価テーブル１３００の間のキーとして利用される。また、総合評価（良し悪し）１２０４に格納される値と総合評価（好き嫌い）１２０５に格納される値は、それぞれ選択的に利用されてよい。
【0100】
なお、銘柄番号と銘柄ＩＤを紐付ける方法には、例えば、以下の方法がある。
（１）消費者ＤＤ６２０のユーザが番号ごとに対象銘柄を指定する。
（２）商品情報管理サーバ６１０が、消費者ＤＤ６２０から番号ごとにアップロードされた画像を解析して対象銘柄を特定する。
（３）商品情報管理サーバ６１０が、消費者ＤＤ６２０からアップロードされた画像を解析して対象銘柄を特定し、左から順番に１番、２番・・・と紐付けていく。
（１）消費者ＤＤ６２０のユーザが番号ごとに対象銘柄を指定する。
（２）商品情報管理サーバ６１０が、消費者ＤＤ６２０から番号ごとにアップロードされた画像を解析して対象銘柄を特定する。
（３）商品情報管理サーバ６１０が、消費者ＤＤ６２０からアップロードされた画像を解析して対象銘柄を特定し、左から順番に１番、２番・・・と紐付けていく。
【0101】
図１３は、投稿評価テーブル１３００の例を示す。
投稿評価テーブル１３００は、消費者ＤＤ６２０から受信した銘柄に対する要素評価値を記憶する。当該テーブルは、投稿ＩＤ１３０１、銘柄番号１３０２、要素ＩＤ１３０３、要素評価１３０４等のフィールドを有する。
投稿評価テーブル１３００は、消費者ＤＤ６２０から受信した銘柄に対する要素評価値を記憶する。当該テーブルは、投稿ＩＤ１３０１、銘柄番号１３０２、要素ＩＤ１３０３、要素評価１３０４等のフィールドを有する。
【0102】
図１４は、ユーザ購入活動テーブル１４００の例を示す。
ユーザ購入活動テーブル１４００は、消費者ＤＤ６２０のユーザの、事業者に対する活動の履歴を記憶する。当該テーブルは、ユーザＩＤ１４０１、事業者ＩＤ１４０２、行動１４０３、行動場所１４０４、表示在庫１４０５、表示評価１４０６、表示距離１４０７、表示価格１４０８、表示ＣＯ２１４０９、表示場所１４１０等のフィールドを有する。なお、これらのフィールドの「表示」とは、飲める店、買える店または買えるＥＣ店として表示されたことを意味する。
ユーザ購入活動テーブル１４００は、消費者ＤＤ６２０のユーザの、事業者に対する活動の履歴を記憶する。当該テーブルは、ユーザＩＤ１４０１、事業者ＩＤ１４０２、行動１４０３、行動場所１４０４、表示在庫１４０５、表示評価１４０６、表示距離１４０７、表示価格１４０８、表示ＣＯ２１４０９、表示場所１４１０等のフィールドを有する。なお、これらのフィールドの「表示」とは、飲める店、買える店または買えるＥＣ店として表示されたことを意味する。
【0103】
図１５は、事業者販売テーブル１５００の例を示す。
事業者販売テーブル１５００は、事業者間の商品の販売の履歴を記憶する。当該テーブルは、事業者ＩＤ１５０１、カテゴリ１５０２、メーカ１５０３、商品ＩＤ１５０４、商品名１５０５、買い手１５０６、買い手タイプ１５０７、買い手電話番号１５０８、買い手住所１５０９、買い手事業者ＩＤ１５１０、本数１５１１、価格１５１２、注文日時１５１３、配達日時１５１４、登録日時１５１５等のフィールドを有する。これらのフィールドのうち、登録日時１５１５の値は、当該レコードが登録された日時を示す。
事業者販売テーブル１５００は、事業者間の商品の販売の履歴を記憶する。当該テーブルは、事業者ＩＤ１５０１、カテゴリ１５０２、メーカ１５０３、商品ＩＤ１５０４、商品名１５０５、買い手１５０６、買い手タイプ１５０７、買い手電話番号１５０８、買い手住所１５０９、買い手事業者ＩＤ１５１０、本数１５１１、価格１５１２、注文日時１５１３、配達日時１５１４、登録日時１５１５等のフィールドを有する。これらのフィールドのうち、登録日時１５１５の値は、当該レコードが登録された日時を示す。
【0104】
図１６は、事業者在庫テーブル１６００の例を示す。
事業者在庫テーブル１６００は、事業者の商品在庫を記憶する。当該テーブルは、事業者ＩＤ１６０１、カテゴリ１６０２、メーカ１６０３、商品ＩＤ１６０４、商品名１６０５、在庫１６０６等のフィールドを有する。
事業者在庫テーブル１６００は、事業者の商品在庫を記憶する。当該テーブルは、事業者ＩＤ１６０１、カテゴリ１６０２、メーカ１６０３、商品ＩＤ１６０４、商品名１６０５、在庫１６０６等のフィールドを有する。
【0105】
図１７は、銘柄特徴テーブル１７００の例を示す。
銘柄特徴テーブル１７００は、銘柄マスタテーブル２０００に格納された商品特性に関する情報と、投稿評価テーブル１３００の情報を解析して得た要素評価に関する情報とを記憶する。当該テーブルは、銘柄ＩＤ１７０１、タイプＡ１７０２、タイプＢ１７０３、要素ＩＤ１７０４、格納値１７０５、平均値１７０６、標準偏差１７０７、適用値１７０８等のフィールドを有する。これらのフィールドのうち、タイプＡ１７０２には、商品特性値が主観的な値であるか、それとも客観的な値であるかを示す値が格納される。タイプＢ１７０３には、商品特性値が定量値であるか、それとも定性値であるかを示す値が格納される。格納値１７０５には、商品特性ごとに予め設定される値が格納される。特に主観的定量値は、銘柄のメーカや取扱事業者により設定される。
銘柄特徴テーブル１７００は、銘柄マスタテーブル２０００に格納された商品特性に関する情報と、投稿評価テーブル１３００の情報を解析して得た要素評価に関する情報とを記憶する。当該テーブルは、銘柄ＩＤ１７０１、タイプＡ１７０２、タイプＢ１７０３、要素ＩＤ１７０４、格納値１７０５、平均値１７０６、標準偏差１７０７、適用値１７０８等のフィールドを有する。これらのフィールドのうち、タイプＡ１７０２には、商品特性値が主観的な値であるか、それとも客観的な値であるかを示す値が格納される。タイプＢ１７０３には、商品特性値が定量値であるか、それとも定性値であるかを示す値が格納される。格納値１７０５には、商品特性ごとに予め設定される値が格納される。特に主観的定量値は、銘柄のメーカや取扱事業者により設定される。
【0106】
適用値１７０８には、定性値については、ダミーデータ（１）に変換した値が格納され、客観的定量値については、格納値１７０５の値がそのまま格納される。一方、主観的定量値については、適用値１７０８には、格納値１７０５の値か、または格納値１７０５の値を平均値１７０６の値と標準偏差１７０７の値で補正した値が格納される。
【0107】
図１８は、嗜好モデルテーブル１８００の例を示す。
嗜好モデルテーブル１８００は、投稿銘柄テーブル１２００と銘柄特徴テーブル１７００の情報を重回帰分析して得た嗜好モデルを記憶する。当該テーブルは、ユーザＩＤ１８０１、カテゴリＩＤ１８０２、要素番号１８０３、要素ＩＤ１８０４、偏回帰係数１８０５、標準偏回帰係数１８０６、切片１８０７等のフィールドを有する。これらのフィールドのうち、標準偏回帰係数１８０６に格納される値は、商品特性がユーザの嗜好に与える影響度を表す値である。
嗜好モデルテーブル１８００は、投稿銘柄テーブル１２００と銘柄特徴テーブル１７００の情報を重回帰分析して得た嗜好モデルを記憶する。当該テーブルは、ユーザＩＤ１８０１、カテゴリＩＤ１８０２、要素番号１８０３、要素ＩＤ１８０４、偏回帰係数１８０５、標準偏回帰係数１８０６、切片１８０７等のフィールドを有する。これらのフィールドのうち、標準偏回帰係数１８０６に格納される値は、商品特性がユーザの嗜好に与える影響度を表す値である。
【0108】
図１９は、嗜好推定テーブル１９００の例を示す。
嗜好推定テーブル１９００は、嗜好モデルを用いて推定した各銘柄の総合評価値を記憶する。当該テーブルは、ユーザＩＤ１９０１、カテゴリＩＤ１９０２、銘柄ＩＤ１９０３、説明変数１９０４、目的変数１９０５の各フィールドを有する。これらのフィールドのうち、説明変数１９０４は、要素「１」１９０６、要素「２」１９０７、要素「３」１９０８等の複数のフィールドに分けられる。図１９に示す例では、これらのフィールドのうち、要素「１」には定性値（ダミー変数）が格納され、要素「２」１９０７には客観的定量値が格納され、要素「３」１９０８には主観的定量値が格納されている。
嗜好推定テーブル１９００は、嗜好モデルを用いて推定した各銘柄の総合評価値を記憶する。当該テーブルは、ユーザＩＤ１９０１、カテゴリＩＤ１９０２、銘柄ＩＤ１９０３、説明変数１９０４、目的変数１９０５の各フィールドを有する。これらのフィールドのうち、説明変数１９０４は、要素「１」１９０６、要素「２」１９０７、要素「３」１９０８等の複数のフィールドに分けられる。図１９に示す例では、これらのフィールドのうち、要素「１」には定性値（ダミー変数）が格納され、要素「２」１９０７には客観的定量値が格納され、要素「３」１９０８には主観的定量値が格納されている。
【0109】
目的変数１９０５は、実績値１９０９と推定値１９１０に分けられる。このうち、実績値１９０９には投稿銘柄テーブル１２００の総合評価値が格納され、推定値１９１０には嗜好モデルを用いて推定した総合評価値が格納される。
【0110】
図２０は、銘柄マスタテーブル２０００の例を示す。
銘柄マスタテーブル２０００は、酒類の銘柄に関する情報を記憶している。当該テーブルは、親ＩＤ２００１、銘柄ＩＤ２００２、名称２００３、カテゴリＩＤ２００４、エリアＩＤ２００５、メーカＩＤ２００６等のフィールドを有する。なお、図２０では、説明の便宜上、銘柄ＩＤ２００２に銘柄名称を充てているため、名称２００３の値の例示を省略している。
銘柄マスタテーブル２０００は、酒類の銘柄に関する情報を記憶している。当該テーブルは、親ＩＤ２００１、銘柄ＩＤ２００２、名称２００３、カテゴリＩＤ２００４、エリアＩＤ２００５、メーカＩＤ２００６等のフィールドを有する。なお、図２０では、説明の便宜上、銘柄ＩＤ２００２に銘柄名称を充てているため、名称２００３の値の例示を省略している。
【0111】
図２１は、商品マスタテーブル２１００の例を示す。
商品マスタテーブル２１００は、酒類の商品に関する情報を記憶している。当該テーブルは、銘柄ＩＤ２１０１、商品ＩＤ２１０２、名称２１０３、タイプ２１０４、容器２１０５、量２１０６等のフィールドを有する。なお、図２１では、説明の便宜上、商品ＩＤ２１０２に商品名称を充てているため、名称２１０３の値の例示を省略している。
商品マスタテーブル２１００は、酒類の商品に関する情報を記憶している。当該テーブルは、銘柄ＩＤ２１０１、商品ＩＤ２１０２、名称２１０３、タイプ２１０４、容器２１０５、量２１０６等のフィールドを有する。なお、図２１では、説明の便宜上、商品ＩＤ２１０２に商品名称を充てているため、名称２１０３の値の例示を省略している。
【0112】
図２２は、エリアマスタテーブル２２００の例を示す。
エリアマスタテーブル２２００は、行政区画の上下関係を記憶している。当該テーブルは、親ＩＤ２２０１、エリアＩＤ２２０２、名称２２０３等のフィールドを有する。なお、図２２では、説明の便宜上、エリアＩＤ２２０２にエリア名称を充てているため、名称２２０３の値の例示を省略している。
エリアマスタテーブル２２００は、行政区画の上下関係を記憶している。当該テーブルは、親ＩＤ２２０１、エリアＩＤ２２０２、名称２２０３等のフィールドを有する。なお、図２２では、説明の便宜上、エリアＩＤ２２０２にエリア名称を充てているため、名称２２０３の値の例示を省略している。
【0113】
図２３は、要素マスタテーブル２３００の例を示す。
要素マスタテーブル２３００は、商品の特性に関する情報を記憶している。当該テーブルは、親ＩＤ２３０１、要素ＩＤ２３０２、名称２３０３、タイプ２３０４等のフィールドを有する。なお、図２３では、説明の便宜上、要素ＩＤ２３０２に要素名称を充てているため、名称２３０３の値の例示を省略している。
要素マスタテーブル２３００は、商品の特性に関する情報を記憶している。当該テーブルは、親ＩＤ２３０１、要素ＩＤ２３０２、名称２３０３、タイプ２３０４等のフィールドを有する。なお、図２３では、説明の便宜上、要素ＩＤ２３０２に要素名称を充てているため、名称２３０３の値の例示を省略している。
【0114】
図２４は、メディアマスタテーブル２４００の例を示す。
メディアマスタテーブル２４００は、酒類に関するメディアの情報を記憶している。当該テーブルは、親ＩＤ２４０１、メディアＩＤ２４０２、名称２４０３、タイプ２４０４等のフィールドを有する。なお、図２４では、説明の便宜上、メディアＩＤ２４０２にメディア名称を充てているため、名称２４０３の値の例示を省略している。
メディアマスタテーブル２４００は、酒類に関するメディアの情報を記憶している。当該テーブルは、親ＩＤ２４０１、メディアＩＤ２４０２、名称２４０３、タイプ２４０４等のフィールドを有する。なお、図２４では、説明の便宜上、メディアＩＤ２４０２にメディア名称を充てているため、名称２４０３の値の例示を省略している。
【0115】
図２５は、事業者マスタテーブル２５００の例を示す。
事業者マスタテーブル２５００は、事業者に関する情報を記憶している。当該テーブルは、親ＩＤ２５０１、事業者ＩＤ２５０２、名称２５０３、タイプ２５０４、サブタイプ２５０５、ＥＣ有無２５０６、実店舗２５０７、配送機能２５０８、電話番号２５０９、住所２５１０、エリアＩＤ２５１１、評価２５１２、アクセスコード２５１３、ＥＣ ＵＲＬ２５１４、予約ＵＲＬ２５１５等のフィールドを有する。
事業者マスタテーブル２５００は、事業者に関する情報を記憶している。当該テーブルは、親ＩＤ２５０１、事業者ＩＤ２５０２、名称２５０３、タイプ２５０４、サブタイプ２５０５、ＥＣ有無２５０６、実店舗２５０７、配送機能２５０８、電話番号２５０９、住所２５１０、エリアＩＤ２５１１、評価２５１２、アクセスコード２５１３、ＥＣ ＵＲＬ２５１４、予約ＵＲＬ２５１５等のフィールドを有する。
【0116】
なお、図２５では、説明の便宜上、事業者ＩＤ２５０２に事業者名称を充てているため、名称２５０３の値の例示を省略している。
図２５に例示するＥＣ ＵＲＬと予約ＵＲＬの「$product_id」部分は、当該ＵＲＬの使用時に、個別商品ＩＤに置き換えられる。
予約ＵＲＬの「seat-reserve」は席予約用のＵＲＬであることを表し、「product-reserve」は商品取り置き用のＵＲＬであることを表す。
図２５に例示するＥＣ ＵＲＬと予約ＵＲＬの「$product_id」部分は、当該ＵＲＬの使用時に、個別商品ＩＤに置き換えられる。
予約ＵＲＬの「seat-reserve」は席予約用のＵＲＬであることを表し、「product-reserve」は商品取り置き用のＵＲＬであることを表す。
【0117】
図２６は、銘柄パーツ設定テーブル２６００の例を示す。
銘柄パーツ設定テーブル２６００は、銘柄パーツの設定情報（特に、事業者が自身のＤＡに組み込む銘柄パーツの設定情報）を記憶している。当該テーブルは、事業者ＩＤ２６０１、ドメイン２６０２、マップボタン２６０３、カートボタン２６０４、カートＵＲＬ２６０５等のフィールドを有する。これらのフィールドのうち、ドメイン２６０２の値は、銘柄パーツの設置ドメインを示す。マップボタン２６０３の値は、マップボタンの表示の要否を示す。カートボタン２６０４の値は、カートボタンの表示の要否を示す。カートＵＲＬ２６０５には、カートボタンの遷移先を１つに限定する場合に、そのＵＲＬが登録される。
銘柄パーツ設定テーブル２６００は、銘柄パーツの設定情報（特に、事業者が自身のＤＡに組み込む銘柄パーツの設定情報）を記憶している。当該テーブルは、事業者ＩＤ２６０１、ドメイン２６０２、マップボタン２６０３、カートボタン２６０４、カートＵＲＬ２６０５等のフィールドを有する。これらのフィールドのうち、ドメイン２６０２の値は、銘柄パーツの設置ドメインを示す。マップボタン２６０３の値は、マップボタンの表示の要否を示す。カートボタン２６０４の値は、カートボタンの表示の要否を示す。カートＵＲＬ２６０５には、カートボタンの遷移先を１つに限定する場合に、そのＵＲＬが登録される。
【0118】
図２７は、銘柄表記ゆれテーブル２７００の例を示す。
銘柄表記ゆれテーブル２７００は、銘柄ＩＤおよび商品ＩＤの表記ゆれを統一するためのテーブルである。当該テーブルは、入力名称２７０１、銘柄ＩＤ２７０２、商品ＩＤ２７０３等のフィールドを有する。なお、これらのフィールドのうち、商品ＩＤ２７０３は任意である。このフィールドは、特定銘柄の「買える店／ＥＣ」押下時に、商品別に取扱店舗を表示する必要があれば必要であり、商品別まで分割不要であれば不要である。
銘柄表記ゆれテーブル２７００は、銘柄ＩＤおよび商品ＩＤの表記ゆれを統一するためのテーブルである。当該テーブルは、入力名称２７０１、銘柄ＩＤ２７０２、商品ＩＤ２７０３等のフィールドを有する。なお、これらのフィールドのうち、商品ＩＤ２７０３は任意である。このフィールドは、特定銘柄の「買える店／ＥＣ」押下時に、商品別に取扱店舗を表示する必要があれば必要であり、商品別まで分割不要であれば不要である。
【0119】
図２８は、名称表記ゆれテーブル２８００の例を示す。
名称表記ゆれテーブル２８００は、酒類に関する用語の表記ゆれを統一するためのテーブルである。当該テーブルは、入力名称２８０１、対象２８０２、対象ＩＤ２８０３等のフィールドを有する。
名称表記ゆれテーブル２８００は、酒類に関する用語の表記ゆれを統一するためのテーブルである。当該テーブルは、入力名称２８０１、対象２８０２、対象ＩＤ２８０３等のフィールドを有する。
【0120】
図２９は、銘柄情報テーブル２９００の例を示す。
銘柄情報テーブル２９００は、事業者ごとに銘柄のイメージ、ＰＲコンテンツ、フェイスパターンに関する情報を記憶している。当該テーブルは、銘柄ＩＤ２９０１、事業者ＩＤ２９０２、タイプ２９０３、情報コンテンツ２９０４等のフィールドを有する。なお、情報コンテンツ２９０４には、図２９に示す「background」に代えて、「product_or_label」や「text」といった値が格納され得る。
銘柄情報テーブル２９００は、事業者ごとに銘柄のイメージ、ＰＲコンテンツ、フェイスパターンに関する情報を記憶している。当該テーブルは、銘柄ＩＤ２９０１、事業者ＩＤ２９０２、タイプ２９０３、情報コンテンツ２９０４等のフィールドを有する。なお、情報コンテンツ２９０４には、図２９に示す「background」に代えて、「product_or_label」や「text」といった値が格納され得る。
【0121】
図３０は、ユーザ購入嗜好テーブル３０００の例を示す。
ユーザ購入嗜好テーブル３０００は、消費者ＤＤ６２０のユーザの購入嗜好に関する情報を記憶している。当該テーブルは、ユーザＩＤ３００１、対象３００２、第１優先３００３、第２優先３００４、第３優先３００５、ＣＯ２許容範囲３００６、価格許容範囲３００７等のフィールドを有する。これらのフィールドのうち、優先度のフィールドに格納される値は、以下の通りである。
ユーザ購入嗜好テーブル３０００は、消費者ＤＤ６２０のユーザの購入嗜好に関する情報を記憶している。当該テーブルは、ユーザＩＤ３００１、対象３００２、第１優先３００３、第２優先３００４、第３優先３００５、ＣＯ２許容範囲３００６、価格許容範囲３００７等のフィールドを有する。これらのフィールドのうち、優先度のフィールドに格納される値は、以下の通りである。
【0122】
（１）在庫 対象銘柄の取得可能性が高い店舗を優先
（２）履歴 所定期間内に利用回数が多い店舗を優先
（３）評価 多くのユーザから評判が高い店舗ほど優先
（４）タイプ 所定期間内に利用回数が多い業態（居酒屋、焼肉、公式ショップなど）を優先
（５）価格 対象銘柄の販売価格が安い店舗を優先
（６）ＣＯ２ 購入後、配送時に排出されるＣＯ２（理論値）が少ないほど優先（基本はＥＣのみ）
（７）場所 現在地から近い店舗ほど優先（基本は実店舗のみ）
（２）履歴 所定期間内に利用回数が多い店舗を優先
（３）評価 多くのユーザから評判が高い店舗ほど優先
（４）タイプ 所定期間内に利用回数が多い業態（居酒屋、焼肉、公式ショップなど）を優先
（５）価格 対象銘柄の販売価格が安い店舗を優先
（６）ＣＯ２ 購入後、配送時に排出されるＣＯ２（理論値）が少ないほど優先（基本はＥＣのみ）
（７）場所 現在地から近い店舗ほど優先（基本は実店舗のみ）
【0123】
優先度の値は、ユーザ購入活動テーブル１４００の解析を通じて決定されてもよいし、設定画面でユーザにより明示的に設定されてもよい。
【0124】
図３１は、事業者商品テーブル３１００の例を示す。
事業者商品テーブル３１００は、事業者の取扱商品に関する情報を記憶している。当該テーブルは、事業者ＩＤ３１０１、カテゴリ３１０２、メーカ３１０３、商品ＩＤ３１０４、商品名３１０５、価格３１０６、商品名（フォーマット後）３１０７、銘柄ＩＤ３１０８、商品ＩＤ３１０９、在庫３１１０、在庫レベル３１１１、在庫推定精度３１１２、販売（予測値）３１１３、在庫（予測値）３１１４、ＥＣ ＵＲＬ３１１５、登録日時３１１６、更新日時３１１７等のフィールドを有する。
事業者商品テーブル３１００は、事業者の取扱商品に関する情報を記憶している。当該テーブルは、事業者ＩＤ３１０１、カテゴリ３１０２、メーカ３１０３、商品ＩＤ３１０４、商品名３１０５、価格３１０６、商品名（フォーマット後）３１０７、銘柄ＩＤ３１０８、商品ＩＤ３１０９、在庫３１１０、在庫レベル３１１１、在庫推定精度３１１２、販売（予測値）３１１３、在庫（予測値）３１１４、ＥＣ ＵＲＬ３１１５、登録日時３１１６、更新日時３１１７等のフィールドを有する。
【0125】
なお、これらのフィールドのうち、カテゴリ３１０２、メーカ３１０３、商品ＩＤ３１０４、商品名３１０５、価格３１０６には、事業者から受信した値が格納される。特に商品ＩＤ３１０４は、事業者独自の商品ＩＤである。
商品ＩＤ３１０９は任意である。このフィールドは、特定銘柄の「買える店／ＥＣ」押下時に、商品別に取扱店舗を表示する必要があれば必要であり、商品別まで分割不要であれば不要である。
商品ＩＤ３１０９は任意である。このフィールドは、特定銘柄の「買える店／ＥＣ」押下時に、商品別に取扱店舗を表示する必要があれば必要であり、商品別まで分割不要であれば不要である。
【0126】
銘柄ＩＤ３１０８と商品ＩＤ３１０９に格納される値は、商品情報管理サーバ６１０において付与されるユニバーサル（共通）ＩＤである。
ＥＣ ＵＲＬ３１１５の値は、事業者マスタテーブル２５００のＥＣ ＵＲＬ２５１４の値よりも優先して適用される。
登録日時３１１６の値は、当該レコードが登録された日時を示し、更新日時３１１７の値は、当該レコードが更新された日時を示す。
ＥＣ ＵＲＬ３１１５の値は、事業者マスタテーブル２５００のＥＣ ＵＲＬ２５１４の値よりも優先して適用される。
登録日時３１１６の値は、当該レコードが登録された日時を示し、更新日時３１１７の値は、当該レコードが更新された日時を示す。
【0127】
図３２は、事業者リワードプログラムテーブル３２００の例を示す。
事業者リワードプログラムテーブル３２００は、事業者等のリワードプログラムに関する情報を記憶している。なおここで、リワードプログラムとは、一定期間に頻繁にサービスを利用した優良顧客に対して事業者等が提供するインセンティブの仕組みのことである。顧客は獲得ポイントやランクごとに特典や報酬を得られる。
事業者リワードプログラムテーブル３２００は、事業者等のリワードプログラムに関する情報を記憶している。なおここで、リワードプログラムとは、一定期間に頻繁にサービスを利用した優良顧客に対して事業者等が提供するインセンティブの仕組みのことである。顧客は獲得ポイントやランクごとに特典や報酬を得られる。
【0128】
上記テーブルは、事業者ＩＤ３２０１、プログラムＩＤ３２０２、対象３２０３、対象ＩＤ３２０４、条件３２０５、リワード３２０６、ウェブサイト３２０７、名称３２０８、説明３２０９等のフィールドを有する。
【0129】
図３３は、事業者サブスクリプションプログラムテーブル３３００の例を示す。
事業者サブスクリプションプログラムテーブル３３００は、事業者が提供するサブスクリプションプログラムに関する情報を記憶している。当該テーブルは、事業者ＩＤ３３０１、プログラムＩＤ３３０２、予算３３０３、タイトル３３０４、説明３３０５等のフィールドを有する。
事業者サブスクリプションプログラムテーブル３３００は、事業者が提供するサブスクリプションプログラムに関する情報を記憶している。当該テーブルは、事業者ＩＤ３３０１、プログラムＩＤ３３０２、予算３３０３、タイトル３３０４、説明３３０５等のフィールドを有する。
【0130】
図３４は、配送コストテーブル３４００の例を示す。
配送コストテーブル３４００は、事業者の商品配送に関する情報を記憶している。当該テーブルは、事業者ＩＤ３４０１、エリアＩＤ３４０２、最終受付時間３４０３、出荷日数３４０４、到着までの日時３４０５、配送コスト３４０６、配送時ＣＯ２３４０７（理論値）、保管日数３４０８、保管時排出ＣＯ２３４０９、税率３４１０等のフィールドを有する。
このテーブルの値は各事業者により登録される。
配送コストテーブル３４００は、事業者の商品配送に関する情報を記憶している。当該テーブルは、事業者ＩＤ３４０１、エリアＩＤ３４０２、最終受付時間３４０３、出荷日数３４０４、到着までの日時３４０５、配送コスト３４０６、配送時ＣＯ２３４０７（理論値）、保管日数３４０８、保管時排出ＣＯ２３４０９、税率３４１０等のフィールドを有する。
このテーブルの値は各事業者により登録される。
【0131】
図３５は、銘柄・要素関係テーブル３５００の例を示す。
銘柄・要素関係テーブル３５００は、各銘柄について商品特性を記憶している。当該テーブルは、銘柄ＩＤ３５０１、要素ＩＤ３５０２、要素タイプ３５０３、値３５０４等のフィールドを有する。
銘柄・要素関係テーブル３５００は、各銘柄について商品特性を記憶している。当該テーブルは、銘柄ＩＤ３５０１、要素ＩＤ３５０２、要素タイプ３５０３、値３５０４等のフィールドを有する。
【0132】
図３６は、銘柄・メディア関係テーブル３６００の例を示す。
銘柄・メディア関係テーブル３６００は、各銘柄についてメディア情報を記憶している。当該テーブルは、銘柄ＩＤ３６０１、メディアＩＤ３６０２、メディアタイプ３６０３、セクション３６０４、タイトル３６０５等のフィールドを有する。
銘柄・メディア関係テーブル３６００は、各銘柄についてメディア情報を記憶している。当該テーブルは、銘柄ＩＤ３６０１、メディアＩＤ３６０２、メディアタイプ３６０３、セクション３６０４、タイトル３６０５等のフィールドを有する。
【0133】
図３７は、ユーザ・銘柄関係テーブル３７００の例を示す。
ユーザ・銘柄関係テーブル３７００は、消費者ＤＤ６２０の各ユーザについて銘柄の嗜好に関する情報を記憶している。当該テーブルは、ユーザＩＤ３７０１、銘柄ＩＤ３７０２、ラベル３７０３、トリガ３７０４、根拠３７０５、登録起点事業者３７０６、登録起点情報３７０７、購入本数３７０８、購入金額３７０９、登録日時３７１０等のフィールドを有する。これらのフィールドのうち、登録日時３７１０の値は、当該レコードが登録された日時を示す。
ユーザ・銘柄関係テーブル３７００は、消費者ＤＤ６２０の各ユーザについて銘柄の嗜好に関する情報を記憶している。当該テーブルは、ユーザＩＤ３７０１、銘柄ＩＤ３７０２、ラベル３７０３、トリガ３７０４、根拠３７０５、登録起点事業者３７０６、登録起点情報３７０７、購入本数３７０８、購入金額３７０９、登録日時３７１０等のフィールドを有する。これらのフィールドのうち、登録日時３７１０の値は、当該レコードが登録された日時を示す。
【0134】
図３８は、ユーザ・事業者関係テーブル３８００の例を示す。
ユーザ・事業者関係テーブル３８００は、消費者ＤＤ６２０の各ユーザについてリワードの交換に関する情報を記憶している。当該テーブルは、ユーザＩＤ３８０１、ユーザキー３８０２、事業者ＩＤ３８０３、プログラムＩＤ３８０４、投稿回数（交換済み）３８０５、購入本数（交換済み）３８０６、購入金額（交換済み）３８０７、投稿回数（未交換）３８０８、購入本数（未交換）３８０９、購入金額（未交換）３８１０、合計投稿回数３８１１、合計購入本数３８１２、合計購入金額３８１３、交換日時３８１４、登録日時３８１５、更新日時３８１６等のフィールドを有する。
ユーザ・事業者関係テーブル３８００は、消費者ＤＤ６２０の各ユーザについてリワードの交換に関する情報を記憶している。当該テーブルは、ユーザＩＤ３８０１、ユーザキー３８０２、事業者ＩＤ３８０３、プログラムＩＤ３８０４、投稿回数（交換済み）３８０５、購入本数（交換済み）３８０６、購入金額（交換済み）３８０７、投稿回数（未交換）３８０８、購入本数（未交換）３８０９、購入金額（未交換）３８１０、合計投稿回数３８１１、合計購入本数３８１２、合計購入金額３８１３、交換日時３８１４、登録日時３８１５、更新日時３８１６等のフィールドを有する。
【0135】
これらのフィールドのうち、ユーザキー３８０２の値は、事業者が管理するユーザキーである。
これらのフィールドの「交換」とは、購入実績とリワードとの交換を意味する。
登録日時３８１５の値は、当該レコードが登録された日時を示し、更新日時３８１６の値は、実績値の計算日時を示す。
これらのフィールドの「交換」とは、購入実績とリワードとの交換を意味する。
登録日時３８１５の値は、当該レコードが登録された日時を示し、更新日時３８１６の値は、実績値の計算日時を示す。
【0136】
なお、以上説明した図１１～図３８に示すテーブルでは、説明を分かりやすくするためにＩＤのフィールドに名称が格納されている。しかし、実際には当該フィールドには英数字のコードが格納され、英数字のコードに紐づく名称は別途管理される。
【0137】
１－６．実施例の動作
１－６－１．ユーザ認証処理
図３９は、ユーザ認証処理３９００の例を示す。同図に示す処理は一定期間で１度のみ実行される。
本処理において消費者ＤＤ６２０のユーザは認証リクエストを行う（ステップ３９０１）。具体的には当該ユーザは、例えば、ログインボタンを押下する。この操作を受けて消費者ＤＤ６２０の認証モジュール８１１は、認証フォームを出力する（ステップ３９０２）。ユーザは、この認証フォームに対し、Ｅメールアドレスやパスワード等の認証情報を入力する（ステップ３９０３）。
１－６－１．ユーザ認証処理
図３９は、ユーザ認証処理３９００の例を示す。同図に示す処理は一定期間で１度のみ実行される。
本処理において消費者ＤＤ６２０のユーザは認証リクエストを行う（ステップ３９０１）。具体的には当該ユーザは、例えば、ログインボタンを押下する。この操作を受けて消費者ＤＤ６２０の認証モジュール８１１は、認証フォームを出力する（ステップ３９０２）。ユーザは、この認証フォームに対し、Ｅメールアドレスやパスワード等の認証情報を入力する（ステップ３９０３）。
【0138】
入力された認証情報は認証サーバに送信され、認証サーバにおいて認証が行われる（ステップ３９０４）。この認証に失敗すると、ユーザは認証情報を入力し直す。一方、この認証に成功すると、認証モジュール８１１は、以降の一定期間はセッションＣＤ（code）を入手可能な状態となる（ステップ３９０５）。
以上がユーザ認証処理３９００についての説明である。
以上がユーザ認証処理３９００についての説明である。
【0139】
１－６－２．ユーザＩＤ取得処理
図４０は、ユーザＩＤ取得処理４０００の例を示す。同図に示す処理はユーザ認証後、必要に応じて実行される。
本処理において消費者ＤＤ６２０のユーザは何らかの要求または入力を行う（ステップ４００１）。この操作を受けて消費者ＤＤ６２０は、要求／入力を、セッションＣＤを添えて商品情報管理サーバ６１０に送信する（ステップ４００２）。
図４０は、ユーザＩＤ取得処理４０００の例を示す。同図に示す処理はユーザ認証後、必要に応じて実行される。
本処理において消費者ＤＤ６２０のユーザは何らかの要求または入力を行う（ステップ４００１）。この操作を受けて消費者ＤＤ６２０は、要求／入力を、セッションＣＤを添えて商品情報管理サーバ６１０に送信する（ステップ４００２）。
【0140】
この要求／入力を受信した商品情報管理サーバ６１０の認証モジュール７１１は、認証サーバにセッションＣＤを送信してユーザＩＤを要求する（ステップ４００３）。認証サーバはセッションＣＤの検証を行い（ステップ４００４）、セッションＣＤが有効であれば、対応するユーザＩＤを商品情報管理サーバ６１０に送信する。商品情報管理サーバ６１０は、このユーザＩＤを取得することで、当該ユーザの属性情報を取得可能になる（ステップ４００５）。ユーザＩＤを取得後、商品情報管理サーバ６１０は、上記の要求／入力に応じた処理を実行する（ステップ４００６）。
以上がユーザＩＤ取得処理４０００についての説明である。
以上がユーザＩＤ取得処理４０００についての説明である。
【0141】
１－６－３．事業者認証処理
図４１は、事業者認証処理４１００の例を示す。同図に示す処理は一定期間で１度のみ実行される。
本処理において事業者ＤＤ６３０を使用する事業者は認証リクエストを行う（ステップ４１０１）。具体的には当該事業者は、例えば、ログインボタンを押下する。この操作を受けて事業者ＤＤ６３０の認証モジュール９１１は、認証フォームを出力する（ステップ４１０２）。事業者は、この認証フォームに対し、Ｅメールアドレスやパスワード等の認証情報を入力する（ステップ４１０３）。
図４１は、事業者認証処理４１００の例を示す。同図に示す処理は一定期間で１度のみ実行される。
本処理において事業者ＤＤ６３０を使用する事業者は認証リクエストを行う（ステップ４１０１）。具体的には当該事業者は、例えば、ログインボタンを押下する。この操作を受けて事業者ＤＤ６３０の認証モジュール９１１は、認証フォームを出力する（ステップ４１０２）。事業者は、この認証フォームに対し、Ｅメールアドレスやパスワード等の認証情報を入力する（ステップ４１０３）。
【0142】
入力された認証情報は認証サーバに送信され、認証サーバにおいて認証が行われる（ステップ４１０４）。この認証に失敗すると、事業者は認証情報を入力し直す。一方、この認証に成功すると、認証モジュール９１１は、以降の一定期間はセッションＣＤを入手可能な状態となる（ステップ４１０５）。
以上が事業者認証処理４１００についての説明である。
以上が事業者認証処理４１００についての説明である。
【0143】
１－６－４．事業者ＩＤ取得処理
図４２は、事業者ＩＤ取得処理４２００の例を示す。同図に示す処理は事業者認証後、必要に応じて実行される。
本処理において事業者ＤＤ６３０を使用する事業者は何らかの要求または入力を行う（ステップ４２０１）。この操作を受けて事業者ＤＤ６３０は、要求／入力を、セッションＣＤを添えて商品情報管理サーバ６１０に送信する（ステップ４２０２）。
図４２は、事業者ＩＤ取得処理４２００の例を示す。同図に示す処理は事業者認証後、必要に応じて実行される。
本処理において事業者ＤＤ６３０を使用する事業者は何らかの要求または入力を行う（ステップ４２０１）。この操作を受けて事業者ＤＤ６３０は、要求／入力を、セッションＣＤを添えて商品情報管理サーバ６１０に送信する（ステップ４２０２）。
【0144】
この要求／入力を受信した商品情報管理サーバ６１０の認証モジュール７１１は、認証サーバにセッションＣＤを送信して事業者ＩＤを要求する（ステップ４２０３）。認証サーバはセッションＣＤの検証を行い（ステップ４２０４）、セッションＣＤが有効であれば、対応する事業者ＩＤを商品情報管理サーバ６１０に送信する。商品情報管理サーバ６１０は、この事業者ＩＤを取得することで、当該事業者の属性情報を取得可能になる（ステップ４２０５）。事業者ＩＤを取得後、商品情報管理サーバ６１０は、上記の要求／入力に応じた処理を実行する（ステップ４２０６）。
以上が事業者ＩＤ取得処理４２００についての説明である。
以上が事業者ＩＤ取得処理４２００についての説明である。
【0145】
１－６－５．事業者の商品／販売／在庫データ連携処理
図４３は、事業者の商品／販売／在庫データ連携処理４３００の例を示す。同図に示す処理は日次など一定の頻度で定期的に実行される。
本処理は、事業者サーバ６４０と商品情報管理サーバ６１０間で、アクセスキーで一意性を担保したセッションが確立されていることを前提としている。
本処理において事業者サーバ６４０は商品、販売または在庫データを抽出して商品情報管理サーバ６１０に送信する（ステップ４３０１）。その際、事業者サーバ６４０は、販売データを送信する場合は、前回送信以降に蓄積された販売データを送信する。
図４３は、事業者の商品／販売／在庫データ連携処理４３００の例を示す。同図に示す処理は日次など一定の頻度で定期的に実行される。
本処理は、事業者サーバ６４０と商品情報管理サーバ６１０間で、アクセスキーで一意性を担保したセッションが確立されていることを前提としている。
本処理において事業者サーバ６４０は商品、販売または在庫データを抽出して商品情報管理サーバ６１０に送信する（ステップ４３０１）。その際、事業者サーバ６４０は、販売データを送信する場合は、前回送信以降に蓄積された販売データを送信する。
【0146】
商品情報管理サーバ６１０のデータ連携モジュール７１２は、販売データを受信すると、当該データを事業者ＩＤと対応付けて事業者販売テーブル１５００に格納する（ステップ４３０２）。
データ連携モジュール７１２は、在庫データを受信すると、当該データを事業者ＩＤと対応付けて事業者在庫テーブル１６００に格納する（ステップ４３０３）。
データ連携モジュール７１２は、在庫データを受信すると、当該データを事業者ＩＤと対応付けて事業者在庫テーブル１６００に格納する（ステップ４３０３）。
【0147】
データ連携モジュール７１２は、商品データを受信すると、当該データを事業者ＩＤと対応付けて事業者商品テーブル３１００（具体的には、事業者ＩＤ３１０１、カテゴリ３１０２、メーカ３１０３、商品ＩＤ３１０４、商品名３１０５、登録日時３２１６）に格納する（ステップ４３０４）。
なお、販売データに基づいて商品データを格納する場合には、当該モジュールは販売データを商品粒度に集約の上、格納する。
なお、販売データに基づいて商品データを格納する場合には、当該モジュールは販売データを商品粒度に集約の上、格納する。
【0148】
商品データを格納後、当該モジュールは、事業者商品テーブル３１００からユニバーサルマスタと未突合のレコードを抽出する（ステップ４３０５）。レコード抽出後、当該モジュールは、商品名から不要な記号を除き、表記ゆれを整え、単語の並び順も整える（ステップ４３０６）。そして当該モジュールは、整形後の商品名を事業者商品テーブル３１００（具体的には、商品名（フォーマット後）３１０７）に格納する。
【0149】
格納後、当該モジュールは、整形後の商品名と商品マスタテーブル２１００を突合する（ステップ４３０７）。そして当該モジュールは、当該テーブルにおいて整形後の商品名と対応付けられている銘柄ＩＤと商品ＩＤを、事業者商品テーブル３１００（具体的には、銘柄ＩＤ３２０８、商品ＩＤ３２０９）に格納する。
なお、機械処理でマッチしなかった商品名については人的処理で突合する。
なお、機械処理でマッチしなかった商品名については人的処理で突合する。
【0150】
人的処理でもマッチしない商品名については、当該モジュールは、新規商品、銘柄登録を行う（ステップ４３０８）。具体的には当該モジュールは、銘柄ＩＤを新たに生成して、生成したＩＤと銘柄名を対応付けて銘柄マスタテーブル２０００に格納する。また当該モジュールは、商品ＩＤを新たに生成して、生成したＩＤと整形後の商品名を対応付けて商品マスタテーブル２１００に格納する。さらに当該モジュールは、生成した銘柄ＩＤおよび商品ＩＤを事業者商品テーブル３１００（具体的には、銘柄ＩＤ３２０８、商品ＩＤ３２０９）に格納する。
以上が商品／販売／在庫データ連携処理４３００についての説明である。
以上が商品／販売／在庫データ連携処理４３００についての説明である。
【0151】
１－６－６．パーツ組み込み処理（事業者独自の商品ＩＤに基づく）
図４４は、銘柄パーツまたは付加価値パーツを組み込むためのパーツ組込処理４４００の例を示す。同図に示す処理では、事業者独自の商品ＩＤに基づき各パーツを組み込む。
本処理は、事業者認証処理４１００が完了していることを前提としている。
本処理において事業者ＤＤ６３０を使用する事業者は商品情報管理サーバ６１０にアクセスする（ステップ４４０１）。このアクセスに伴い、事業者ＩＤ取得処理４２００が実行されて、商品情報管理サーバ６１０の組込タグ管理モジュール７１３は事業者ＩＤを取得する（ステップ４４０２）。
図４４は、銘柄パーツまたは付加価値パーツを組み込むためのパーツ組込処理４４００の例を示す。同図に示す処理では、事業者独自の商品ＩＤに基づき各パーツを組み込む。
本処理は、事業者認証処理４１００が完了していることを前提としている。
本処理において事業者ＤＤ６３０を使用する事業者は商品情報管理サーバ６１０にアクセスする（ステップ４４０１）。このアクセスに伴い、事業者ＩＤ取得処理４２００が実行されて、商品情報管理サーバ６１０の組込タグ管理モジュール７１３は事業者ＩＤを取得する（ステップ４４０２）。
【0152】
また、上記のアクセスに伴い、事業者ＤＤ６３０の組込タグ設定モジュール９１２は、銘柄パーツ組み込み用のタグを表示する（ステップ４４０３）。事業者は、表示されたタグを事業者ＤＡ６２２内に設置する（ステップ４４０４）。以下にタグの例を示す。
（１）商品／販売／在庫データを連携している場合
（１－１）銘柄カード用
<iframe src="https://nomi-log.jp/bcard/?player_cd=xxx&prod_cd=xxx"></iframe>
（１－２）銘柄ページ用
<iframe src="https://nomi-log.jp/bpage/?player_cd=xxx&prod_cd=xxx"></iframe>
（１）商品／販売／在庫データを連携している場合
（１－１）銘柄カード用
<iframe src="https://nomi-log.jp/bcard/?player_cd=xxx&prod_cd=xxx"></iframe>
（１－２）銘柄ページ用
<iframe src="https://nomi-log.jp/bpage/?player_cd=xxx&prod_cd=xxx"></iframe>
【0153】
なお、これらのタグが事業者ＤＤ６３０で表示される時点で、player_cdには当該事業者のコード（言い換えると、ＩＤ）が埋められている。
prod_cd=xxxのxxx部分に、埋め込みたい対象の事業者独自の商品コード（言い換えると、商品ＩＤ）を埋めて、事業者ＤＡ６２２の任意のページに埋め込む。
prod_cd=xxxのxxx部分に、埋め込みたい対象の事業者独自の商品コード（言い換えると、商品ＩＤ）を埋めて、事業者ＤＡ６２２の任意のページに埋め込む。
【0154】
（２）商品／販売／在庫データを連携していない場合
（２－１）銘柄カード用
<iframe src="https://nomi-log.jp/bcard/?player_cd=xxx&brand_cd=xxx"></iframe>
（２－２）銘柄ページ用
<iframe src="https://nomi-log.jp/bpage/?player_cd=xxx&brand_cd=xxx"></iframe>
（２－１）銘柄カード用
<iframe src="https://nomi-log.jp/bcard/?player_cd=xxx&brand_cd=xxx"></iframe>
（２－２）銘柄ページ用
<iframe src="https://nomi-log.jp/bpage/?player_cd=xxx&brand_cd=xxx"></iframe>
【0155】
なお、これらのタグが事業者ＤＤ６３０で表示される時点で、player_cdには当該事業者のコード（言い換えると、ＩＤ）が埋められている。
brand_cd=xxxののxxx部分に、埋め込みたい対象の銘柄の銘柄コード（言い換えると、銘柄ＩＤ）を所定のフォームで検索して、そのコードを埋めて、事業者ＤＡ６２２の任意のページに埋め込む。
brand_cd=xxxののxxx部分に、埋め込みたい対象の銘柄の銘柄コード（言い換えると、銘柄ＩＤ）を所定のフォームで検索して、そのコードを埋めて、事業者ＤＡ６２２の任意のページに埋め込む。
【0156】
銘柄パーツ組み込み用のタグに加えて、付加価値パーツ（具体的には例えば、接客パーツ）を組み込む場合は、事業者ＤＤ６３０の組込タグ設定モジュール９１２は、付加価値パーツ組み込み用のタグを表示する（ステップ４４０５）。事業者は、表示されたタグを事業者ＤＡ６２２内に設置する（ステップ４４０６）。以下にタグの例を示す。
<iframe src="https://nomi-log.jp/chat/?player_cd=xxx"></iframe>
<iframe src="https://nomi-log.jp/chat/?player_cd=xxx"></iframe>
【0157】
なお、このタグは、商品／販売／在庫データを連携していないと、埋め込むことができない。
このタグが事業者ＤＤ６３０で表示される時点で、player_cdには当該事業者のコード（言い換えると、ＩＤ）が埋められている。
prod_cd=xxxのxxx部分に、埋め込みたい対象の事業者独自の商品コード（言い換えると、商品ＩＤ）を埋めて、事業者ＤＡ６２２の任意のページに埋め込む。
このタグが事業者ＤＤ６３０で表示される時点で、player_cdには当該事業者のコード（言い換えると、ＩＤ）が埋められている。
prod_cd=xxxのxxx部分に、埋め込みたい対象の事業者独自の商品コード（言い換えると、商品ＩＤ）を埋めて、事業者ＤＡ６２２の任意のページに埋め込む。
【0158】
事業者ＩＤの取得後、商品情報管理サーバ６１０の組込タグ管理モジュール７１３は、組込タグ設定内容を取得し（ステップ４４０７）、事業者ＤＤ６３０の組込タグ設定モジュール９１２に銘柄パーツ設定フォームを表示させる（ステップ４４０８）。表示されるフォームは、マップボタンの表示要否、カートボタンの表示要否、カートボタンの遷移先を設定するためのフォームである。事業者は、このフォームに設定内容を入力する（ステップ４４０９）。
【0159】
組込タグ設定モジュール９１２は、入力された設定内容を含む更新依頼を商品情報管理サーバ６１０に送信する（ステップ４４１０）。この送信に伴い、事業者ＩＤ取得処理４２００が実行されて、商品情報管理サーバ６１０の組込タグ管理モジュール７１３は事業者ＩＤを取得する（ステップ４４１１）。事業者ＩＤを取得後、当該モジュールは、送信された設定内容に基づいて銘柄パーツ設定テーブル２６００を更新する（ステップ４４１２）。この更新後、事業者ＤＤ６３０の組込タグ設定モジュール９１２は更新結果を表示する（ステップ４４１３）。
以上がパーツ組込処理４４００についての説明である。
以上がパーツ組込処理４４００についての説明である。
【0160】
１－６－７．パーツ組み込み処理（ユニバーサル銘柄ＩＤに基づく）
図４５は、銘柄パーツを組み込むためのパーツ組込処理４５００の例を示す。同図に示す処理では、図４４に示すパーツ組込処理４４００とは異なり、事業者独自の商品ＩＤに代えてユニバーサル銘柄ＩＤに基づき銘柄パーツを組み込む。
本処理は、事業者認証処理４１００が完了していることを前提としている。
本処理において事業者ＤＤ６３０を使用する事業者は商品情報管理サーバ６１０にアクセスする（ステップ４５０１）。このアクセスに伴い、事業者ＩＤ取得処理４２００が実行されて、商品情報管理サーバ６１０の組込タグ管理モジュール７１３は事業者ＩＤを取得する（ステップ４５０２）。
図４５は、銘柄パーツを組み込むためのパーツ組込処理４５００の例を示す。同図に示す処理では、図４４に示すパーツ組込処理４４００とは異なり、事業者独自の商品ＩＤに代えてユニバーサル銘柄ＩＤに基づき銘柄パーツを組み込む。
本処理は、事業者認証処理４１００が完了していることを前提としている。
本処理において事業者ＤＤ６３０を使用する事業者は商品情報管理サーバ６１０にアクセスする（ステップ４５０１）。このアクセスに伴い、事業者ＩＤ取得処理４２００が実行されて、商品情報管理サーバ６１０の組込タグ管理モジュール７１３は事業者ＩＤを取得する（ステップ４５０２）。
【0161】
また、上記のアクセスに伴い、事業者ＤＤ６３０の組込タグ設定モジュール９１２は、銘柄パーツを組み込むタグの生成フォームを表示する（ステップ４５０３）。事業者は、このフォームに対象銘柄名の全部または一部を入力する（ステップ４５０４）。組込タグ設定モジュール９１２は、当該フォームにおける変更を都度、商品情報管理サーバ６１０に送信する（ステップ４５０５）。
【0162】
商品情報管理サーバ６１０の組込タグ管理モジュール７１３は、銘柄表記ゆれテーブル２７００と銘柄マスタテーブル２０００を参照して、入力値に部分一致する銘柄群を特定し、当該銘柄名称群を返却する（ステップ４５０６）。事業者ＤＤ６３０の組込タグ設定モジュール９１２は、受領した銘柄名を一覧で補完表示する（ステップ４５０７）。事業者、この一覧から対象銘柄を選択する（ステップ４５０８）。組込タグ設定モジュール９１２は、選択または入力された銘柄名を商品情報管理サーバ６１０に送信する（ステップ４５０９）。
【0163】
商品情報管理サーバ６１０の組込タグ管理モジュール７１３は、銘柄表記ゆれテーブル２７００と銘柄マスタテーブル２０００を参照して、受領した銘柄名に対応する銘柄ＩＤを特定し、返却する（ステップ４５１０）。この返却を受けて、事業者ＤＤ６３０の組込タグ設定モジュール９１２は、当該銘柄の銘柄パーツを組み込むタグを表示する（ステップ４５１１）。事業者は、表示されたタグを事業者ＤＡ６２２内に設置する（ステップ４５１２）。以下にタグの例を示す。
【0164】
（１）銘柄カード用
<iframe src="https://nomi-log.jp/bcard/?player_cd=xxx&brand_cd=xxx"></iframe>
（２）銘柄ページ用
<iframe src="https://nomi-log.jp/bpage/?player_cd=xxx&brand_cd=xxx"></iframe>
なお、これらのタグが事業者ＤＤ６３０で表示される時点で、player_cdには当該事業者のコード（言い換えると、ＩＤ）が埋められており、brand_cd=xxxののxxx部分には銘柄コード（言い換えると、銘柄ＩＤ）が埋められている。
<iframe src="https://nomi-log.jp/bcard/?player_cd=xxx&brand_cd=xxx"></iframe>
（２）銘柄ページ用
<iframe src="https://nomi-log.jp/bpage/?player_cd=xxx&brand_cd=xxx"></iframe>
なお、これらのタグが事業者ＤＤ６３０で表示される時点で、player_cdには当該事業者のコード（言い換えると、ＩＤ）が埋められており、brand_cd=xxxののxxx部分には銘柄コード（言い換えると、銘柄ＩＤ）が埋められている。
【0165】
事業者ＩＤの取得後、商品情報管理サーバ６１０の組込タグ管理モジュール７１３は、組込タグ設定内容を取得し（ステップ４５１３）、事業者ＤＤ６３０の組込タグ設定モジュール９１２に銘柄パーツ設定フォームを表示させる（ステップ４５１４）。表示されるフォームは、マップボタンの表示要否、カートボタンの表示要否、カートボタンの遷移先を設定するためのフォームである。事業者は、このフォームに設定内容を入力する（ステップ４５１５）。
【0166】
組込タグ設定モジュール９１２は、入力された設定内容を含む更新依頼を商品情報管理サーバ６１０に送信する（ステップ４５１６）。この送信に伴い、事業者ＩＤ取得処理４２００が実行されて、商品情報管理サーバ６１０の組込タグ管理モジュール７１３は事業者ＩＤを取得する（ステップ４５１７）。事業者ＩＤを取得後、当該モジュールは、送信された設定内容に基づいて銘柄パーツ設定テーブル２６００を更新する（ステップ４５１８）。この更新後、事業者ＤＤ６３０の組込タグ設定モジュール９１２は更新結果を表示する（ステップ４５１９）。
以上がパーツ組込処理４５００についての説明である。
以上がパーツ組込処理４５００についての説明である。
【0167】
なお、上記の処理のステップ４５０４において、事業者は、対象銘柄を特定するための情報として、銘柄名に代えてＪＡＮコード、ＥＡＮコードまたは商品画像を入力してもよい。
【0168】
１－６－８．銘柄訴求情報の登録処理
図４６は、造り手が銘柄訴求情報を登録するための登録処理４６００の例を示す。
本処理は、事業者認証処理４１００が完了していることを前提としている。
本処理において事業者ＤＤ６３０の情報登録モジュール９１３は登録フォームを出力する（ステップ４６０１）。造り手は、このフォームに登録内容または変更内容を入力する（ステップ４６０２）。情報登録モジュール９１３は、入力情報を商品情報管理サーバ６１０に送信する（ステップ４６０３）。
図４６は、造り手が銘柄訴求情報を登録するための登録処理４６００の例を示す。
本処理は、事業者認証処理４１００が完了していることを前提としている。
本処理において事業者ＤＤ６３０の情報登録モジュール９１３は登録フォームを出力する（ステップ４６０１）。造り手は、このフォームに登録内容または変更内容を入力する（ステップ４６０２）。情報登録モジュール９１３は、入力情報を商品情報管理サーバ６１０に送信する（ステップ４６０３）。
【0169】
この送信に伴い、事業者ＩＤ取得処理４２００が実行されて、商品情報管理サーバ６１０の登録情報管理モジュール７１４は事業者ＩＤを取得する（ステップ４６０４）。事業者ＩＤを取得後、当該モジュールは、受領した入力情報に基づいてＤＢを更新する（ステップ４６０５）。更新後、事業者ＤＤ６３０の情報登録モジュール９１３は更新結果を表示する（ステップ４６０６）。なお、入力情報と更新先のテーブルの関係は以下のとおりである。
【0170】
（１）基本情報（メーカ、カテゴリ、エリアなど）
銘柄マスタテーブル２０００
（２）属性情報（特徴、製法、原材料など）
銘柄・要素関係テーブル３５００
要素マスタテーブル２３００（対象属性が未登録の場合）
（３）イメージ（画像、動画、ＶＲ空間など）
銘柄情報テーブル２９００
銘柄マスタテーブル２０００
（２）属性情報（特徴、製法、原材料など）
銘柄・要素関係テーブル３５００
要素マスタテーブル２３００（対象属性が未登録の場合）
（３）イメージ（画像、動画、ＶＲ空間など）
銘柄情報テーブル２９００
【0171】
（４）ＰＲコンテンツ
銘柄情報テーブル２９００
（５）コンテスト受賞履歴、メディア露出履歴
銘柄・メディア関係テーブル３６００
メディアマスタテーブル２４００（対象メディアが未登録の場合）
（６）飲める店／買える店マップ
事業者商品テーブル３１００または、後述する事業者・銘柄関係テーブル７７００
事業者マスタテーブル２５００（対象事業者が未登録の場合）
銘柄情報テーブル２９００
（５）コンテスト受賞履歴、メディア露出履歴
銘柄・メディア関係テーブル３６００
メディアマスタテーブル２４００（対象メディアが未登録の場合）
（６）飲める店／買える店マップ
事業者商品テーブル３１００または、後述する事業者・銘柄関係テーブル７７００
事業者マスタテーブル２５００（対象事業者が未登録の場合）
【0172】
（７）買えるＥＣ店リスト
事業者商品テーブル３１００
事業者マスタテーブル２５００（対象事業者が未登録の場合）
（８）銘柄パーツのフェイスパターン
銘柄情報テーブル２９００
以上が登録処理４６００についての説明である。
事業者商品テーブル３１００
事業者マスタテーブル２５００（対象事業者が未登録の場合）
（８）銘柄パーツのフェイスパターン
銘柄情報テーブル２９００
以上が登録処理４６００についての説明である。
【0173】
１－６－９．取扱銘柄の登録処理
図４７は、売り手が取扱銘柄を直接登録するための登録処理４７００の例を示す。
本処理は、事業者認証処理４１００が完了していることを前提としている。
また本処理では、最初にパーツ組込処理４５００のステップ４５０１～４５０９が実行される。
図４７は、売り手が取扱銘柄を直接登録するための登録処理４７００の例を示す。
本処理は、事業者認証処理４１００が完了していることを前提としている。
また本処理では、最初にパーツ組込処理４５００のステップ４５０１～４５０９が実行される。
【0174】
その後、商品情報管理サーバ６１０の登録情報管理モジュール７１４は、銘柄表記ゆれテーブル２７００と銘柄マスタテーブル２０００を参照して、事業者ＤＤ６３０から受領した銘柄名に相当する銘柄ＩＤを特定する（ステップ４７０１）。また当該モジュールは、事業者ＩＤ取得処理４２００を通じて事業者ＩＤを取得する（ステップ４７０２）。事業者ＩＤを取得後、当該モジュールは、特定した銘柄ＩＤを当該事業者の取扱銘柄として事業者商品テーブル３１００に登録する（ステップ４７０３）。
以上が登録処理４７００についての説明である。
以上が登録処理４７００についての説明である。
【0175】
１－６－１０．取扱情報登録のための売り手の商品／販売／在庫データの連携処理
このデータ連携処理は、商品／販売／在庫データ連携処理４３００と同じである。
このデータ連携処理は、商品／販売／在庫データ連携処理４３００と同じである。
【0176】
１－６－１１．売り手の仕入先の販売データ連携処理
図４８は、売り手の仕入先の販売データ連携処理４８００の例を示す。
本処理では、最初に商品／販売／在庫データ連携処理４３００のステップ４３０１および４３０２が実行される。
図４８は、売り手の仕入先の販売データ連携処理４８００の例を示す。
本処理では、最初に商品／販売／在庫データ連携処理４３００のステップ４３０１および４３０２が実行される。
【0177】
その後、商品情報管理サーバ６１０のデータ連携モジュール７１２は、販売データにおける販売先（買い手）を事業者に登録する（ステップ４８０１）。具体的には当該モジュールは、販売先を事業者マスタテーブル２５００（具体的には、事業者ＩＤ２５０２、名称２５０３、タイプ２５０４、電話番号２５０９、住所２５１０）に登録し、その販売先の事業者ＩＤを事業者販売テーブル１５００（具体的には、買い手事業者ＩＤ１５１０）に登録する。その際、当該モジュールは差分（未登録分のみ）登録し、名寄せによって、冗長レコードを極力排除する。
【0178】
次に当該モジュールは、上記の販売先事業者ＩＤと対応付けて商品データを事業者商品テーブル３１００（具体的には、事業者ＩＤ３１０１、カテゴリ３１０２、メーカ３１０３、商品ＩＤ３１０４、商品名３１０５、登録日時３２１６）に格納する（ステップ４８０２）。
その後、商品／販売／在庫データ連携処理４３００のステップ４３０４～４３０６が実行される。
以上が販売データ連携処理４８００についての説明である。
その後、商品／販売／在庫データ連携処理４３００のステップ４３０４～４３０６が実行される。
以上が販売データ連携処理４８００についての説明である。
【0179】
１－６－１２．連携事業者の在庫情報更新処理
以下のいずれかの方法で、事業者商品テーブル３１００の在庫数、在庫レベル、在庫推定精度を更新する。
（１）対象事業者の在庫データを連携（データ連携処理４３００）
事業者の追加対応は不要。処理内容は、事業者商品テーブル３１００の在庫数を常時反映させる。在庫推定精度は１００％。
（２）対象事業者の仕入元の販売データを連携（データ連携処理４８００）
事業者の追加対応は不要。処理内容は、仕入元の事業者販売テーブル１５００が更新される都度、過去の推移を踏まえて在庫レベルを推定する。在庫推定精度は低から高（過去推移次第）。
以下のいずれかの方法で、事業者商品テーブル３１００の在庫数、在庫レベル、在庫推定精度を更新する。
（１）対象事業者の在庫データを連携（データ連携処理４３００）
事業者の追加対応は不要。処理内容は、事業者商品テーブル３１００の在庫数を常時反映させる。在庫推定精度は１００％。
（２）対象事業者の仕入元の販売データを連携（データ連携処理４８００）
事業者の追加対応は不要。処理内容は、仕入元の事業者販売テーブル１５００が更新される都度、過去の推移を踏まえて在庫レベルを推定する。在庫推定精度は低から高（過去推移次第）。
【0180】
（３）対象事業者の販売データを連携（データ連携処理４３００）
事業者の追加対応は、在庫補充の度、管理画面から在庫数を更新する。処理内容は、事業者販売テーブル１５００が更新される都度、当該商品の在庫数を減少させる。在庫推定精度は低から中（更新実績次第）。
（４）対象事業者が直接入力
事業者の追加対応は、在庫変動の度、管理画面から在庫数を更新する。処理内容は特になし。在庫推定精度は低から中（更新実績次第）。
事業者の追加対応は、在庫補充の度、管理画面から在庫数を更新する。処理内容は、事業者販売テーブル１５００が更新される都度、当該商品の在庫数を減少させる。在庫推定精度は低から中（更新実績次第）。
（４）対象事業者が直接入力
事業者の追加対応は、在庫変動の度、管理画面から在庫数を更新する。処理内容は特になし。在庫推定精度は低から中（更新実績次第）。
【0181】
１－６－１３．「飲みたい」登録処理
図４９は、消費者ＤＤ６２０のユーザが飲みたい銘柄を登録するための登録処理４９００の例を示す。
本処理は、ユーザ認証処理３９００が完了していることを前提としている。仮に当該処理が完了していない場合には、後述するステップ４９０４の時点で当該処理に遷移する。
図４９は、消費者ＤＤ６２０のユーザが飲みたい銘柄を登録するための登録処理４９００の例を示す。
本処理は、ユーザ認証処理３９００が完了していることを前提としている。仮に当該処理が完了していない場合には、後述するステップ４９０４の時点で当該処理に遷移する。
【0182】
本処理においてユーザが任意のページにアクセスすると（ステップ４９０１）、消費者ＤＤ６２０の表示モジュール８２１は当該ページを表示する（ステップ４９０２）。表示されるページは、銘柄パーツが組み込まれたページであり、当該ページの表示に伴い、銘柄パーツの読込処理（銘柄パーツ表示処理５２００のステップ５２０３～５２１１）が実行される（ステップ４９０３）。この銘柄パーツの読み込み処理については後述する。
【0183】
ページの表示後、ユーザは銘柄パーツのタグボタン（図６５の符号６５０７参照）を押下する（ステップ４９０４）。この操作を受けて、消費者ＤＤ６２０の意向／履歴登録モジュール８１２は登録リクエストを商品情報管理サーバ６１０に送信する（ステップ４９０５）。送信されるリクエストには、セッションＣＤとユニバーサル銘柄ＩＤが添付されている。このリクエストの送信に伴い、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０の意向／履歴管理モジュール７１５はユーザＩＤを取得する（ステップ４９０６）。
【0184】
ユーザＩＤを取得後、当該モジュールは、ユーザの「飲みたい」という意向をユーザ・銘柄関係テーブル３７００（具体的には、ユーザＩＤ３７０１、銘柄ＩＤ３７０２、ラベル３７０３）に登録する。登録後、消費者ＤＤ６２０の意向／履歴登録モジュール８１２は登録完了を通知する（ステップ４９０８）。図７１は、登録完了通知画面７１００の一例を示す。
以上が登録処理４９００についての説明である。
以上が登録処理４９００についての説明である。
【0185】
１－６－１４．「飲んだ」、「お気に入り」登録処理
図５０は、消費者ＤＤ６２０のユーザが飲んだ銘柄またはお気に入りの銘柄を登録するための登録処理５０００の例を示す。
本処理は、ユーザ認証処理３９００が完了していることを前提としている。仮に当該処理が完了していない場合には、後述するステップ５００１の時点で当該処理に遷移する。
図５０は、消費者ＤＤ６２０のユーザが飲んだ銘柄またはお気に入りの銘柄を登録するための登録処理５０００の例を示す。
本処理は、ユーザ認証処理３９００が完了していることを前提としている。仮に当該処理が完了していない場合には、後述するステップ５００１の時点で当該処理に遷移する。
【0186】
本処理においてユーザが投稿・評価画面にアクセスすると（ステップ５００１）、消費者ＤＤ６２０の意向／履歴登録モジュール８１２は投稿・評価フォームを表示する（ステップ５００２）。ユーザは、このフォームに投稿または評価を入力する（ステップ５００３）。意向／履歴登録モジュール８１２は、入力された投稿／評価の登録リクエストを、セッションＣＤと銘柄特定情報を添付して商品情報管理サーバ６１０に送信する（ステップ５００４）。この送信に伴い、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０の意向／履歴管理モジュール７１５はユーザＩＤを取得する（ステップ５００５）。
【0187】
ユーザＩＤを取得後、当該モジュールは、受領した銘柄特定情報から対象銘柄ＩＤを特定する（ステップ５００６）。銘柄ＩＤを特定後、当該モジュールは、受領した投稿／評価を投稿テーブル１１００、投稿銘柄テーブル１２００、投稿評価テーブル１３００に登録する（ステップ５００７）。登録後、当該モジュールは、ユーザの履歴をユーザ・銘柄関係テーブル３７００（具体的には、ユーザＩＤ３７０１、銘柄ＩＤ３７０２、ラベル３７０３、根拠３７０５）に登録する（ステップ５００８）。その際、当該モジュールは、ユーザの評価が一定水準以上であれば、「飲んだ」に加えて「お気に入り」としても登録する。
【0188】
登録後、消費者ＤＤ６２０の意向／履歴登録モジュール８１２は登録完了を通知する（ステップ５００９）。
以上が登録処理５０００についての説明である。
以上が登録処理５０００についての説明である。
【0189】
なお、上記の登録処理５０００において、ユーザがプレファレンス（飲用意向、飲用履歴、評価履歴など）を登録する際に対象銘柄を指定する手段は様々である。例えば、以下の手段がある。
（１）既にユニバーサル銘柄ＩＤを保有しているアプリ（銘柄パーツなど）上でボタンを押下するなどのアクションを介して、ユーザがユニバーサル銘柄ＩＤをサーバに渡す。
（２）対象銘柄名のテキスト入力／音声入力を介して、ユーザが入力された値をサーバに渡す。
（３）対象銘柄（商品そのものや商品について記載された雑誌など）を撮影した画像をユーザがサーバに渡す。
（１）既にユニバーサル銘柄ＩＤを保有しているアプリ（銘柄パーツなど）上でボタンを押下するなどのアクションを介して、ユーザがユニバーサル銘柄ＩＤをサーバに渡す。
（２）対象銘柄名のテキスト入力／音声入力を介して、ユーザが入力された値をサーバに渡す。
（３）対象銘柄（商品そのものや商品について記載された雑誌など）を撮影した画像をユーザがサーバに渡す。
【0190】
１－６－１５．「買った」登録処理
図５１は、消費者ＤＤ６２０のユーザが買った銘柄を登録するための登録処理５１００の例を示す。
本処理は、商品データの連携が完了していることを前提としている。また本処理は、ユーザ認証処理３９００が完了していることを前提としている。
図５１は、消費者ＤＤ６２０のユーザが買った銘柄を登録するための登録処理５１００の例を示す。
本処理は、商品データの連携が完了していることを前提としている。また本処理は、ユーザ認証処理３９００が完了していることを前提としている。
【0191】
本処理においてユーザがアクセス操作をすると（ステップ５１０１）、消費者ＤＤ６２０の表示モジュール８２１はＥＣ画面を表示する（ステップ５１０２）。ユーザは、このＥＣ画面上で購入手続きを行う（ステップ５１０３）。この操作を受けて、表示モジュール８２１は、事業者サーバ６４０に決済処理リクエストを送信する（ステップ５１０４）。事業者サーバ６４０は、この決済処理リクエストを処理し（ステップ５１０５）、その結果、表示モジュール８２１は決済完了を通知する（ステップ５１０６）。
【0192】
当該通知後、当該モジュールは、購入通知リクエストを意向／履歴登録モジュール８１２に渡す（ステップ５１０７）。このリクエストには、事業者ＩＤと個別商品ＩＤが添付されている。このリクエストを受けて、意向／履歴登録モジュール８１２は、購入通知を商品情報管理サーバ６１０に送信する（ステップ５１０８）。送信される通知には、セッションＣＤ、事業者ＩＤおよび個別商品ＩＤが添付されている。この通知の送信に伴い、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０の意向／履歴管理モジュール７１５はユーザＩＤを取得する（ステップ５１０９）。
【0193】
ユーザＩＤを取得後、当該モジュールは、事業者商品テーブル３１００を参照して、受領した個別商品ＩＤから銘柄ＩＤを特定する（ステップ５１１０）。銘柄ＩＤを特定後、当該モジュールは、ユーザの履歴をユーザ・銘柄関係テーブル３７００（具体的には、ユーザＩＤ３７０１、銘柄ＩＤ３７０２、ラベル３７０３、トリガ３７０４、根拠３７０５、購入本数３７０８、購入金額３７０９）に登録する（ステップ５１１１）。
【0194】
登録後、消費者ＤＤ６２０の意向／履歴登録モジュール８１２は登録完了を通知する（ステップ５１１２）。
以上が登録処理５１００についての説明である。
以上が登録処理５１００についての説明である。
【0195】
１－６－１６．銘柄パーツ表示処理
図５２は、銘柄パーツ表示処理５２００の例を示す。
本処理においてユーザが任意のページにアクセスすると（ステップ５２０１）、消費者ＤＤ６２０の表示モジュール８２１は当該ページを表示する（ステップ５２０２）。表示されるページは、銘柄パーツが組み込まれたページである。当該モジュールは、銘柄パーツリクエストを銘柄パーツ表示モジュール８１３に渡す。このリクエストには、個別商品ＩＤまたはユニバーサル銘柄ＩＤとパーツタイプ情報が添付されている。ここでパーツタイプ情報は、銘柄カードか銘柄ページのいずれかを示す。
図５２は、銘柄パーツ表示処理５２００の例を示す。
本処理においてユーザが任意のページにアクセスすると（ステップ５２０１）、消費者ＤＤ６２０の表示モジュール８２１は当該ページを表示する（ステップ５２０２）。表示されるページは、銘柄パーツが組み込まれたページである。当該モジュールは、銘柄パーツリクエストを銘柄パーツ表示モジュール８１３に渡す。このリクエストには、個別商品ＩＤまたはユニバーサル銘柄ＩＤとパーツタイプ情報が添付されている。ここでパーツタイプ情報は、銘柄カードか銘柄ページのいずれかを示す。
【0196】
上記のリクエストを受けて、銘柄パーツ表示モジュール８１３は、銘柄パーツリクエストを商品情報管理サーバ６１０に送信する（ステップ５２０４）。このリクエストには、事業者ＩＤと個別商品ＩＤまたはユニバーサル銘柄ＩＤが添付されている。
【0197】
商品情報管理サーバ６１０の銘柄パーツ情報提供モジュール７１６は、個別商品ＩＤを受領した場合は、事業者商品テーブル３１００を参照して、対象銘柄ＩＤを特定する（ステップ５２０５）。そして当該モジュールは、対象銘柄に対する銘柄パーツの必要情報を抽出する（ステップ５２０６）。この際に参照されるテーブルと抽出される情報は以下の通りである。
【0198】
（１）銘柄マスタテーブル２０００
基本情報（メーカ、カテゴリ、エリアなど）
（２）銘柄・要素関係テーブル３５００
属性情報（特徴、製法、原材料など）
基本情報（メーカ、カテゴリ、エリアなど）
（２）銘柄・要素関係テーブル３５００
属性情報（特徴、製法、原材料など）
【0199】
（３）銘柄情報テーブル２９００
イメージ（画像、動画、ＶＲ空間など）
ＰＲコンテンツ
銘柄パーツのフェイスパターン
（４）銘柄・メディア関係テーブル３６００
コンテスト受賞履歴、メディア露出履歴
イメージ（画像、動画、ＶＲ空間など）
ＰＲコンテンツ
銘柄パーツのフェイスパターン
（４）銘柄・メディア関係テーブル３６００
コンテスト受賞履歴、メディア露出履歴
【0200】
また当該モジュールは、銘柄パーツ設定テーブル２６００を参照して、対象事業者の銘柄パーツ出力条件を抽出する（ステップ５２０７）。
【0201】
消費者ＤＤ６２０の銘柄パーツ表示モジュール８１３は、上記のパーツタイプ情報に応じた出力処理を行う（ステップ５２０８）。具体的には当該モジュールは、パーツタイプ情報が「card」を示す場合には銘柄カードを出力し、パーツタイプ情報が「page」を示す場合には銘柄ページを出力する。
【0202】
また当該モジュールは、フェイスパターンに応じた出力処理を行う（ステップ５２０９）。具体的には当該モジュールは、フェイスパターンが「background」であれば、背景画像または動画パターンを採用し、フェイスパターンが「product_or_label」であれば、商品／ラベル画像パターンを採用し、フェイスパターンが「text」であれば、テキストのみパターンを採用する。
【0203】
また当該モジュールは、ボタン設定に応じて出力処理を行う（ステップ５２１０）。具体的には当該モジュールは、ボタン設定に応じて、マップボタンの表示要否、カートボタンの表示要否、カートボタンの遷移先の限定の要否について判断する。
【0204】
上記のステップ５２０８～５２１０を経て、当該モジュールは、銘柄パーツを表示する（ステップ５２１１）。
以上が銘柄パーツ表示処理５２００についての説明である。
以上が銘柄パーツ表示処理５２００についての説明である。
【0205】
なお、上記の処理において、銘柄関連情報から表示レイアウトに変換する処理は、消費者ＤＤ６２０側で行う形でも商品情報管理サーバ６１０側で行う形でも、どちらでもよい。
【0206】
図６５は、銘柄パーツの一例として、銘柄カード６５００を示す。
銘柄カード６５００は、ＷＥＢであれば、ページ内の一部として表示される表示要素である。当該カードは、最小限の領域内で表示され、ボタンを押下された際に表示領域が拡大する。
この銘柄カード６５００は、銘柄の基本情報を通知する。具体的には当該カードは、銘柄についての画像６５０１、名称６５０２、カテゴリ６５０３、（生産）エリア６５０４およびメーカ６５０５を通知する。
銘柄カード６５００は、ＷＥＢであれば、ページ内の一部として表示される表示要素である。当該カードは、最小限の領域内で表示され、ボタンを押下された際に表示領域が拡大する。
この銘柄カード６５００は、銘柄の基本情報を通知する。具体的には当該カードは、銘柄についての画像６５０１、名称６５０２、カテゴリ６５０３、（生産）エリア６５０４およびメーカ６５０５を通知する。
【0207】
また、この銘柄カード６５００は、情報ボタン６５０６、タグボタン６５０７、マップボタン６５０８およびカートボタン６５０９を有する。
これらのボタンのうち、情報ボタン６５０６は、後述する銘柄紹介領域（図６６の符号６６０２参照）を表示するためのボタンである。
タグボタン６５０７は、対象銘柄を「飲みたい」登録するためのボタンである。
マップボタン６５０８は、対象銘柄を飲める又は買える店を表示するためのボタンである。
カートボタン６５０９は、対象銘柄を買えるＥＣ店を表示するためのボタンである。
これらのボタンのうち、情報ボタン６５０６は、後述する銘柄紹介領域（図６６の符号６６０２参照）を表示するためのボタンである。
タグボタン６５０７は、対象銘柄を「飲みたい」登録するためのボタンである。
マップボタン６５０８は、対象銘柄を飲める又は買える店を表示するためのボタンである。
カートボタン６５０９は、対象銘柄を買えるＥＣ店を表示するためのボタンである。
【0208】
図６６は、銘柄パーツの別の例として、銘柄ページ６６００を示す。
銘柄ページ６６００は、銘柄カード６５００と異なり、最初から最大限の領域で表示される表示要素である。当該ページは、ＷＥＢサイトであれば、ポップアップ形式やページ遷移先で表示される。
銘柄ページ６６００は、銘柄カード６５００と異なり、最初から最大限の領域で表示される表示要素である。当該ページは、ＷＥＢサイトであれば、ポップアップ形式やページ遷移先で表示される。
【0209】
この銘柄ページ６６００は、フェイス領域６６０１と銘柄紹介領域６６０２を有する。このうちフェイス領域６６０１は、銘柄の基本情報を通知する。具体的には当該領域は、銘柄についての画像６６０３、名称６６０４、カテゴリ６６０５、（生産）エリア６６０６およびメーカ６６０７を通知する。
また当該領域は、タグボタン６６０８、マップボタン６６０９およびカートボタン６６１０を有する。これらのボタンの機能は、上述した銘柄カード６５００の同名のボタンと同じである。
また当該領域は、タグボタン６６０８、マップボタン６６０９およびカートボタン６６１０を有する。これらのボタンの機能は、上述した銘柄カード６５００の同名のボタンと同じである。
【0210】
一方、銘柄紹介領域６６０２は、商品情報タブ６６１１、造り手の銘柄紹介タブ６６１２、お知らせタブ６６１３、飲み手の口コミタブ６６１４および受賞履歴タブ６６１５を有する。これらのタブのうち任意のタブを選択することで、所望の情報を閲覧することができる。
【0211】
図６７は、事業者ＤＡ６２２に銘柄カードが組み込まれた場合に表示される画面６７００の例を示す。同図に示す画面６７００には、３つの銘柄カード６７０１～６７０３が組み込まれている。
【0212】
図６８は、事業者ＤＡ６２２に銘柄ページが組み込まれた場合に表示される画面６８００の例を示す。同図に示す画面６８００において特定銘柄６８０１がクリックされると、当該銘柄の銘柄ページ６８０２がポップアップ形式で表示される。
【0213】
図６９は、フェイス領域の表示オプションの例を示す。同図に示す表示オプションは、銘柄カード、銘柄ページ共通である。
図６９（ａ）は、基本情報のみを通知するフェイス領域６９０１を示す。ここで言う基本情報とは、商品の名称６９０２、カテゴリ６９０３、（生産）エリア６９０４およびメーカ６９０５である。
図６９（ａ）は、基本情報のみを通知するフェイス領域６９０１を示す。ここで言う基本情報とは、商品の名称６９０２、カテゴリ６９０３、（生産）エリア６９０４およびメーカ６９０５である。
【0214】
図６９（ｂ）は、商品のラベル画像付きのフェイス領域６９０６を示す。同図に示すフェイス領域６９０６は、基本情報に加えて、商品のラベル画像６９０７を通知する。
図６９（ｃ）は、任意の静止画または動画を背景とするフェイス領域６９０８を示す。同図に示すフェイス領域６９０８は、任意の静止画または動画６９０９を背景として基本情報を通知する。
図６９（ｃ）は、任意の静止画または動画を背景とするフェイス領域６９０８を示す。同図に示すフェイス領域６９０８は、任意の静止画または動画６９０９を背景として基本情報を通知する。
【0215】
図７０は、銘柄紹介領域の表示オプションの例を示す。
図７０（ａ）は、造り手または売り手のＤＡにより出力される銘柄紹介領域７００１の例を示す。同図に示す銘柄紹介領域７００１は特に、造り手の銘柄紹介タブ７００２を有している。
図７０（ａ）は、造り手または売り手のＤＡにより出力される銘柄紹介領域７００１の例を示す。同図に示す銘柄紹介領域７００１は特に、造り手の銘柄紹介タブ７００２を有している。
【0216】
図７０（ｂ）は、売り手のＤＡにより出力される銘柄紹介領域７００３の例を示す。同図に示す銘柄紹介領域７００３は、造り手の銘柄紹介タブ７００４を有している。加えて当該領域には、売り手による簡単な銘柄紹介７００５が記載されている。この銘柄紹介は、売り手により独自に登録されたものである。
【0217】
図７０（ｃ）は、売り手のＤＡにより出力される銘柄紹介領域７００６の例を示す。同図に示す銘柄紹介領域７００６は、造り手の銘柄紹介タブ７００７を有している。加えて当該領域は、売り手の銘柄紹介タブ７００８を有している。このタブは、売り手により独自に詳細な銘柄紹介が登録された結果、表示される。
【0218】
なお、図７０に示すフェイス領域には、造り手が自由に画像、３６０度画像、動画を複数埋め込み可能である。
また銘柄紹介領域のコンテンツは、造り手が自由に作成可能である。造り手は画像と文章を埋めるだけでもよいし、ＨＴＭＬコードを指定してもよい。また、銘柄紹介領域の「飲み手の口コミ」および「受賞履歴」部分については、造り手が表示要否を設定可能である。
また銘柄紹介領域のコンテンツは、造り手が自由に作成可能である。造り手は画像と文章を埋めるだけでもよいし、ＨＴＭＬコードを指定してもよい。また、銘柄紹介領域の「飲み手の口コミ」および「受賞履歴」部分については、造り手が表示要否を設定可能である。
【0219】
１－６－１７．マップ表示処理
図５３は、銘柄パーツのマップボタン押下時に実行されるマップ表示処理５３００の例を示す。
本処理を実行するにあたって、ユーザ認証処理３９００が完了しているか否かは任意である。
本処理において消費者ＤＤ６２０のユーザがマップボタン（図６５の符号６５０８参照）を押下すると（ステップ５３０１）、消費者ＤＤ６２０のマップ表示モジュール８１４は、商品情報管理サーバ６１０にリクエストを送信する（ステップ５３０２）。このリクエストには、事業者ＩＤ、ユニバーサル銘柄ＩＤ、アクセス位置、セッションＣＤが添付されている。
図５３は、銘柄パーツのマップボタン押下時に実行されるマップ表示処理５３００の例を示す。
本処理を実行するにあたって、ユーザ認証処理３９００が完了しているか否かは任意である。
本処理において消費者ＤＤ６２０のユーザがマップボタン（図６５の符号６５０８参照）を押下すると（ステップ５３０１）、消費者ＤＤ６２０のマップ表示モジュール８１４は、商品情報管理サーバ６１０にリクエストを送信する（ステップ５３０２）。このリクエストには、事業者ＩＤ、ユニバーサル銘柄ＩＤ、アクセス位置、セッションＣＤが添付されている。
【0220】
このリクエストにセッションＣＤが添付されている場合、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０のマップ情報提供モジュール７１７はユーザＩＤを取得する（ステップ５３０３）。ユーザＩＤを取得後、当該モジュールは、対象銘柄を飲める店、買える店を抽出する（ステップ５３０４）。
【0221】
具体的には当該モジュールは、事業者商品テーブル３１００を参照して、受領したユニバーサル銘柄ＩＤと対応付けられている事業者ＩＤを抽出する。そして当該モジュールは、事業者マスタテーブル２５００をさらに参照して、抽出した事業者ＩＤのうち、住所が、受領したアクセス位置から一定範囲内にあり、かつ、タイプが「飲食店」である事業者ＩＤを、飲める店として抽出する。また当該モジュールは、同テーブルを参照して、事業者商品テーブル３１００から抽出した事業者ＩＤのうち、住所が、受領したアクセス位置から一定範囲内にあり、かつ、タイプが「小売店」である事業者ＩＤを、買える店として抽出する。
【0222】
飲める店および買える店を抽出後、当該モジュールは、対象ユーザが特定できる場合には、飲める店、買える店のそれぞれについて、ユーザの嗜好または条件で並び替えおよび／または絞り込みを行う（ステップ５３０５）。その際、当該モジュールは、ユーザ購入嗜好テーブル３０００（対象３００２＝実店舗）を参照する。以下に並べ替えと絞り込みの例を示す。
【0223】
（１）入手可能性（在庫状況）を優先する場合
当該モジュールは、事業者商品テーブル３１００を参照して、対象の事業者ＩＤおよび銘柄ＩＤに対応する在庫数に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（２）利用した店舗を優先する場合
当該モジュールは、ユーザ・事業者関係テーブル３８００を参照して、利用履歴に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（３）よく利用する業態を優先する場合
当該モジュールは、事業者マスタテーブル２５００とユーザ・事業者関係テーブル３８００を参照して、タイプに基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
当該モジュールは、事業者商品テーブル３１００を参照して、対象の事業者ＩＤおよび銘柄ＩＤに対応する在庫数に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（２）利用した店舗を優先する場合
当該モジュールは、ユーザ・事業者関係テーブル３８００を参照して、利用履歴に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（３）よく利用する業態を優先する場合
当該モジュールは、事業者マスタテーブル２５００とユーザ・事業者関係テーブル３８００を参照して、タイプに基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
【0224】
（４）店舗の評判を優先する場合
当該モジュールは、事業者マスタテーブル２５００を参照して、評価に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（５）店舗の所在地（近さ）を優先する場合
当該モジュールは、事業者マスタテーブル２５００を参照して、住所とアクセス位置の距離に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（６）価格を優先する場合
当該モジュールは、事業者商品テーブル３１００を参照して、対象の事業者ＩＤおよび銘柄ＩＤに対応する価格に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
当該モジュールは、事業者マスタテーブル２５００を参照して、評価に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（５）店舗の所在地（近さ）を優先する場合
当該モジュールは、事業者マスタテーブル２５００を参照して、住所とアクセス位置の距離に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（６）価格を優先する場合
当該モジュールは、事業者商品テーブル３１００を参照して、対象の事業者ＩＤおよび銘柄ＩＤに対応する価格に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
【0225】
店舗の並び替えおよび／または絞り込み後、消費者ＤＤ６２０のマップ表示モジュール８１４は、店舗群をマップにプロットし、かつ、マップ下部にリスト化して表示する（ステップ５３０６）。その際、リストの表示内容は、データの登録状況に応じて決まる。例えば、在庫数の表示の有無は、事業者商品テーブル３１００における在庫数の登録の有無に応じて決まり、予約ボタンの表示の有無は、事業者マスタテーブル２５００における予約ＵＲＬの登録の有無に応じて決まる。
【0226】
図７２は、マップ等を有する銘柄カード７２００の例を示す。
銘柄カード７２００は、フェイス領域７２０１、マップ７２０２、飲める店リスト７２０３および買える店リスト７２０４を有する。
このうち、マップ７２０２は、ユーザの現在位置から近い場所で、対象銘柄を飲める飲食店および対象銘柄を買える小売店を示す。
銘柄カード７２００は、フェイス領域７２０１、マップ７２０２、飲める店リスト７２０３および買える店リスト７２０４を有する。
このうち、マップ７２０２は、ユーザの現在位置から近い場所で、対象銘柄を飲める飲食店および対象銘柄を買える小売店を示す。
【0227】
飲める店リスト７２０３は、ユーザの現在位置から近い場所で、対象銘柄を飲める飲食店のリストである。当該リストは、各店舗について、名称７２０５、在庫レベル７２０６、住所７２０７、電話番号７２０８および予約ボタン７２０９を示す。
買える店リスト７２０４は、ユーザの現在位置から近い場所で、対象銘柄を買える小売店のリストである。当該リストは、各店舗について、名称７２０５、在庫レベル７２０６、住所７２０７、電話番号７２０８および予約ボタン７２０９を示す。
買える店リスト７２０４は、ユーザの現在位置から近い場所で、対象銘柄を買える小売店のリストである。当該リストは、各店舗について、名称７２０５、在庫レベル７２０６、住所７２０７、電話番号７２０８および予約ボタン７２０９を示す。
【0228】
マップ表示処理５３００の説明に戻る。
ユーザが上記のマップまたはリストに表示された特定店舗をクリックまたは訪問すると（ステップ５３０７）、マップ表示モジュール８１４は、リクエストを商品情報管理サーバ６１０に送信する（ステップ５３０８）。このリクエストには、事業者ＩＤ、ユニバーサル銘柄ＩＤ、セッションＣＤ、クリック対象事業者ＩＤ、活動履歴情報が添付されている。
ユーザが上記のマップまたはリストに表示された特定店舗をクリックまたは訪問すると（ステップ５３０７）、マップ表示モジュール８１４は、リクエストを商品情報管理サーバ６１０に送信する（ステップ５３０８）。このリクエストには、事業者ＩＤ、ユニバーサル銘柄ＩＤ、セッションＣＤ、クリック対象事業者ＩＤ、活動履歴情報が添付されている。
【0229】
このリクエストにセッションＣＤが添付されている場合、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０のマップ情報提供モジュール７１７はユーザＩＤを取得する（ステップ５３０９）。ユーザＩＤを取得後、当該モジュールは、ユーザ購入活動テーブル１４００に、受領した活動履歴を登録する（ステップ５３１０）。
【0230】
登録され、蓄積された活動履歴は、ユーザの嗜好または条件を推定する際に参照される（ステップ５３１１）。この推定処理は、ユーザ購入活動テーブル１４００を解析することで行われ、ユーザが重視する上位３つのファクターが抽出されてユーザ購入嗜好テーブル３０００に登録される。またこの推定処理は、週次、月次などの一定頻度で実行される。
以上がマップ表示処理５３００についての説明である。
以上がマップ表示処理５３００についての説明である。
【0231】
１－６－１８．ＥＣリスト表示処理
図５４は、銘柄パーツのカートボタン押下時に実行されるＥＣリスト表示処理５４００の例を示す。
本処理を実行するにあたって、ユーザ認証処理３９００が完了しているか否かは任意である。
本処理において消費者ＤＤ６２０のユーザがカートボタン（図６５の参照符号６５０９参照）を押下すると（ステップ５４０１）、消費者ＤＤ６２０のＥＣリスト表示モジュール８１５は、遷移先が１つに限定されているか否かを判定する（ステップ５４０２）。
図５４は、銘柄パーツのカートボタン押下時に実行されるＥＣリスト表示処理５４００の例を示す。
本処理を実行するにあたって、ユーザ認証処理３９００が完了しているか否かは任意である。
本処理において消費者ＤＤ６２０のユーザがカートボタン（図６５の参照符号６５０９参照）を押下すると（ステップ５４０１）、消費者ＤＤ６２０のＥＣリスト表示モジュール８１５は、遷移先が１つに限定されているか否かを判定する（ステップ５４０２）。
【0232】
この判定の結果、遷移先が１つに限定されている場合には（ＹＥＳ）、当該モジュールは設定遷移先に遷移する（ステップ５４０３）。一方、この判定の結果、遷移先が１つに限定されていない場合には（ＮＯ）、当該モジュールは、買えるＥＣ店のリクエストを商品情報管理サーバ６１０に送信する（ステップ５４０４）。このリクエストには、事業者ＩＤ、ユニバーサル銘柄ＩＤ、アクセス位置、セッションＣＤが添付されている。
【0233】
このリクエストにセッションＣＤが添付されている場合、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０のＥＣ情報提供モジュール７１８はユーザＩＤを取得する（ステップ５４０５）。ユーザＩＤを取得後、当該モジュールは、対象銘柄を買えるＥＣ店を抽出する（ステップ５４０６）。
【0234】
具体的には当該モジュールは、事業者商品テーブル３１００を参照して、受領したユニバーサル銘柄ＩＤと対応付けられている事業者ＩＤを抽出する。そして当該モジュールは、事業者マスタテーブル２５００をさらに参照して、抽出した事業者ＩＤのうち、ＥＣ ＵＲＬが登録されている事業者ＩＤを、買えるＥＣ店として抽出する。
【0235】
ＥＣ店を抽出後、当該モジュールは、対象ユーザが特定できる場合には、買えるＥＣ店について、ユーザの嗜好または条件で並び替えおよび／または絞り込みを行う（ステップ５４０７）。その際、当該モジュールは、ユーザ購入嗜好テーブル３０００（対象３００２＝ＥＣ）を参照する。以下に並べ替えと絞り込みの例を示す。
【0236】
（１）入手可能性（在庫状況）を優先する場合
当該モジュールは、事業者商品テーブル３１００を参照して、対象の事業者ＩＤおよび銘柄ＩＤに対応する在庫数に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（２）利用した店舗を優先する場合
当該モジュールは、ユーザ・事業者関係テーブル３８００を参照して、利用履歴に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（３）よく利用する業態を優先する場合
当該モジュールは、事業者マスタテーブル２５００とユーザ・事業者関係テーブル３８００を参照して、タイプに基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
当該モジュールは、事業者商品テーブル３１００を参照して、対象の事業者ＩＤおよび銘柄ＩＤに対応する在庫数に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（２）利用した店舗を優先する場合
当該モジュールは、ユーザ・事業者関係テーブル３８００を参照して、利用履歴に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（３）よく利用する業態を優先する場合
当該モジュールは、事業者マスタテーブル２５００とユーザ・事業者関係テーブル３８００を参照して、タイプに基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
【0237】
（４）店舗の評判を優先する場合
当該モジュールは、事業者マスタテーブル２５００を参照して、評価に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（５）配送に掛かるＣＯ２（理論値）を優先する場合
当該モジュールは、配送コストテーブル３４００を参照して、配送時ＣＯ２に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（６）価格を優先する場合
当該モジュールは、事業者商品テーブル３１００を参照して、対象の事業者ＩＤおよび銘柄ＩＤに対応する価格に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
当該モジュールは、事業者マスタテーブル２５００を参照して、評価に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（５）配送に掛かるＣＯ２（理論値）を優先する場合
当該モジュールは、配送コストテーブル３４００を参照して、配送時ＣＯ２に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
（６）価格を優先する場合
当該モジュールは、事業者商品テーブル３１００を参照して、対象の事業者ＩＤおよび銘柄ＩＤに対応する価格に基づいて事業者ＩＤを並び替えおよび／または絞り込みする。
【0238】
店舗の並び替えおよび／または絞り込み後、消費者ＤＤ６２０のＥＣリスト表示モジュール８１５は、価格を表示する場合には、配送コストテーブル３４００を参照して、対象の事業者ＩＤおよびエリアＩＤに対応する配送コストを抽出する（ステップ５４０８）。また当該モジュールは、排出ＣＯ２を表示する場合には、配送コストテーブル３４００を参照して、対象の事業者ＩＤおよびエリアＩＤに対応する配送時ＣＯ２を抽出する（ステップ５４０９）。
【0239】
配送時ＣＯ２を抽出後、当該モジュールは、店舗群をリスト化して表示する（ステップ５４１０）。その際、リストの表示内容は、データの登録状況に応じて決まる。例えば、出荷予定日、配達予定日、配送料の表示の有無は、配送コストテーブル３４００におけるデータの登録の有無に応じて決まる。合計価格と在庫数の表示の有無は、事業者商品テーブル３１００における価格と在庫数の登録の有無に応じて決まる。
【0240】
図７３は、店舗リストを有する銘柄カード７３００の例を示す。
銘柄カード７３００は、フェイス領域７３０１と、店舗リスト７３０２を有する。
このうち、店舗リスト７３０２は、対象銘柄を買えるＥＣ店のリストである。当該リストは、各ＥＣ店について、名称７３０３、在庫レベル７３０４、出荷予定日７３０５、配達予定日７３０６、配送料７３０７、合計（金額）７３０８および購入ボタン７３０９を示す。
銘柄カード７３００は、フェイス領域７３０１と、店舗リスト７３０２を有する。
このうち、店舗リスト７３０２は、対象銘柄を買えるＥＣ店のリストである。当該リストは、各ＥＣ店について、名称７３０３、在庫レベル７３０４、出荷予定日７３０５、配達予定日７３０６、配送料７３０７、合計（金額）７３０８および購入ボタン７３０９を示す。
【0241】
ＥＣリスト表示処理５４００の説明に戻る。
ユーザが上記のリストに表示された特定店舗をクリックまたは訪問、もしくは特定店舗で購入すると（ステップ５４１１）、ＥＣリスト表示モジュール８１５は、リクエストを商品情報管理サーバ６１０に送信する（ステップ５４１２）。このリクエストには、事業者ＩＤ、ユニバーサル銘柄ＩＤ、セッションＣＤ、クリック対象事業者ＩＤ、活動履歴情報が添付されている。
ユーザが上記のリストに表示された特定店舗をクリックまたは訪問、もしくは特定店舗で購入すると（ステップ５４１１）、ＥＣリスト表示モジュール８１５は、リクエストを商品情報管理サーバ６１０に送信する（ステップ５４１２）。このリクエストには、事業者ＩＤ、ユニバーサル銘柄ＩＤ、セッションＣＤ、クリック対象事業者ＩＤ、活動履歴情報が添付されている。
【0242】
このリクエストにセッションＣＤが添付されている場合、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０のＥＣ情報提供モジュール７１８はユーザＩＤを取得する（ステップ５４１３）。ユーザＩＤを取得後、当該モジュールは、ユーザ購入活動テーブル１４００に、受領した活動履歴を登録する（ステップ５４１４）。
【0243】
登録され、蓄積された活動履歴は、ユーザの嗜好または条件を推定する際に参照される（ステップ５４１５）。この推定処理は、ユーザ購入活動テーブル１４００を解析することで行われ、ユーザが重視する上位３つのファクターが抽出されてユーザ購入嗜好テーブル３０００に登録される。またこの推定処理は、週次、月次などの一定頻度で実行される。
以上がＥＣリスト表示処理５４００についての説明である。
以上がＥＣリスト表示処理５４００についての説明である。
【0244】
１－６－１９．ＥＣ店における商品通知処理
図５５は、ＥＣ店舗で実行される、訪問客のプレファレンスに基づく商品通知処理５５００の例を示す。
本処理は、ユーザ認証処理３９００が完了していることを前提としている。
本処理において消費者ＤＤ６２０のユーザがＥＣ店舗にアクセスすると（ステップ５５４０１）、消費者ＤＤ６２０の表示モジュール８２１はＥＣ画面を表示する（ステップ５５０２）。
図５５は、ＥＣ店舗で実行される、訪問客のプレファレンスに基づく商品通知処理５５００の例を示す。
本処理は、ユーザ認証処理３９００が完了していることを前提としている。
本処理において消費者ＤＤ６２０のユーザがＥＣ店舗にアクセスすると（ステップ５５４０１）、消費者ＤＤ６２０の表示モジュール８２１はＥＣ画面を表示する（ステップ５５０２）。
【0245】
この表示に伴い、消費者ＤＤ６２０の商品通知モジュール８１６は、リクエストを商品情報管理サーバ６１０に送信する（ステップ５５０３）。このリクエストには、セッションＣＤと事業者ＩＤが添付されている。
【0246】
このリクエストの送信に伴い、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０の商品情報提供モジュール７１９はユーザＩＤを取得する（ステップ５５０４）。ユーザＩＤを取得後、当該モジュールは、当該ユーザの活動履歴をユーザ購入活動テーブル１４００に登録する（ステップ５５０５）。
【0247】
登録後、当該モジュールは、当該ユーザが意向、行動または評価を記録した銘柄を抽出する（ステップ５５０６）。具体的には当該モジュールは、ユーザ・銘柄関係テーブル３７００から、取得したユーザＩＤに対応付けられている銘柄ＩＤとラベルを抽出する。
【0248】
加えて当該モジュールは、当該ユーザにお勧めの銘柄を抽出する（ステップ５５０７）。具体的には当該モジュールは、嗜好推定テーブル１９００から、取得したユーザＩＤに対応付けられており、かつ、推定値が一定以上の銘柄ＩＤを抽出し、ラベル「お勧め」と紐付ける。
【0249】
そして当該モジュールは、ステップ５５０６および５５０７で抽出した銘柄群から、対象事業者で取り扱っている商品群を絞り込む（ステップ５５０８）。具体的には当該モジュールは、事業者商品テーブル３１００から、対象の事業者ＩＤと、抽出した銘柄ＩＤに対応付けられた事業者独自の商品ＩＤを抽出する。抽出後、当該モジュールは、抽出した商品ＩＤと、対応する記録種別（ラベル）情報を消費者ＤＤ６２０に返却する（ステップ５５０９）。以下に返却データの例を示す。
【0250】
商品ＩＤ ラベル
x231203 飲みたい
x231204 飲んだ
x231205 飲んだ
x231212 好き
x231212 お勧め
x231203 飲みたい
x231204 飲んだ
x231205 飲んだ
x231212 好き
x231212 お勧め
【0251】
消費者ＤＤ６２０では、当スキームＤＡ６２１が表示／装飾を変更する場合は、商品通知モジュール８１６が対象商品の表示／装飾の変更コマンドを実行する（ステップ５５１０）。そして表示モジュール８２１がコマンドに応じて対象商品の表示／装飾を変更する（ステップ５５１１）。
【0252】
なお、この場合、例えば、商品ＩＤ「pxyz052」、記録種別「飲みたい」のときに、$('.tag4_pxyz052').addClass('view4_wish-to-drink')などの形で事業者ＤＡ６２２の表示を変更可能なプロトコルは、当該事業者ＤＡ６２２（の開発者）と商品情報管理サーバ６１０の間で事前に共有済みである。
【0253】
一方、消費者ＤＤ６２０において事業者ＤＡ６２２が表示／装飾を変更する場合は、商品通知モジュール８１６は受領データをそのまま表示モジュール８２１に返却する（ステップ５５１２）。そして表示モジュール８２１は、受領データ（アクセスユーザの商品ｘ行動種別）に応じて、適宜事業者ＤＡ６２２の表示を変更する（ステップ５５１３）。
以上が商品通知処理５５００についての説明である。
以上が商品通知処理５５００についての説明である。
【0254】
図７４は、対象商品に対して装飾が施されたＥＣ画面７４００の例を示す。
同図に示す画面では、ユーザが飲みたい銘柄７４０１が枠線７４０２で囲まれ、「飲みたい銘柄」とのラベル７４０３が付されている。
また同画面では、ユーザが飲んだ銘柄７４０４が枠線７４０５で囲まれ、「飲んだ銘柄」とのラベル７４０６が付されている。
同図に示す画面では、ユーザが飲みたい銘柄７４０１が枠線７４０２で囲まれ、「飲みたい銘柄」とのラベル７４０３が付されている。
また同画面では、ユーザが飲んだ銘柄７４０４が枠線７４０５で囲まれ、「飲んだ銘柄」とのラベル７４０６が付されている。
【0255】
なお、対象商品の通知は、対象商品のサイズ変更、対象商品周りの背景色変更、対象商品周りへの特定マークまたは特定アイコンの付与、または対象商品周りでの吹き出しなどの補足情報表示により行われてもよい。
【0256】
上記の商品通知処理５５００において当スキームＤＡ６２１が表示／装飾を変更する場合は、事業者ＤＡ６２２はアクセスユーザのユーザＩＤと記録した商品群およびラベルを取得することができない。ただし、当スキームＤＡ６２１は消費者ＤＤ６２０上で動作するため、事業者が利用規約を逸した対応を行った際には、当スキームＤＡ６２１内で取得している情報を取得されてしまうリスクがある。しかし、その場合でも、取扱商品以外の商品についてユーザが記録した情報は漏洩しない。
【0257】
一方、上記の処理において事業者ＤＡ６２２が表示／装飾を変更する場合は、事業者ＤＡ６２２は、記録した商品群およびラベルを取得できるが、アクセスユーザのユーザＩＤを取得することはできない。ただし、事業者ＤＡ６２２側でも別途ユーザ認証を実施していた場合は、「当該ユーザが記録した商品群と記録種別」として事業者側が当該データを保持できる状態になる。
【0258】
１－６－２０．実店舗における商品通知処理
図５６は、飲食店または小売店で実行される、来店客のプレファレンスに基づく商品通知処理５６００の例を示す。
本処理は、事業者認証処理４１００が完了していることを前提としている。
本処理において事業者ＤＤ６３０を使用する事業者は当スキームＤＡ６３１にアクセスする（ステップ５６０１）。このアクセスを受けて、事業者ＤＤ６３０のコード表示モジュール９１４は、ＱＲコード（登録商標）入りのポップ広告を表示する（ステップ５６０２）。事業者、このポップ広告を印刷して店頭に設置する（ステップ５６０３）。
図５６は、飲食店または小売店で実行される、来店客のプレファレンスに基づく商品通知処理５６００の例を示す。
本処理は、事業者認証処理４１００が完了していることを前提としている。
本処理において事業者ＤＤ６３０を使用する事業者は当スキームＤＡ６３１にアクセスする（ステップ５６０１）。このアクセスを受けて、事業者ＤＤ６３０のコード表示モジュール９１４は、ＱＲコード（登録商標）入りのポップ広告を表示する（ステップ５６０２）。事業者、このポップ広告を印刷して店頭に設置する（ステップ５６０３）。
【0259】
その後、消費者ＤＤ６２０のユーザは当該店舗に来店時に、店頭のＱＲコードを撮影する（ステップ５６０４）。この撮影を受けて、当スキームＤＡ６２１が起動されて、消費者ＤＤ６２０の商品通知モジュール８１６は、リクエストを商品情報管理サーバ６１０に送信する（ステップ５６０５）。このリクエストには、セッションＣＤと事業者ＩＤが添付されている。
【0260】
このリクエストの送信後、上記の商品通知処理５５００のステップ５５０４～５５１０が実行される。その後、消費者ＤＤ６２０の商品通知モジュール８１６は、対象商品を適宜通知する（ステップ５６０６）
【0261】
なお、上記の処理でユーザは、ＱＲコードを撮影することで当該店舗に来店したことを商品情報管理サーバ６１０に通知している。しかし、ＱＲコードの撮影に代えて、消費者ＤＤ６２０のＧＰＳ情報を商品情報管理サーバ６１０に送信することで、ユーザは当該店舗への来店を商品情報管理サーバ６１０に通知してもよい。また、別の変形例として、ＲＦタグ、ｂｅａｃｏｎ、Ｗｉ－Ｆｉ（登録商標）等を利用して、ユーザの実店舗への入出検知を行ってもよい。
【0262】
なお、上記の処理では消費者ＤＤ６２０を介してユーザに対して対象商品が通知されているが、対象商品の通知手段は消費者ＤＤ６２０に限られない。例えば、対象商品を、当該店舗に設置されたディスプレイ（例えば、電子看板）を介してユーザに通知してもよい。その場合、商品情報管理サーバ６１０は、対象商品の情報を、当該店舗を運営する事業者が管理するサーバに送信する。対象商品の情報を受信したサーバは、当該店舗に設置されたディスプレイにその情報を表示させる。
【0263】
図７５は、対象商品を通知するアプリ画面７５００の例を示す。同図に示す画面は、ユーザが飲みたい銘柄を通知するものである。
図７６は、別の画面例として、対象商品を通知するアプリ画面７６００を示す。同図に示す画面もまた、ユーザが飲みたい銘柄を通知するものである。ただし同画面には、２軸の要素評価のチャート７６０１が含まれる。
図７６は、別の画面例として、対象商品を通知するアプリ画面７６００を示す。同図に示す画面もまた、ユーザが飲みたい銘柄を通知するものである。ただし同画面には、２軸の要素評価のチャート７６０１が含まれる。
【0264】
このチャート７６０１には、複数のアイコン７６０２が配置されている。各アイコン７６０２は銘柄を表しており、各アイコン７６０２の位置は、２つの評価軸に対する当該銘柄の要素評価値を表している。
アプリ画面７６００が消費者ＤＤ６２０に表示される場合には、対象銘柄の要素評価値が商品情報管理サーバ６１０から消費者ＤＤ６２０に送信される。
以上が商品通知処理５６００についての説明である。
アプリ画面７６００が消費者ＤＤ６２０に表示される場合には、対象銘柄の要素評価値が商品情報管理サーバ６１０から消費者ＤＤ６２０に送信される。
以上が商品通知処理５６００についての説明である。
【0265】
１－６－２１．接客対応
図５７は、ユーザによる評価で蓄積された商品特性に基づく接客対応処理５７００の例を示す。
本処理は、商品データの連携が完了していることを前提としている。また本処理は、ユーザ認証処理３９００が完了していることを前提としている。
本処理においてユーザがアクセス操作をすると（ステップ５７０１）、消費者ＤＤ６２０の表示モジュール８２１はＥＣ画面を表示する（ステップ５７０２）。この表示に伴い、消費者ＤＤ６２０の提案銘柄通知モジュール８１７は接客パーツを表示する（ステップ５７０３）。この接客パーツは、対応可能な条件を適宜提示する。
図５７は、ユーザによる評価で蓄積された商品特性に基づく接客対応処理５７００の例を示す。
本処理は、商品データの連携が完了していることを前提としている。また本処理は、ユーザ認証処理３９００が完了していることを前提としている。
本処理においてユーザがアクセス操作をすると（ステップ５７０１）、消費者ＤＤ６２０の表示モジュール８２１はＥＣ画面を表示する（ステップ５７０２）。この表示に伴い、消費者ＤＤ６２０の提案銘柄通知モジュール８１７は接客パーツを表示する（ステップ５７０３）。この接客パーツは、対応可能な条件を適宜提示する。
【0266】
この接客パーツに対してユーザは、銘柄提案に対する多様なリクエストを行う（ステップ５７０４）。このリクエストを受けて、提案銘柄通知モジュール８１７は銘柄提案リクエストを商品情報管理サーバ６１０に送信する（ステップ５７０５）。このリクエストには、セッションＣＤ、事業者ＩＤ、要求内容が添付されている。
【0267】
このリクエストの送信に伴い、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０の銘柄提案モジュール７２０はユーザＩＤを取得する（ステップ５７０６）。ユーザＩＤを取得後、当該モジュールは、名称表記ゆれテーブル２８００を参照しつつ要求内容を解析して（ステップ５７０７）、対応可能な条件に合致する形で要求がクリアになったか否かを判定する（ステップ５７０８）。この判定の結果、要求がクリアでない場合には（ＮＯ）、消費者ＤＤ６２０の提案銘柄通知モジュール８１７は不足している点や曖昧な点を確認し（ステップ５７０９）、ユーザは問いに答え（ステップ５７１０）、提案銘柄通知モジュール８１７は再度リクエストを商品情報管理サーバ６１０に送信する（ステップ５７１１）。
【0268】
一方、ステップ５７０８の判定の結果、要求がクリアになった場合には（ＹＥＳ）、商品情報管理サーバ６１０の銘柄提案モジュール７２０は次にステップ５７１２を実行する。
なお、上記のステップ５７０７～５７１１は、対応可能な条件に合致する形で要求がクリアになるまで繰り返し実行される。これらのステップは、汎用的な言語解析ＡＩ（ＡＰＩ）を利用して実行される。
なお、上記のステップ５７０７～５７１１は、対応可能な条件に合致する形で要求がクリアになるまで繰り返し実行される。これらのステップは、汎用的な言語解析ＡＩ（ＡＰＩ）を利用して実行される。
【0269】
ステップ５７１２において銘柄提案モジュール７２０は、指定された条件に該当する銘柄を抽出する。この際、対応可能な銘柄抽出条件は以下の通りである。
【0270】
（１）銘柄の基本情報（カテゴリ、産地、メーカなど）
当該モジュールは、銘柄マスタテーブル２０００から、指定されたカテゴリＩＤ、エリアＩＤまたはメーカＩＤに対応付けられている銘柄ＩＤを抽出する。
（２）銘柄の属性情報（原材料、製法など）
当該モジュールは、銘柄・要素関係テーブル３５００から、指定された要素ＩＤに対応付けられている銘柄ＩＤを抽出する。
（３）銘柄の各種特性（白身魚に合う、祝い事にお勧めなど）
当該モジュールは、銘柄特徴テーブル１７００から、指定された要素ＩＤの特徴が強い銘柄ＩＤを抽出する。
当該モジュールは、銘柄マスタテーブル２０００から、指定されたカテゴリＩＤ、エリアＩＤまたはメーカＩＤに対応付けられている銘柄ＩＤを抽出する。
（２）銘柄の属性情報（原材料、製法など）
当該モジュールは、銘柄・要素関係テーブル３５００から、指定された要素ＩＤに対応付けられている銘柄ＩＤを抽出する。
（３）銘柄の各種特性（白身魚に合う、祝い事にお勧めなど）
当該モジュールは、銘柄特徴テーブル１７００から、指定された要素ＩＤの特徴が強い銘柄ＩＤを抽出する。
【0271】
（４）銘柄の受賞履歴、露出履歴（○○金賞受賞など）
当該モジュールは、銘柄・メディア関係テーブル３６００から、指定されたメディアＩＤに対応付けられている銘柄ＩＤを抽出する。
（５）対象ユーザの意向、行動（飲みたい銘柄、飲んだ銘柄、お気に入り銘柄など）
当該モジュールは、ユーザ・銘柄関係テーブル３７００から、対象ユーザに指定された意向、履歴が登録されている銘柄ＩＤを抽出する。
（６）対象ユーザの嗜好
当該モジュールは、嗜好推定テーブル１９００から、対象ユーザに対応付けられており、かつ、推定値が一定以上の銘柄ＩＤを抽出する。
当該モジュールは、銘柄・メディア関係テーブル３６００から、指定されたメディアＩＤに対応付けられている銘柄ＩＤを抽出する。
（５）対象ユーザの意向、行動（飲みたい銘柄、飲んだ銘柄、お気に入り銘柄など）
当該モジュールは、ユーザ・銘柄関係テーブル３７００から、対象ユーザに指定された意向、履歴が登録されている銘柄ＩＤを抽出する。
（６）対象ユーザの嗜好
当該モジュールは、嗜好推定テーブル１９００から、対象ユーザに対応付けられており、かつ、推定値が一定以上の銘柄ＩＤを抽出する。
【0272】
銘柄の抽出後、消費者ＤＤ６２０の提案銘柄通知モジュール８１７は、抽出された銘柄を提示する（ステップ５７１３）。銘柄の提示方法は、テキストベースに限らず、音声または画像ベースでもよい。
以上が接客対応処理５７００についての説明である。
以上が接客対応処理５７００についての説明である。
【0273】
上述した接客対応処理５７００のステップ５７１２と商品通知処理５５００のステップ５５０７では、嗜好推定テーブル１９００が参照される。この嗜好推定テーブル１９００は、以下の手順で生成される。
（１）登録処理５０００を通じて、投稿テーブル１１００、投稿銘柄テーブル１２００、投稿評価テーブル１３００にデータが蓄積される。
（２）上記３つのテーブルに蓄積されたデータに基づき、ユーザ別に嗜好モデルテーブル１８００が更新される。
（１）登録処理５０００を通じて、投稿テーブル１１００、投稿銘柄テーブル１２００、投稿評価テーブル１３００にデータが蓄積される。
（２）上記３つのテーブルに蓄積されたデータに基づき、ユーザ別に嗜好モデルテーブル１８００が更新される。
【0274】
（３）上記３つのテーブルに蓄積されたデータと、造り手に登録された銘柄特性情報に基づき、銘柄特徴テーブル１７００が更新される。
（４）銘柄特徴テーブル１７００と嗜好モデルテーブル１８００に基づき、嗜好推定テーブル１９００が更新される。
以下、（２）～（４）の処理について説明する。
（４）銘柄特徴テーブル１７００と嗜好モデルテーブル１８００に基づき、嗜好推定テーブル１９００が更新される。
以下、（２）～（４）の処理について説明する。
【0275】
１－６－２２．嗜好モデルの生成
図５８は、嗜好モデルの生成フロー５８００の例を示す。
本フローは、商品情報管理サーバ６１０のモデル生成モジュール７２７により、ユーザとカテゴリの各組について定期的に実行される。
本フローにおいてモデル生成モジュール７２７は、処理対象となるユーザＩＤとカテゴリＩＤを取得する（ステップ５８０１）。
図５８は、嗜好モデルの生成フロー５８００の例を示す。
本フローは、商品情報管理サーバ６１０のモデル生成モジュール７２７により、ユーザとカテゴリの各組について定期的に実行される。
本フローにおいてモデル生成モジュール７２７は、処理対象となるユーザＩＤとカテゴリＩＤを取得する（ステップ５８０１）。
【0276】
ユーザＩＤ等を取得後、当該モジュールは、各銘柄の総合評価値と商品特性値を取得する。具体的には当該モジュールは、投稿テーブル１１００から、取得したユーザＩＤと対応付けられている投稿ＩＤを取得する（ステップ５８０２）。
投稿ＩＤを取得後、当該モジュールは、銘柄マスタテーブル２０００から、取得したカテゴリＩＤと対応付けられている銘柄ＩＤを取得する（ステップ５８０３）。
投稿ＩＤを取得後、当該モジュールは、銘柄マスタテーブル２０００から、取得したカテゴリＩＤと対応付けられている銘柄ＩＤを取得する（ステップ５８０３）。
【0277】
銘柄ＩＤを取得後、当該モジュールは、投稿銘柄テーブル１２００から、取得した投稿ＩＤと銘柄ＩＤとに対応付けられている総合評価値を取得する（ステップ５８０４）。
総合評価値を取得後、当該モジュールは、銘柄特徴テーブル１７００から、取得した銘柄ＩＤと対応付けられている適用値を取得する（ステップ５８０５）。
総合評価値を取得後、当該モジュールは、銘柄特徴テーブル１７００から、取得した銘柄ＩＤと対応付けられている適用値を取得する（ステップ５８０５）。
【0278】
各銘柄の総合評価値と適用値を取得すると、当該モジュールは、取得した総合評価値と適用値に基づいて重回帰分析を行い、総合評価を目的変数とし商品特性を説明変数とする嗜好モデルを生成する（ステップ５８０６）。その際、当該モジュールは、多重共線性の発生を防止するために、説明変数とする要素を所定の要素に絞り込んでもよい。
当該モジュールは、要素ごとの偏回帰係数および標準偏回帰係数と、切片を、取得したユーザＩＤとカテゴリＩＤとに対応付けて嗜好モデルテーブル１８００に格納する（ステップ５８０７）。
以上が嗜好モデルの生成フロー５８００についての説明である。
当該モジュールは、要素ごとの偏回帰係数および標準偏回帰係数と、切片を、取得したユーザＩＤとカテゴリＩＤとに対応付けて嗜好モデルテーブル１８００に格納する（ステップ５８０７）。
以上が嗜好モデルの生成フロー５８００についての説明である。
【0279】
１－６－２３．主観的定量値の補正
図５９は、主観的定量値の補正フロー５９００の例を示す。
本フローは、商品情報管理サーバ６１０の補正モジュール７２８により実行される。
本フローにおいて補正モジュール７２８は、処理対象の銘柄について、銘柄特徴テーブル１７００から、処理対象の要素ＩＤを１つ取得する（ステップ５９０１）。その際、当該モジュールは、銘柄特徴テーブル１７００においてタイプＡ「主観的」とタイプＢ「定量値」に対応付けられている要素ＩＤ（すなわち、主観的定量値の要素ＩＤ）を取得する。
図５９は、主観的定量値の補正フロー５９００の例を示す。
本フローは、商品情報管理サーバ６１０の補正モジュール７２８により実行される。
本フローにおいて補正モジュール７２８は、処理対象の銘柄について、銘柄特徴テーブル１７００から、処理対象の要素ＩＤを１つ取得する（ステップ５９０１）。その際、当該モジュールは、銘柄特徴テーブル１７００においてタイプＡ「主観的」とタイプＢ「定量値」に対応付けられている要素ＩＤ（すなわち、主観的定量値の要素ＩＤ）を取得する。
【0280】
要素ＩＤを取得後、当該モジュールは、投稿評価テーブル１３００から、取得した要素ＩＤと対応付けられている要素評価値をすべて取得する（ステップ５９０２）。
要素評価値を取得後、当該モジュールは、取得した要素評価値の平均値と標準偏差を計算する（ステップ５９０３）。
計算後、当該モジュールは、計算した平均値と標準偏差を、取得した要素ＩＤと対応付けて銘柄特徴テーブル１７００に格納する（ステップ５９０４）。
要素評価値を取得後、当該モジュールは、取得した要素評価値の平均値と標準偏差を計算する（ステップ５９０３）。
計算後、当該モジュールは、計算した平均値と標準偏差を、取得した要素ＩＤと対応付けて銘柄特徴テーブル１７００に格納する（ステップ５９０４）。
【0281】
格納後、当該モジュールは、銘柄特徴テーブル１７００から、取得した要素ＩＤと対応付けられている格納値を取得する（ステップ５９０５）。
格納値を取得後、当該モジュールは、取得した格納値と、計算した平均値および標準偏差とに基づいて適用値を計算する（ステップ５９０６）。具体的には当該モジュールは、格納値が平均値±１σの範囲に含まれる場合には格納値を適用値とみなし、そうでない場合には格納値と平均値の加重平均値を適用値とみなす。
当該モジュールは、計算した適用値を、取得した要素ＩＤと対応付けて銘柄特徴テーブル１７００に格納する（ステップ５９０７）。
格納値を取得後、当該モジュールは、取得した格納値と、計算した平均値および標準偏差とに基づいて適用値を計算する（ステップ５９０６）。具体的には当該モジュールは、格納値が平均値±１σの範囲に含まれる場合には格納値を適用値とみなし、そうでない場合には格納値と平均値の加重平均値を適用値とみなす。
当該モジュールは、計算した適用値を、取得した要素ＩＤと対応付けて銘柄特徴テーブル１７００に格納する（ステップ５９０７）。
【0282】
格納後、当該モジュールは、処理対象の銘柄のすべての主観的定量値について適用値を計算したか否かを判定する（ステップ５９０８）。この判定の結果、すべての主観的定量値について適用値を計算していない場合には、当該モジュールはステップ５９０１を実行する。一方、すべての主観的定量値について適用値を計算した場合には、当該モジュールは、すべての処理対象の銘柄について適用値を計算したか否かを判定する（ステップ５９０９）。この判定の結果、すべての処理対象の銘柄について適用値を計算していない場合には、当該モジュールはステップ５９０１を実行する。一方、すべての処理対象の銘柄について適用値を計算した場合には、当該モジュールは本補正フローを終了する。
【0283】
以上説明した補正フローにより、銘柄特徴テーブル１７００に予め格納されている格納値に、ユーザの実際の評価を反映させることができる。
【0284】
１－６－２４．嗜好推定テーブル１９００の生成
図６０は、嗜好推定テーブル１９００の生成フロー６０００の例を示す。
本フローは、商品情報管理サーバ６１０の嗜好推定モジュール７２９により実行される。
本フローにおいて嗜好推定モジュール７２９は、投稿テーブル１１００から、対象のユーザＩＤと対応付けられている投稿ＩＤを取得する（ステップ６００１）。
投稿ＩＤを取得後、当該モジュールは、銘柄マスタテーブル２０００から、取得したカテゴリＩＤと対応付けられている銘柄ＩＤを取得する（ステップ６００２）。
図６０は、嗜好推定テーブル１９００の生成フロー６０００の例を示す。
本フローは、商品情報管理サーバ６１０の嗜好推定モジュール７２９により実行される。
本フローにおいて嗜好推定モジュール７２９は、投稿テーブル１１００から、対象のユーザＩＤと対応付けられている投稿ＩＤを取得する（ステップ６００１）。
投稿ＩＤを取得後、当該モジュールは、銘柄マスタテーブル２０００から、取得したカテゴリＩＤと対応付けられている銘柄ＩＤを取得する（ステップ６００２）。
【0285】
銘柄ＩＤを取得後、当該モジュールは、投稿銘柄テーブル１２００から、取得した投稿ＩＤと銘柄ＩＤとに対応付けられている総合評価値を取得する（ステップ６００３）。
総合評価値を取得後、当該モジュールは、銘柄特徴テーブル１７００から、取得した投稿ＩＤと対応付けられている各要素の適用値を取得する（ステップ６００４）。
適用値を取得後、当該モジュールは、取得したユーザＩＤ、カテゴリＩＤ、銘柄ＩＤ、総合評価値および適用値を対応付けて嗜好推定テーブル１９００に格納する（ステップ６００５）。
総合評価値を取得後、当該モジュールは、銘柄特徴テーブル１７００から、取得した投稿ＩＤと対応付けられている各要素の適用値を取得する（ステップ６００４）。
適用値を取得後、当該モジュールは、取得したユーザＩＤ、カテゴリＩＤ、銘柄ＩＤ、総合評価値および適用値を対応付けて嗜好推定テーブル１９００に格納する（ステップ６００５）。
【0286】
嗜好推定テーブル１９００を生成すると、当該モジュールは、嗜好モデルテーブル１８００から、取得したユーザＩＤとカテゴリＩＤとに対応付けられている嗜好モデルを取得する（ステップ６００６）。
当該モジュールは、嗜好推定テーブル１９００に登録した各銘柄ＩＤについて、取得した嗜好モデルに適用値を入力して総合評価値を推定し、推定した総合評価値を嗜好推定テーブル１９００に格納する（ステップ６００７）。その際、当該モジュールは、嗜好推定テーブル１９００に登録した銘柄ＩＤのうち、総合評価値（実績値）が登録されていない銘柄ＩＤについてのみ、総合評価値を推定する。
以上が生成フロー６０００についての説明である。
当該モジュールは、嗜好推定テーブル１９００に登録した各銘柄ＩＤについて、取得した嗜好モデルに適用値を入力して総合評価値を推定し、推定した総合評価値を嗜好推定テーブル１９００に格納する（ステップ６００７）。その際、当該モジュールは、嗜好推定テーブル１９００に登録した銘柄ＩＤのうち、総合評価値（実績値）が登録されていない銘柄ＩＤについてのみ、総合評価値を推定する。
以上が生成フロー６０００についての説明である。
【0287】
１－６－２５．リワードプログラムの登録処理
図６１は、事業者によるリワードプログラムの登録処理６１００の例を示す。
本処理は、事業者認証処理４１００が完了していることを前提としている。
本処理において事業者がリワード登録ページにアクセスすると（ステップ６１０１）、事業者ＤＤ６３０のリワードプログラム登録モジュール９１５はリワード登録フォームを表示する（ステップ６１０２）。事業者は、このフォームに対象、条件および内容を入力する（ステップ６１０３）。
図６１は、事業者によるリワードプログラムの登録処理６１００の例を示す。
本処理は、事業者認証処理４１００が完了していることを前提としている。
本処理において事業者がリワード登録ページにアクセスすると（ステップ６１０１）、事業者ＤＤ６３０のリワードプログラム登録モジュール９１５はリワード登録フォームを表示する（ステップ６１０２）。事業者は、このフォームに対象、条件および内容を入力する（ステップ６１０３）。
【0288】
ここで対象は、メーカ（群）、産地（群）、カテゴリ（群）で指定される。
条件は、ユーザの「飲んだ」投稿、ユーザが撮影した画像に基づく「飲んだ」投稿、連携売り手において「買った」履歴などである。
内容は、特定店舗における割引クーポン配布や景品送付などである。
条件は、ユーザの「飲んだ」投稿、ユーザが撮影した画像に基づく「飲んだ」投稿、連携売り手において「買った」履歴などである。
内容は、特定店舗における割引クーポン配布や景品送付などである。
【0289】
対象等の入力後、リワードプログラム登録モジュール９１５はプログラム登録リクエストを商品情報管理サーバ６１０に送信する（ステップ６１０４）。商品情報管理サーバ６１０のリワードプログラム管理モジュール７２１は、受領したリワードプログラムの情報を事業者リワードプログラムテーブル３２００に登録する（ステップ６１０５）。登録後、リワードプログラム登録モジュール９１５は登録完了を通知する（ステップ６１０６）。
以上がリワードプログラムの登録処理６１００についての説明である。
以上がリワードプログラムの登録処理６１００についての説明である。
【0290】
１－６－２６．ユーザによるリワード蓄積状況の定期算出
ユーザ・銘柄関係テーブル３７００に基づいて、ユーザ・事業者関係テーブル３８００に登録されているリワードプログラムごとの蓄積状況が算出される。この計算は、日次など一定頻度で行われる。
ユーザ・銘柄関係テーブル３７００に基づいて、ユーザ・事業者関係テーブル３８００に登録されているリワードプログラムごとの蓄積状況が算出される。この計算は、日次など一定頻度で行われる。
【0291】
１－６－２７．ユーザによるリワードプログラムの利用処理
図６２は、ユーザによるリワードプログラムの利用処理６２００の例を示す。
本処理は、ユーザ認証処理３９００が完了していることを前提としている。
本処理においてユーザがリワードプログラムページにアクセスすると（ステップ６２０１）、消費者ＤＤ６２０のリワード利用モジュール８１８は状況確認リクエストを商品情報管理サーバ６１０に送信する（ステップ６２０２）。このリクエストには、セッションＣＤが添付されている。
図６２は、ユーザによるリワードプログラムの利用処理６２００の例を示す。
本処理は、ユーザ認証処理３９００が完了していることを前提としている。
本処理においてユーザがリワードプログラムページにアクセスすると（ステップ６２０１）、消費者ＤＤ６２０のリワード利用モジュール８１８は状況確認リクエストを商品情報管理サーバ６１０に送信する（ステップ６２０２）。このリクエストには、セッションＣＤが添付されている。
【0292】
このリクエストの送信に伴い、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０のリワード管理モジュール７２２はユーザＩＤを取得する（ステップ６２０３）。ユーザＩＤを取得後、当該モジュールは、ユーザ・事業者関係テーブル３８００から該当するプログラムの情報を抽出する（ステップ６２０４）。この抽出後、消費者ＤＤ６２０のリワード利用モジュール８１８は、該当プログラムとその蓄積状況を出力する（ステップ６２０５）。この出力結果を見て、事業者は蓄積状況を確認する（ステップ６２０６）。
【0293】
ユーザが蓄積値をリワードに交換する場合には、交換申込を行う（ステップ６２０７）。この操作を受けて、リワード利用モジュール８１８は交換リクエストを商品情報管理サーバ６１０に送信する（ステップ６２０８）。このリクエストには、セッションＣＤ、プログラムＩＤ、消化範囲情報が添付されている。
【0294】
このリクエストを受けて、商品情報管理サーバ６１０のリワード管理モジュール７２２は、ユーザ・事業者関係テーブル３８００においてリワード消化処理を実行する（ステップ６２０９）。この実行に伴い、事業者サーバ６４０はリワード内容に応じた手続きを開始する（ステップ６２１０）。手続きの開始後、商品情報管理サーバ６１０のリワード管理モジュール７２２は、リワード交換ガイダンスのポインタＵＲＬを消費者ＤＤ６２０に返却する（ステップ６２１１）。消費者ＤＤ６２０のリワード利用モジュール８１８は、受領したリワード交換ガイダンスのポインタを表示する（ステップ６２１２）。
以上がリワードプログラムの利用処理６２００についての説明である。
以上がリワードプログラムの利用処理６２００についての説明である。
【0295】
１－６－２８．事業者によるプログラム販売処理
図６３は、事業者によるプログラム販売処理６３００の例を示す。ここで言うプログラムとは、サブスクリプションプログラムのことである。
本処理は、ユーザ認証処理３９００と事業者認証処理４１００が完了していることを前提としている。
図６３は、事業者によるプログラム販売処理６３００の例を示す。ここで言うプログラムとは、サブスクリプションプログラムのことである。
本処理は、ユーザ認証処理３９００と事業者認証処理４１００が完了していることを前提としている。
【0296】
本処理において事業者はプログラムを登録する（ステップ６３０１、６３０２）。具体的には事業者は、プログラムＩＤ送付頻度、送付あたり販売単価、送付あたり原価予算を事業者サーバ６４０に登録する。この登録を受けて、事業者ＤＤ６３０のプログラム登録モジュール９１６はプログラム登録リクエストを商品情報管理サーバ６１０に送信する（ステップ６３０３）。このリクエストには、事業者ＩＤ、プログラムＩＤ、送付あたりの原価予算情報が添付されている。
【0297】
商品情報管理サーバ６１０のプログラム管理モジュール７２３は、事業者サブスクリプションプログラムテーブル３３００に、受領した情報を登録する（ステップ６３０４）。
【0298】
消費者ＤＤ６２０の表示モジュール８２１は、事業者サーバ６４０に登録されたプログラムをユーザに販売する（ステップ６３０５）。ユーザがこのプログラムを購入すると（ステップ６３０６）、表示モジュール８２１は決済処理を事業者サーバ６４０に要求する（ステップ６３０７）。この要求を受けて、事業者サーバ６４０は決済処理を実行し、ユーザキーを発行する（ステップ６３０８）。ユーザキーの発行後、表示モジュール８２１は決済完了を商品情報管理サーバ６１０に通知する（ステップ６３０９）。この通知には、セッションＣＤ、プログラムＩＤ、ユーザキーが添付されている。
【0299】
この通知に伴い、ユーザＩＤ取得処理４０００が実行され、商品情報管理サーバ６１０のプログラム管理モジュール７２３はユーザＩＤを取得する（ステップ６３１０）。ユーザＩＤを取得後、当該モジュールは、ユーザＩＤ、ユーザキー、プログラムＩＤを対応付けてユーザ・事業者関係テーブル３８００に登録する（ステップ６３１１）。
以上がプログラム販売処理６３００についての説明である。
以上がプログラム販売処理６３００についての説明である。
【0300】
１－６－２９．ユーザへの商品配送処理
図６４は、ユーザへの商品配送処理６４００の例を示す。ここで言う商品とは、サブスクリプションプログラムに従って配送される商品のことである。
本処理において事業者サーバ６４０は商品選定リクエストを商品情報管理サーバ６１０に送信する（ステップ６４０１）。このリクエストには、プログラムＩＤとユーザキーが添付されている。
図６４は、ユーザへの商品配送処理６４００の例を示す。ここで言う商品とは、サブスクリプションプログラムに従って配送される商品のことである。
本処理において事業者サーバ６４０は商品選定リクエストを商品情報管理サーバ６１０に送信する（ステップ６４０１）。このリクエストには、プログラムＩＤとユーザキーが添付されている。
【0301】
商品情報管理サーバ６１０の商品選定モジュール７２４は、ユーザ・事業者関係テーブル３８００から、受領したプログラムＩＤとユーザキーに対応付けられているユーザＩＤを抽出する（ステップ６４０２）。また当該モジュールは、事業者サブスクリプションプログラムテーブル３３００を参照して、受領したプログラムＩＤに対応付けられている原価予算を抽出する。
【0302】
次に当該モジュールは、ユーザ・銘柄関係テーブル３７００を参照して、当該ユーザが「飲みたい」または「お気に入り（好き）」として登録した銘柄ＩＤを抽出する（ステップ６４０３）。
加えて当該モジュールは、当該ユーザにお勧めの銘柄を抽出する（ステップ６４０４）。具体的には当該モジュールは、嗜好推定テーブル１９００から、取得したユーザＩＤに対応付けられており、かつ、推定値が一定以上の銘柄ＩＤを抽出する。
加えて当該モジュールは、当該ユーザにお勧めの銘柄を抽出する（ステップ６４０４）。具体的には当該モジュールは、嗜好推定テーブル１９００から、取得したユーザＩＤに対応付けられており、かつ、推定値が一定以上の銘柄ＩＤを抽出する。
【0303】
次に当該モジュールは、抽出した銘柄群から、対象事業者で取り扱っていて、予算に収まる商品群を絞り込む（ステップ６４０５）。具体的には当該モジュールは、事業者商品テーブル３１００から、対象事業者ＩＤと、ステップ６４０３または６４０４で抽出した銘柄ＩＤと、予算以下の価格とに対応付けられている銘柄ＩＤと事業者独自の商品ＩＤを抽出する。その際、当該モジュールは、当該テーブルに在庫情報が登録されていれば、在庫のある商品を抽出する。
【0304】
次に当該モジュールは、抽出した商品群から、過去にユーザに送付した銘柄を除外する（ステップ６４０６）。具体的には当該モジュールは、ユーザ・銘柄関係テーブル３７００から、対象ユーザＩＤと対象プログラムＩＤ（登録起点情報３７０７）に対応付けられている銘柄ＩＤを抽出する。そして当該モジュールは、抽出した銘柄の商品を、ステップ６４０５で抽出した商品群から除外する。
【0305】
次に当該モジュールは、残った商品群から、お勧め度合いが最も高い商品を選定する（ステップ６４０７）。具体的には当該モジュールは、嗜好推定テーブル１９００から、対象ユーザＩＤと、最高の実績値または推定値と対応付けられている銘柄ＩＤを抽出する。そして当該モジュールは、抽出した銘柄の商品を選定する。
【0306】
次に当該モジュールは、対象商品を選定した実績をユーザ・銘柄関係テーブル３７００に登録する（ステップ６４０８）。具体的には当該モジュールは、当該テーブルに、対象ユーザＩＤと、ステップ６４０７で抽出した銘柄ＩＤと対応付けて、「買った」（ラベル３７０３）、対象事業者ＩＤ（登録起点事業者ＩＤ３７０６）、対象プログラムＩＤ（登録起点情報３７０７）を登録する。
【0307】
登録後、事業者サーバ６４０は、ステップ６４０７で選定された商品について配送手続きを開始する（ステップ６４０９）。
以上が商品配送処理６４００についての説明である。
以上が商品配送処理６４００についての説明である。
【0308】
２．変形例
上記の実施例は以下のように変形してもよい。
（１）嗜好モデルの生成フロー５８００では、重回帰分析で嗜好モデルを生成している（ステップ５８０７参照）。しかし、これに代えて、その他の統計学的手法や機械学習手法を用いて嗜好モデルを生成してもよい。
上記の実施例は以下のように変形してもよい。
（１）嗜好モデルの生成フロー５８００では、重回帰分析で嗜好モデルを生成している（ステップ５８０７参照）。しかし、これに代えて、その他の統計学的手法や機械学習手法を用いて嗜好モデルを生成してもよい。
【0309】
（２）上記の実施例では酒類を対象商品として想定している。しかし、酒類に代えて他の嗜好性商品を対象商品として採用してもよい。
【0310】
（３）銘柄パーツの応用例として、売り手が自社営業担当向けに銘柄パーツを流用するアプリケーションを採用してもよい。このようなアプリケーションによれば、造り手がキャンペーン情報などのページやＰＤＦファイルを複数の売り手の営業担当に展開できる。
【0311】
（４）銘柄パーツの簡素版（商品画像のみ）の応用例として、飲食店または飲食店のメニュー制作会社が、各造り手が登録した商品画像をまとめて閲覧および選択して、飲食店のメニュー作成アプリに当該画像群を取り込めるように連携できるアプリケーションを採用してもよい。
【0312】
（５）リワードプログラムを登録または利用するためのアプリケーションは、当スキームＤＡ６２１または６３１に限られず、任意の事業者のアプリケーション（当モジュールが組み込まれた形）であってもよい。
【0313】
（６）リワードプログラムと対応付けて蓄積される実績情報は、「買った」という実績情報に限られず、「飲んだ」という実績情報も含めてもよい。
【0314】
（７）商品取扱情報を卸の販売データに基づいて商品情報管理サーバ６１０に登録した場合、店舗側が所定のフォームから当該データの掲載を拒否することを可能にしてもよい。
【0315】
（８）事業者の位置付けに応じて銘柄パーツの情報登録権を設定してもよい。
図７７は、事業者の位置付けに応じて設定された銘柄パーツの情報登録権の例を示す。
同図に示すように、対象銘柄の造り手は、銘柄パーツのフェイス設定と造り手の銘柄ＰＲを登録することができる。ここで、銘柄パーツのフェイス設定とは、例えば、図６９に例示する商品の名称６９０２や商品のラベル画像６９０７である。一方、造り手の銘柄ＰＲとは、図６６に例示する造り手の銘柄紹介タブ６６１２を選択したときに表示される情報である。
図７７は、事業者の位置付けに応じて設定された銘柄パーツの情報登録権の例を示す。
同図に示すように、対象銘柄の造り手は、銘柄パーツのフェイス設定と造り手の銘柄ＰＲを登録することができる。ここで、銘柄パーツのフェイス設定とは、例えば、図６９に例示する商品の名称６９０２や商品のラベル画像６９０７である。一方、造り手の銘柄ＰＲとは、図６６に例示する造り手の銘柄紹介タブ６６１２を選択したときに表示される情報である。
【0316】
次に、対象銘柄の造り手代理について説明する。
対象銘柄の造り手代理は、特定エリアにおいて対象銘柄の独占販売権を有する売り手である。上記の実施例では、この造り手代理と造り手を「造り手」と総称している。
この対象銘柄の造り手代理は、銘柄パーツのフェイス設定、造り手の銘柄ＰＲおよび売り手の銘柄ＰＲを登録することができる。ここで、売り手の銘柄ＰＲとは、図７０に例示する売り手による簡単な銘柄紹介７００５、または、売り手の銘柄紹介タブ７００８を選択したときに表示される情報である。
対象銘柄の造り手代理は、特定エリアにおいて対象銘柄の独占販売権を有する売り手である。上記の実施例では、この造り手代理と造り手を「造り手」と総称している。
この対象銘柄の造り手代理は、銘柄パーツのフェイス設定、造り手の銘柄ＰＲおよび売り手の銘柄ＰＲを登録することができる。ここで、売り手の銘柄ＰＲとは、図７０に例示する売り手による簡単な銘柄紹介７００５、または、売り手の銘柄紹介タブ７００８を選択したときに表示される情報である。
【0317】
造り手代理が登録可能な情報のうち、銘柄パーツのフェイス設定と造り手の銘柄ＰＲは、造り手代理の販売エリアにおける消費者のアクセスに対して表示される。
その際、それらの情報は、造り手が対象情報を未登録の場合には無条件に表示され、造り手が対象情報を登録済みの場合には、造り手代理がＰＲ優先権を有している場合にのみ表示される。
一方、売り手の銘柄ＰＲは、造り手代理が運営するＤＡ上に組み込んだ銘柄パーツのみにおいて表示される。
その際、それらの情報は、造り手が対象情報を未登録の場合には無条件に表示され、造り手が対象情報を登録済みの場合には、造り手代理がＰＲ優先権を有している場合にのみ表示される。
一方、売り手の銘柄ＰＲは、造り手代理が運営するＤＡ上に組み込んだ銘柄パーツのみにおいて表示される。
【0318】
次に、売り手について説明する。
この売り手は、独占販売権を有しないが、対象銘柄を販売する売り手である。この売り手は、売り手の銘柄ＰＲのみを登録することができる。
この売り手が登録した売り手の銘柄ＰＲは、当該売り手が運営するＤＡ上に組み込んだ銘柄パーツのみにおいて表示される。
この売り手は、独占販売権を有しないが、対象銘柄を販売する売り手である。この売り手は、売り手の銘柄ＰＲのみを登録することができる。
この売り手が登録した売り手の銘柄ＰＲは、当該売り手が運営するＤＡ上に組み込んだ銘柄パーツのみにおいて表示される。
【0319】
各事業者の位置付けの判定方法は、例えば、以下の通りである。
事業者ＤＤ６３０におけるアクセス事業者ＩＤが、銘柄マスタテーブル２０００における対象銘柄のメーカＩＤと一致する場合には、当該事業者は対象銘柄の造り手と判定される。
事業者ＤＤ６３０におけるアクセス事業者ＩＤが、後述する事業者・銘柄関係テーブル７７００において対象銘柄の独占販売権を有する事業者ＩＤと一致する場合には、当該事業者は対象銘柄の造り手代理と判定される。
事業者ＤＤ６３０におけるアクセス事業者ＩＤが、後述する事業者・銘柄関係テーブル７７００または事業者商品テーブル３１００において対象銘柄の販売実績を有する事業者ＩＤと一致する場合には、当該事業者は対象銘柄の売り手と判定される。
事業者ＤＤ６３０におけるアクセス事業者ＩＤが、銘柄マスタテーブル２０００における対象銘柄のメーカＩＤと一致する場合には、当該事業者は対象銘柄の造り手と判定される。
事業者ＤＤ６３０におけるアクセス事業者ＩＤが、後述する事業者・銘柄関係テーブル７７００において対象銘柄の独占販売権を有する事業者ＩＤと一致する場合には、当該事業者は対象銘柄の造り手代理と判定される。
事業者ＤＤ６３０におけるアクセス事業者ＩＤが、後述する事業者・銘柄関係テーブル７７００または事業者商品テーブル３１００において対象銘柄の販売実績を有する事業者ＩＤと一致する場合には、当該事業者は対象銘柄の売り手と判定される。
【0320】
図７８は、各事業者について銘柄ごとに情報登録権を設定するための事業者・銘柄関係テーブル７７００の例を示す。
事業者・銘柄関係テーブル７７００は、事業者ＩＤ７７０１、銘柄ＩＤ７７０２、メーカＩＤ７７０３、販売エリアＩＤ７７０４、独占販売権の有無７７０５、ＰＲ優先権の有無７７０６、登録日時７７０７、更新日時７７０８、更新者ＩＤ７７０９等のフィールドを有する。
事業者・銘柄関係テーブル７７００は、事業者ＩＤ７７０１、銘柄ＩＤ７７０２、メーカＩＤ７７０３、販売エリアＩＤ７７０４、独占販売権の有無７７０５、ＰＲ優先権の有無７７０６、登録日時７７０７、更新日時７７０８、更新者ＩＤ７７０９等のフィールドを有する。
【0321】
これらのフィールドのうち、事業者ＩＤ７７０１には、売り手事業者ＩＤが格納される。
メーカＩＤ７７０３には、該当銘柄の造り手事業者ＩＤが格納される。
販売エリアＩＤ７７０４には、売り手が該当銘柄を販売するエリアのＩＤが格納される。
独占販売権の有無７７０５には、該当エリアにおいて該当銘柄の独占販売権を有するか否かを示す値が格納される。
メーカＩＤ７７０３には、該当銘柄の造り手事業者ＩＤが格納される。
販売エリアＩＤ７７０４には、売り手が該当銘柄を販売するエリアのＩＤが格納される。
独占販売権の有無７７０５には、該当エリアにおいて該当銘柄の独占販売権を有するか否かを示す値が格納される。
【0322】
ＰＲ優先権の有無７７０６には、売り手が独占販売権を有する場合、該当エリアにおいてＰＲコンテンツを造り手のコンテンツよりも優先するか否かを示す値が格納される。
登録日時７７０７には、当該レコードが登録された日時を示す値が格納される。
更新日時７７０８には、当該レコードが更新された日時を示す値が格納される。
更新者ＩＤ７７０９には、当該レコードの情報を更新した事業者ＩＤが格納される。なお、販売エリアＩＤ、独占優先権およびＰＲ優先権は、造り手により更新された場合、売り手は更新することができない。
登録日時７７０７には、当該レコードが登録された日時を示す値が格納される。
更新日時７７０８には、当該レコードが更新された日時を示す値が格納される。
更新者ＩＤ７７０９には、当該レコードの情報を更新した事業者ＩＤが格納される。なお、販売エリアＩＤ、独占優先権およびＰＲ優先権は、造り手により更新された場合、売り手は更新することができない。
【0323】
次に、事業者・銘柄関係テーブル７７００の登録／変更条件について説明する。
このテーブルの各レコードは、事業者商品テーブル３１００を銘柄ＩＤで日次集計することで追加されるか、または、事業者ＤＤ６３０を使用する売り手または造り手により銘柄ごとに追加される。
このテーブルの各レコードは、事業者商品テーブル３１００を銘柄ＩＤで日次集計することで追加されるか、または、事業者ＤＤ６３０を使用する売り手または造り手により銘柄ごとに追加される。
【0324】
販売エリアＩＤ、独占販売権およびＰＲ優先権は、売り手が登録できる。ただし、同一エリアで複数の売り手は独占販売権を登録できない。そのような登録の試みに対してはエラーが出力される。万一エラーが発生した場合には、当事者間で解決してもらうことになる。
また、造り手が上書き変更できて、造り手が更新した後は、売り手は販売エリアＩＤ、独占優先権、ＰＲ優先権を更新できなくなる。
また、造り手が上書き変更できて、造り手が更新した後は、売り手は販売エリアＩＤ、独占優先権、ＰＲ優先権を更新できなくなる。
【0325】
以上説明した事業者・銘柄関係テーブル７７００は、商品情報管理サーバ６１０の補助記憶装置７０２に記憶される。当該テーブルは、上述した銘柄訴求情報の登録処理４６００において登録情報管理モジュール７１４により参照される。
登録情報管理モジュール７１４は、当該テーブルを参照して、事業者ＤＤ６３０を使用する事業者が対象銘柄の商品関連情報の登録権を有する場合には当該情報を管理し、当該事業者が当該登録権を有しない場合には当該情報を管理しない。
登録情報管理モジュール７１４は、当該テーブルを参照して、事業者ＤＤ６３０を使用する事業者が対象銘柄の商品関連情報の登録権を有する場合には当該情報を管理し、当該事業者が当該登録権を有しない場合には当該情報を管理しない。
【0326】
また事業者・銘柄関係テーブル７７００は、上述した銘柄パーツ表示処理５２００において銘柄パーツ情報提供モジュール７１６により参照される。
銘柄パーツ情報提供モジュール７１６は、消費者ＤＤ６２０において、商品パーツを表示するためのコードが組み込まれた画面が表示される場合に、対象銘柄の商品関連情報を当該消費者ＤＤ６２０に送信する。
銘柄パーツ情報提供モジュール７１６は、消費者ＤＤ６２０において、商品パーツを表示するためのコードが組み込まれた画面が表示される場合に、対象銘柄の商品関連情報を当該消費者ＤＤ６２０に送信する。
【0327】
その際、当該モジュールは、その商品関連情報を登録した事業者（具体的には、造り手代理）と予め対応付けられているエリアに当該消費者ＤＤ６２０が存在する場合に、その商品関連情報を当該消費者ＤＤ６２０に送信する。
加えて当該モジュールは、その商品関連情報を登録した事業者（具体的には、造り手代理）が、同様の情報を登録した事業者（具体的には、造り手）に対して優先権を有する場合に、その商品関連情報を当該消費者ＤＤ６２０に送信する。
消費者ＤＤ６２０の銘柄パーツ表示モジュール８１３は、商品情報管理サーバ６１０から送信された商品関連情報を取得して表示する。
加えて当該モジュールは、その商品関連情報を登録した事業者（具体的には、造り手代理）が、同様の情報を登録した事業者（具体的には、造り手）に対して優先権を有する場合に、その商品関連情報を当該消費者ＤＤ６２０に送信する。
消費者ＤＤ６２０の銘柄パーツ表示モジュール８１３は、商品情報管理サーバ６１０から送信された商品関連情報を取得して表示する。
【0328】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【0329】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【0330】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
なお、上述の実施例は少なくとも特許請求の範囲に記載の構成を開示している。
なお、上述の実施例は少なくとも特許請求の範囲に記載の構成を開示している。
【符号の説明】
【0331】
６００…商品情報管理システム、６１０…商品情報管理サーバ、６２０…消費者ＤＤ、６３０…事業者ＤＤ、６４０…事業者サーバ、７１１…認証モジュール、７１２…データ連携モジュール、７１３…組込タグ管理モジュール、７１４…登録情報管理モジュール、７１５…意向／履歴管理モジュール、７１６…銘柄パーツ情報提供モジュール、７１７…マップ情報提供モジュール、７１８…ＥＣ情報提供モジュール、７１９…商品情報提供モジュール、７２０…銘柄提案モジュール、７２１…リワードプログラム管理モジュール、７２２…リワード管理モジュール、７２３…プログラム管理モジュール、７２４…商品選定モジュール、７２５…投稿管理モジュール、７２６…評価管理モジュール、７２７…モデル生成モジュール、７２８…補正モジュール、７２９…嗜好推定モジュール、７４１…トランザクションＤＢ、７４２…解析データＤＢ、７４３…マスタＤＢ、７４４…設定ＤＢ、７４５…要素ＤＢ、７４６…関係ＤＢ、８１１…認証モジュール、８１２…意向／履歴登録モジュール、８１３…銘柄パーツ表示モジュール、８１４…マップ表示モジュール、８１５…ＥＣリスト表示モジュール、８１６…商品通知モジュール、８１７…提案銘柄通知モジュール、８１８…リワード利用モジュール、８１９…投稿モジュール、８２０…評価送信モジュール、８２１…表示モジュール、８３１…消費者ＤＤデータ、９１１…認証モジュール、９１２…組込タグ設定モジュール、９１３…情報登録モジュール、９１４…コード表示モジュール、９１５…リワードプログラム登録モジュール、９１６…プログラム登録モジュール、９２１…事業者ＤＤデータ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45】
【図46】
【図47】
【図48】
【図49】
【図50】
【図51】
【図52】
【図53】
【図54】
【図55】
【図56】
【図57】
【図58】
【図59】
【図60】
【図61】
【図62】
【図63】
【図64】
【図65】
【図66】
【図67】
【図68】
【図69】
【図70】
【図71】
【図72】
【図73】
【図74】
【図75】
【図76】
【図77】
【図78】