(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023060800
(43)【公開日】2023-04-28
(54)【発明の名称】販売支援システム
(51)【国際特許分類】
G06Q 30/0601 20230101AFI20230421BHJP
【FI】
G06Q30/06 300
【審査請求】未請求
【請求項の数】12
【出願形態】OL
(21)【出願番号】P 2022046116
(22)【出願日】2022-03-22
(31)【優先権主張番号】P 2021196552
(32)【優先日】2021-12-02
(33)【優先権主張国・地域又は機関】JP
(31)【優先権主張番号】P 2021170573
(32)【優先日】2021-10-18
(33)【優先権主張国・地域又は機関】JP
(71)【出願人】
【識別番号】508071881
【氏名又は名称】株式会社ダハ
(74)【代理人】
【識別番号】100105201
【弁理士】
【氏名又は名称】椎名 正利
(72)【発明者】
【氏名】露崎 美恵子
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049BB22
(57)【要約】
【課題】ネット上での取り扱いの商品や役務の件数を充実させ、売上の増大を図ることが可能で、かつ、販売形態の追加、刷新、多様化や工程管理を簡単に図れる販売支援システムを提供する。
【解決手段】センターサーバーで保存された商品データについて、所定の処理を開始するためのソースコードを生成するコード生成手段と、コード生成手段で生成されたソースコードをセンターサーバーに保存されている商品データの所定の箇所に対して埋め込む埋め込み手段と、埋め込み手段でソースコードを埋め込んだ商品データを、センターサーバーよりショップに対して提供する商品データ提供手段と、商品データ提供手段で提供された商品データを基に、webページをショップサーバーが作成するwebページ作成手段と、webページ作成手段で作成されたwebページにおいて、ユーザにより所定の処理の開始が要求されることで、所定の処理が行なわれる。
【選択図】
図28
【特許請求の範囲】
【請求項1】
ショップの商品データが保存され、該商品データのwebページが生成されるショップサーバーと、
前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、
該商品データ収集手段により集められた商品データを保存するセンターサーバーと、
該センターサーバーで保存された前記商品データについて、所定の処理を開始するためのソースコードを生成するコード生成手段と、
該コード生成手段で生成されたソースコードを前記センターサーバーに保存されている商品データの所定の箇所に対して埋め込む埋め込み手段と、
該埋め込み手段で前記ソースコードを埋め込んだ商品データを、前記センターサーバーより前記ショップに対して提供する商品データ提供手段と、
該商品データ提供手段で提供された前記商品データを基に、前記webページを前記ショップサーバーが作成するwebページ作成手段と、
該webページ作成手段で作成された前記webページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする販売支援システム。
【請求項2】
ショップの商品データが保存され、該商品データのwebページが生成されるショップサーバーと、
前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、
該商品データ収集手段により集められた商品データを保存するセンターサーバーと、
前記商品データについて所定の処理を開始するためのソースコードを前記ショップサーバーが前記商品データのwebページの所定の箇所のソースコードに対して差し替える、若しくは前記商品データのwebページの所定の箇所に埋め込む差替え等手段と、
該差替え等手段で前記ソースコードの差し替え等のされた前記webページを前記ショップサーバーが作成するwebページ作成手段と、
該webページ作成手段で作成された前記webページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする販売支援システム。
【請求項3】
ショップの商品データが掲載されたwebページを保存し、該webページをインターネットを介してユーザの閲覧に供するショップサーバーと、
前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、
該商品データ収集手段により集められた商品データを保存するセンターサーバーと、
前記webページに埋め込まれ、所定の処理を開始するためのリンクを生成するソースコードと、
前記リンクのリンク先であり、前記商品データの少なくとも一つを掲載したwebページを前記センターサーバーが作成するwebページ作成手段と、
該webページ作成手段で作成された前記webページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする販売支援システム。
【請求項4】
前記ショップが、商品データの提供元である少なくとも一つの提供元ショップと、該商品データの提供先である提供先ショップとで構成され、
前記提供元ショップから提供された商品データと前記提供先ショップの商品データを基に前記webページ作成手段で前記webページが作成されることを特徴とする請求項1~3のいずれか一項に記載の販売支援システム。
【請求項5】
前記ショップの前記商品データ中の所定の箇所若しくは前記ソースコードを介して生成された画面に、前記センターサーバーが前記ショップのショップ名、コメント文、検索入力欄、検索ボタン、パンくずリスト、リンクボタン、販売店リスト、言語の選択ボックス及び所定の言語の翻訳文のいずれか少なくとも一つを埋め込む処理を行うことを特徴とする請求項1~4のいずれか一項に記載の販売支援システム。
【請求項6】
前記センターサーバーに用意された管理画面と、
該管理画面において、前記ショップがユーザに対して問い合わせを行うために必要な仕様データを各ショップ毎に予め設定する仕様データ設定手段と、
該仕様データ設定手段で設定された前記仕様データに基づき、ユーザに対しての問い合わせを含むページを生成する問い合わせ生成手段と、
該問い合わせ生成手段で生成された前記ページが、前記所定の処理を行うプログラムにおいて前記ユーザに対して表示される問い合わせ表示手段と、
該問い合わせ表示手段で表示された前記ページの前記問い合わせに対する前記ユーザの返答結果が前記センターサーバーに保存される返答結果保存手段を備えたことを特徴とする請求項1~5のいずれか一項に記載の販売支援システム。
【請求項7】
前記センターサーバーに用意された管理画面と、
該管理画面において、前記ショップが前記商品データの工程管理を行うために必要な仕様データを各ショップ毎に予め設定する仕様データ設定手段と、
該仕様データ設定手段で設定された前記仕様データに基づき、前記ショップに対しての商品の製作順序、商品の製作時間、商品の製作完了及び商品の配達の少なくともいずれか一つを含む工程を管理するページを生成する工程管理生成手段と、
該工程管理生成手段で生成された前記ページが、前記ショップに対して表示される表示手段を備えたことを特徴とする請求項1~6のいずれか一項に記載の販売支援システム。
【請求項8】
前記所定の処理を行うプログラムにより、前記webページに掲載されている原文が複数のブロックに分離され、該ブロック毎に前記原文と該原文に対する翻訳文とが並べてユーザに対し表示されることを特徴とする請求項1~7のいずれか一項に記載の販売支援システム。
【請求項9】
年齢、性別、趣味嗜好、業種、用途の少なくともいずれか一つの属性を含む複数の購入者の購入情報を基に、商品毎に属性別の購入度合いがまとめられた基本属性と、
ショップでユーザにより購入された複数の商品と、
該複数の商品について前記ショップでの購入の情報又は前記基本属性を基に属性別にまとめられた購入属性と、
該購入属性を基にユーザによる購入需要の大小を判定する判定手段を備えたことを特徴とする販売支援システム。
【請求項10】
前記判定手段で前記購入需要が大きいと判断された属性について前記基本属性を基に同じ属性を有する商品データの追加、若しくは仕入れを判断、又は、前記ショップのサイトに他店の商品データを販売のために掲載することを特徴とする請求項9記載の販売支援システム。
【請求項11】
前記判定手段で前記購入需要が小さいと判断されたとき、前記ショップの商品データを他店の通販サイトに販売のため掲載することを特徴とする請求項9又は請求項10記載の販売支援システム。
【請求項12】
年齢、性別、趣味嗜好、業種、用途の少なくともいずれか一つの属性を含む複数の購入者の購入情報を基に、商品毎に属性別の購入度合いがまとめられた基本属性と、
ショップで取り扱われている複数の商品データを収集する商品データ収集手段と、
前記複数の商品データについて前記基本属性を基にまとめた販売属性と、
前記ショップでユーザにより購入された複数の商品と、
該複数の商品について前記ショップでの購入の情報又は前記基本属性を基に属性別にまとめられた購入属性と、
前記販売属性と前記購入属性とを前記属性について対比する対比手段とを備えたことを特徴とする販売支援システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は販売支援システムに係わり、特にネット上での取り扱いの商品や役務の件数を充実させ、売上の増大を図ることが可能で、かつ、販売形態の追加、刷新、多様化や工程管理等を簡単に図れる販売支援システムに関する。
【背景技術】
【0002】
従来、ショップはユーザの便宜を図るために、また、受注の機会を逃さないために、出来るだけ在庫切れが生じさせないようにする必要があった。このため、一定量の在庫を常に保有したり、また、効率の良い在庫管理を行うために需要の予測を行ったり等の工夫をしている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、在庫を常に確保するには費用もかかり、在庫管理も煩雑であった。
また、商品や役務を扱う販売事業者がユーザの商品探しや役務探しに対し便宜を十分に図ったり、売上を延ばすためには、一つの方策として取り扱う商品や役務の件数を増大させ販売可能な商品や役務を充実させることが望まれる。
こうすることで商品や役務の購入や予約、デリバリー、テイクアウト、カタログ請求等の頻度が増えるし、リピータの確保にも繋がり易くなると考えられる。
しかし、各販売事業者には取り扱う商品や役務の件数に限界があるし、商品や役務の件数を充実させるには費用もかかり、在庫管理の負担や倉庫費用等も急激に増えるおそれがある。
また、現在稼働中のお店をそのままの形で他の販売事業者参加型のモールや相互販売ができるように変えることができれば、在庫管理の負担無く取り扱う商品や役務の件数を充実できる。しかしながら、稼働中のお店の販売システムをモール化や相互販売の実現のために大幅に改造する必要が生ずる。更に、ホームページに掲載する際にも同種類の商品や役務等でまとめたり、ジャンル構成や一覧リストの統一化を図ったり等技術的にも解決しなければならない課題は多い。
更に、各販売事業者にとって現在行っている事業形態よりも、ネット上で商品購入、予約、デリバリー、テイクアウト、クーポン適用、カタログ請求、ライブコマース、価格比較等の販売の形態を拡げたり刷新したり、外国人にも販売をしたい等の多様化を図りたい場合がある。また、商品や役務の製作や配達に関する工程を管理したい場合がある。この場合、各販売事業者にとってシステム構築や改造等の負担のかかるおそれがあった。これらの販売作業を行う人的負担も十分に避けない場合もあった。
更に、上記したモール化、相互販売、多様化を図る場合に、どのようにすれば効率的であるかが判断できることが望ましい。また、このモール化等の導入をしたショップにとって、どの程度効果があり売上増に繋がるのかが予測できたり、提案できることが望ましい。更に、新規追加商品の仕入れについても効率的な判断や提案のできることが望ましい。
【0005】
本発明はこのような従来の課題に鑑みてなされたもので、ネット上での取り扱いの商品や役務の件数を充実させ、売上の増大を図ることが可能で、かつ、販売形態の追加、刷新、多様化や工程管理等を簡単に図れる販売支援システムを提供することを目的とする。
【課題を解決するための手段】
【0006】
このため本発明(請求項1)は、ショップの商品データが保存され、該商品データのwebページが生成されるショップサーバーと、前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、該商品データ収集手段により集められた商品データを保存するセンターサーバーと、該センターサーバーで保存された前記商品データについて、所定の処理を開始するためのソースコードを生成するコード生成手段と、該コード生成手段で生成されたソースコードを前記センターサーバーに保存されている商品データの所定の箇所に対して埋め込む埋め込み手段と、該埋め込み手段で前記ソースコードを埋め込んだ商品データを、前記センターサーバーより前記ショップに対して提供する商品データ提供手段と、該商品データ提供手段で提供された前記商品データを基に、前記webページを前記ショップサーバーが作成するwebページ作成手段と、該webページ作成手段で作成された前記webページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする。
【0007】
商品データ収集手段により集められた商品データに対して、センターサーバーでは、所定の処理を開始するためのソースコードを生成する。そして、この生成されたソースコードをセンターサーバーに保存されている商品データの所定の箇所に対して埋め込む。ショップサーバーでは、センターサーバーより提供されたこの商品データを基に、webページを作成する。
このことにより、ショップではwebページに対して所定の処理を行うことが簡単にでき、若しくは所定の処理を改造無く組み込める。
【0008】
また、本発明(請求項2)は、ショップの商品データが保存され、該商品データのwebページが生成されるショップサーバーと、前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、該商品データ収集手段により集められた商品データを保存するセンターサーバーと、前記商品データについて所定の処理を開始するためのソースコードを前記ショップサーバーが前記商品データのwebページの所定の箇所のソースコードに対して差し替える、若しくは前記商品データのwebページの所定の箇所に埋め込む差替え等手段と、該差替え等手段で前記ソースコードの差し替え等のされた前記webページを前記ショップサーバーが作成するwebページ作成手段と、該webページ作成手段で作成された前記webページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする。
【0009】
商品データについて所定の処理を開始するためのソースコードを、ショップサーバーが商品データのwebページの所定の箇所のソースコードに対して差し替える、若しくは商品データのwebページの所定の箇所に埋め込む。そして、ソースコードの差し替え等のされたwebページをショップサーバーが作成する。
このことにより、ショップではwebページに対して所定の処理を簡単に組み込める。
【0010】
更に、本発明(請求項3)は、ショップの商品データが掲載されたwebページを保存し、該webページをインターネットを介してユーザの閲覧に供するショップサーバーと、前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、該商品データ収集手段により集められた商品データを保存するセンターサーバーと、前記webページに埋め込まれ、所定の処理を開始するためのリンクを生成するソースコードと、前記リンクのリンク先であり、前記商品データの少なくとも一つを掲載したwebページを前記センターサーバーが作成するwebページ作成手段と、該webページ作成手段で作成された前記webページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする。
【0011】
これにより、webページ中に所定の処理を行うためのボタンやアンカーテキスト等が配設されていない場合であっても、所定の処理を簡単に導入ができる。商品データの更新も簡単である。
【0012】
更に、本発明(請求項4)は、前記ショップが、商品データの提供元である少なくとも一つの提供元ショップと、該商品データの提供先である提供先ショップとで構成され、前記提供元ショップから提供された商品データと前記提供先ショップの商品データを基に前記webページ作成手段で前記webページが作成されることを特徴とする。
【0013】
提供先ショップでは提供元ショップから提供された商品データをセンターサーバーを介して取り扱える。このため、提供先ショップにおける取り扱い商品点数が増加し、ショップはモール化や相互販売、提携販売が簡単に実現できる。そして、提供先ショップと提供元ショップの商品データを基に、webページを作成することができる。このため、提供先ショップの商品データのみならず、提供元ショップから提供された商品データについても簡単に所定の処理を行うプログラムが組み込める。
【0014】
更に、本発明(請求項5)は、前記ショップの前記商品データ中の所定の箇所若しくは前記ソースコードを介して生成された画面に、前記センターサーバーが前記ショップのショップ名、コメント文、検索入力欄、検索ボタン、パンくずリスト、リンクボタン、販売店リスト、言語の選択ボックス及び所定の言語の翻訳文のいずれか少なくとも一つを埋め込む処理を行うことを特徴とする。
【0015】
ショップの商品データ中の所定の箇所、若しくはソースコードを介して生成された画面に、センターサーバーがショップのショップ名、コメント文、検索入力欄、検索ボタン、パンくずリスト、リンクボタン、販売店リスト、言語の選択ボックスや所定の言語の翻訳文を埋め込むことで、ショップ側での改造の負担が無くショップや商品に関する情報等を追加できる。また、ショップにおいて、他のショップの商品が取り扱われる場合には、ユーザがこれらの情報を基にこの他のショップの商品を認識できたり、この他のショップを配達元として確認できる。
ショップの商品データ中の所定の箇所に販売店リストを埋め込んだ場合には、ショップ側での改造の負担が無く、この販売店リスト中に記載のショップについても所定の処理を行うプログラムが簡単に組み込める。また、ショップは改造無く簡単に所定の処理を行うプログラムが組み込める。
【0016】
更に、本発明(請求項6)は、前記センターサーバーに用意された管理画面と、該管理画面において、前記ショップがユーザに対して問い合わせを行うために必要な仕様データを各ショップ毎に予め設定する仕様データ設定手段と、該仕様データ設定手段で設定された前記仕様データに基づき、ユーザに対しての問い合わせを含むページを生成する問い合わせ生成手段と、該問い合わせ生成手段で生成された前記ページが、前記所定の処理を行うプログラムにおいて前記ユーザに対して表示される問い合わせ表示手段と、該問い合わせ表示手段で表示された前記ページの前記問い合わせに対する前記ユーザの返答結果が前記センターサーバーに保存される返答結果保存手段を備えて構成した。
【0017】
ショップが販売、予約、デリバリー、資料請求等の処理の過程において、ユーザに対して問い合わせを行うために必要な仕様データを各ショップ毎に管理画面で予め設定する。これにより、ショップは自店の独自の仕様を他店の仕様、若しくはセンターサーバーの仕様に合わせることなく維持できる。提供先ショップに対し提供元ショップが参加するモール化、相互販売、提携販売を行った場合には、各店それぞれに販売、予約、デリバリー、資料請求等の処理に独自の仕様があることが想定されるが、このような場合であっても各店が独自の仕様を維持しつつ参加できる。
【0018】
更に、本発明(請求項7)は、前記センターサーバーに用意された管理画面と、該管理画面において、前記ショップが前記商品データの工程管理を行うために必要な仕様データを各ショップ毎に予め設定する仕様データ設定手段と、該仕様データ設定手段で設定された前記仕様データに基づき、前記ショップに対しての商品の製作順序、商品の製作時間、商品の製作完了及び商品の配達の少なくともいずれか一つを含む工程を管理するページを生成する工程管理生成手段と、該工程管理生成手段で生成された前記ページが、前記ショップに対して表示される表示手段を備えて構成した。
【0019】
このことにより、ショップは所定の処理が簡単に行えるようになる上に、商品の工程管理も簡単に行えるようになる。表示手段で表示されたページに対する応答結果を保存すれば、調整や解析用に使えたり、商品の注文状況が分かるので売上の管理にも使える。
【0020】
更に、本発明(請求項8)は、前記所定の処理を行うプログラムにより、前記webページに掲載されている原文が複数のブロックに分離され、該ブロック毎に前記原文と該原文に対する翻訳文とが並べてユーザに対し表示されることを特徴とする。
【0021】
ブロック毎に原文と翻訳文とが対訳とされることでユーザは見易く、情報に対する判断を的確に行うことができる。
更に、本発明は、複数のショップについてその保有する商品を保存するデータベースと、該データベースに保存された前記ショップの商品を同じ種類の商品毎にまとめるまとめ手段と、該まとめ手段でまとめた前記ショップの商品を販売店リストとしてwebページに生成するwebページ生成手段と、前記webページ若しくは前記販売店リスト中に配設された外国人購入用のリンクとを備え、該リンクのユーザによるクリックに基づき外国人購入用の処理が動作することを特徴とする。
【0022】
更に、本発明(請求項9)は、年齢、性別、趣味嗜好、業種、用途の少なくともいずれか一つの属性を含む複数の購入者の購入情報を基に、商品毎に属性別の購入度合いがまとめられた基本属性と、ショップでユーザにより購入された複数の商品と、該複数の商品について前記ショップでの購入の情報又は前記基本属性を基に属性別にまとめられた購入属性と、該購入属性を基にユーザによる購入需要の大小を判定する判定手段を備えて構成した。
【0023】
ショップでの購入の情報や基本属性を基に属性別に購入属性をまとめる。そして、この購入属性を基にユーザによる購入需要の大小を判定する。これにより、このショップにおける購入需要を属性別に評価できるようになる。このため、このショップの購入需要が大きい属性の場合には、この購入需要の大きさを活用して一層の販売の強化を図ったり、購入需要が小さい属性の場合には、購入需要の補強を図ることができ、ショップの売上増に繋げられる。
【0024】
更に、本発明(請求項10)は、前記判定手段で前記購入需要が大きいと判断された属性について前記基本属性を基に同じ属性を有する商品データの追加、若しくは仕入れを判断、又は、前記ショップのサイトに他店の商品データを販売のために掲載することを特徴とする。
【0025】
ショップの購入需要が大きいと判断された属性については、基本属性を基に同じ属性を有する商品データを追加したり、実際にその商品の仕入れを判断できる。また、ショップのサイトに他店の商品データを販売のために掲載することもできる。これにより、ショップの商品を充実でき、売上増に繋げることができる。
【0026】
更に、本発明(請求項11)は、前記判定手段で前記購入需要が小さいと判断されたとき、前記ショップの商品データを他店の通販サイトに販売のため掲載することを特徴とする。
【0027】
ショップの購入需要が小さいと判断された属性については、ショップの商品データを他店の通販サイトに販売のため掲載する。これにより、このショップでは、販売利益を得ることができ、売上増に繋げられる。
【0028】
更に、本発明(請求項12)は、年齢、性別、趣味嗜好、業種、用途の少なくともいずれか一つの属性を含む複数の購入者の購入情報を基に、商品毎に属性別の購入度合いがまとめられた基本属性と、ショップで取り扱われている複数の商品データを収集する商品データ収集手段と、前記複数の商品データについて前記基本属性を基にまとめた販売属性と、前記ショップでユーザにより購入された複数の商品と、該複数の商品について前記ショップでの購入の情報又は前記基本属性を基に属性別にまとめられた購入属性と、前記販売属性と前記購入属性とを前記属性について対比する対比手段とを備えて構成した。
【0029】
複数の商品データについて販売属性を基本属性を基にまとめる。一方、ショップでの購入の情報や基本属性を基に購入属性をまとめる。そして、この販売属性と購入属性とを属性について対比する。このように、ショップ毎に購入属性と販売属性をまとめ、対比等による評価をすることで、ショップの購入需要や販売面での弱点や強い点を図表化したり明確化することができる。商品の購入需要にマッチングした商品構成になっているかを簡単に判断できる。これにより、ショップの購入需要の強い面を活用して一層の販売の強化や商品の充実を図ったり、商品の購入需要と商品構成とがミスマッチングしていて、購入需要が弱い面については購入需要の補強をすることができ、売上増に繋げられる。
【発明の効果】
【0030】
以上説明したように本発明によれば、商品データ収集手段により集められた商品データに対して、センターサーバーでは、所定の処理を開始するためのソースコードを生成し、この生成されたソースコードをセンターサーバーに保存されている商品データの所定の箇所に対して埋め込むことで、ショップではwebページに対して所定の処理を行うプログラムが簡単に、若しくは改造無く組み込める。
【図面の簡単な説明】
【0031】
【
図4】提供先-提供元対応テーブルにおけるデータの関係性を示す図
【
図7】各提供元ショップの商品データの収集、更新、データ集合体の生成方法を示すフローチャート
【
図8】提供先ショップの商品データの収集、更新方法を示すフローチャート
【
図9】販売店リストを用意する処理方法を示すフローチャート
【
図11】提供元ショップの残りの商品から販売店リストを作成する方法を示すフローチャート
【
図12】提供先ショップのwebページで行われる検索の処理と一覧ページの処理方法を示すフローチャート
【
図14A】商品詳細ページの作成方法を示すフローチャート(その1)
【
図14B】商品詳細ページの作成方法を示すフローチャート(その2)
【
図14C】商品詳細ページの作成方法を示すフローチャート(その3)
【
図19A】商品詳細ページ作成の別方法を示すフローチャート(その1)
【
図19B】商品詳細ページ作成の別方法を示すフローチャート(その2)
【
図19C】商品詳細ページ作成の別方法を示すフローチャート(その3)
【
図20】提供先ショップと提供元ショップ間の関係を示す図
【
図21】提供先ショップの販売履歴データを示す概念図
【
図22】提供元ショップの販売履歴データを示す概念図
【
図23】提供元ショップが同時に提供先ショップにもなっている場合の販売履歴データを示す概念図
【
図24】ネットを介して資料請求する場合を示すフローチャート(その1)
【
図25】商品詳細ページの商品説明文中の適所に対し、資料請求ボタンのソースコードを埋め込む例
【
図26】ネットを介して資料請求する場合を示すフローチャート(その2)
【
図28】相互販売、提携販売、モール化で提供先ショップがデリバリー等の仕組みを導入した場合を示すフローチャート(その1)
【
図29】商品説明文にデリバリーボタンを配設した画面例
【
図31】デリバリー等の仕組みを導入した場合を示すフローチャート(その2)
【
図33】デリバリー等の仕組みのホームページ適用例
【
図34】事業種類コードにより分類されたデータベース例
【
図42】原文と翻訳文の対訳の掲載された外国人向けのwebページの例
【
図43】ショップの商品データを外国人が検索可能とした例
【
図44】ショップの既存のwebページから直接外国人が検索可能とした例
【
図46】分節や用語毎に分離され、ホームページ上に選択自在に表示された日本語の例
【
図47】販売店リストに海外ユーザ購入ボタンが表示された例
【
図53】ショップの特徴を提携により一層強化させた例
【発明を実施するための形態】
【0032】
以下、本発明の第1の実施形態について説明する。
図1に本販売支援システムのシステム構成図を示す。
図1において、インターネット10にはユーザの使用するパソコン3やスマートフォン5等の情報端末が接続されている。また、このインターネット10には、商品データの提供元となるショッピングモール、ショップ、メーカー等の通販サイトを運営する提供元ショップ2のサーバー4が接続されている。ここに、商品データには役務データを含み、通販サイトには役務提供等の事業者サイトを含んでもよい(以下、同旨)。役務提供等の事業者には例えば、レストラン、食堂、クリーニング店、花屋、お菓子屋、学習塾、ホテル等の各サービス業を含む。図中、提供元ショップ2-1、2-2、2-3と示しているのは提供元ショップ2が複数であることを示している。これらの提供元ショップ2は独自のwebサイトを運営しているが、必ずしもサイトを持たなくても良い。
【0033】
この提供元ショップ2のサーバー4から提供された商品データはインターネット10を介してセンターサーバー6で受信されるようになっている。また、センターサーバー6は、提供元ショップ2のwebサイトを巡回し、ホームページから所定の定義に基づき商品データを収集するようになっている。
そして、このセンターサーバー6では商品データについて所定の解析が行われるようになっている。その後、後述する商品毎の販売店リストを含む形や販売店リストを含まない個別の商品等の形で提供先となる提供先ショップ1のサーバー7に対しAPI(Application Programming Interface)やCSVファイル等でセンターサーバー6から商品データが提供されるようになっている。ここに、販売店リストは、例えば
図2に示すように同一の商品aを取り扱い販売しているショップをまとめたリストである。ここに、商品aには役務データを含み、また、ショップには役務を取り扱う事業者の営む店を含んでもよい(以下、同旨)。
提供先ショップ1はショッピングモールやショップ等の通販サイトを運営しており、提供先ショップ1独自のwebサイト9を有している。但し、webサイト9を有さずに新規に通販サイトを構築することも可能である。そして、提供先ショップ1のサーバー7は、センターサーバー6のAPIやCSVファイル等を通じて、販売店リストを含む商品データをダウンロードできるようになっている。但し、販売店リストを含まない個別の商品等の商品データのみがダウンロードされてもよい。ここに、提供先ショップ1は複数の提供元ショップ2の参加した通販モール化や、ショップ同士の間で互いの商品を販売する相互販売や、提携したショップ間の内の一方のみで商品を販売する提携販売が実現できるようになっている。
【0034】
センターサーバー6の構成図を
図3に示す。このセンターサーバー6には、演算を行う演算部11、表示・操作部13、外部とのインターネット10を介してデータ通信を行う通信部15に加え、商品データ収集・解析部20には巡回プログラム21及び商品データ解析プログラム23が構築されている。巡回プログラム21では提供元ショップ2や提供先ショップ1のwebページに掲載された商品データを定期的に巡回し、webページのhtmlソースコードから所定の定義に従い商品名、メーカー名、型式、価格、送料、仕様、商品説明、商品画像、商品詳細ページのURL、ジャンル名、JANコード等の商品データを収集するようになっている。
【0035】
なお、商品データ収集・解析部20において、この商品データは巡回による以外にもCSVファイルによる提供や手動でも登録が可能なようになっている。巡回方式を採用するのは、提供元ショップ2の人手間を省くことで便利にするためである。しかしながら、巡回を行わずにCSVファイルによる提供や手動での登録を行うようにしても良い。また、巡回を行いつつCSVファイルによる提供や手動での登録が行えるようにしても良い。データの更新時にのみ登録を行うようにしても良い。
【0036】
商品データ解析プログラム23では巡回プログラム21で収集した多数の商品データから、後述する所定のロジックにより同じ商品を取り扱うショップを一つの集合の販売店リストとしてまとめたり、販売店リストの生成されていない商品(以下、個別商品と言う)を抽出したりするものである。また、htmlソースコードを生成したり、商品説明文テキスト中に埋め込む処理等も行う。
ユーザ対応・管理プログラム25では、ユーザとの応対や、ユーザやショップの管理を自動で行うプログラムが搭載されている。このプログラムは、例えば、予約プログラム、注文プログラム、デリバリープログラム、カタログ請求プログラム、クーボン適用プログラム、現金還元プログラム、テイクアウトプログラム、価格交渉プログラム、外国人購入用プログラム等である。
【0037】
また、センターサーバー6のデータベース30には、複数の販売店リストを保存した販売店リストデータベース31、提供元ショップ2のショップ名、サイトURL、商品販売条件等を保存した提供元ショップデータベース33、提供先ショップ1のショップ名、サイトURL、商品販売条件等を保存した提供先ショップデータベース35、
図4に示すように、提供先ショップ1毎にいずれの提供元ショップ2が提携しているのかその関係を保存した提供先-提供元対応データベース37、提供元ショップ2が販売中の商品データを保存した提供元ショップ商品データベース39、提供先ショップ1が販売中の商品データを保存した提供先ショップ商品データベース41、提供元ショップ2若しくは提供先ショップ1が希望する場合にこれらのショップの販売履歴管理データをバックアップする販売履歴管理データベース43、提供元ショップ2の内で販売店リストの生成されていない個別商品を保存する個別商品データベース45、ユーザ対応・管理プログラム25で利用されるユーザ情報、管理情報を保存するユーザ対応・管理データベース47が備えられている。
【0038】
一方、提供元ショップ2のサーバー4は
図5に示すように、センターサーバー6を含むインターネット10での通信を行うための通信部55、元々本実施形態の適用以前より提供元ショップ2が行っていた通販システムの運用に必要な管理部57、顧客データベース59を備える。
【0039】
また、本実施形態ではデータベース60を備える。但し、データベース60は、元々提供元ショップ2が保有していたサーバーとは独立したサーバーとして構築されても良い。
このデータベース60には、提供元ショップ2が取り扱う商品の提供元ショップ2における販売履歴を管理する提供元ショップ販売履歴管理データベース61、提供元ショップ2が取り扱う商品の提供先ショップ1における販売履歴を管理する提供先ショップ販売履歴管理データベース63、提供元ショップ2が取り扱う商品を保存している提供元ショップ商品データベース65を備える。但し、このデータベース60の一部又はすべてはセンターサーバー6に保存されてもよい。
【0040】
また、提供先ショップ1のサーバー7は
図6に示すように、センターサーバー6を含むインターネット10での通信を行うための通信部75、元々本実施形態の適用以前より提供先ショップ1が行っていた通販システムの運用に必要な管理部77、顧客データベース81を備える。また、本実施形態ではwebページ作成部79とデータベース80を備える。但し、webページ作成部79とデータベース80は、元々提供先ショップ1が保有していたサーバーとは独立したサーバーとして構築されても良い。
なお、webページ作成部79には、図示しないが、商品詳細ページを作成する商品詳細ページ作成部と、一覧ページを作成する一覧ページ作成部と、検索結果リストを作成する検索結果リスト作成部を有する。
このデータベース80には、提供元ショップ2が取り扱う商品の提供先ショップ1における販売履歴を管理する提供元ショップ販売履歴管理データベース83、提供先ショップ1が取り扱う商品の提供先ショップ1における販売履歴を管理する提供先ショップ販売履歴管理データベース85、提供先ショップ1が取り扱う商品を保存している提供先ショップ商品データベース87、ダウンロードした各商品を保存する個別商品データベース89を備える。但し、このデータベース80の一部又はすべてはセンターサーバー6に保存されてもよい。
【0041】
次に、各提供元ショップ2の商品データを収集し、この商品データを更新し、データ集合体を生成する方法を
図7のフローチャートに基づき説明する。
図7のステップ1(図中S1と略す。以下同旨)では、巡回プログラム21が各提供元ショップ2のサイトに存在するwebページを巡回し、このwebページに掲載されている商品データを収集する。ステップ2では、巡回プログラム21は、収集した最新のデータで前回取得した商品データの商品名、価格、説明文、送料、商品購入により付与されるポイント、ジャンル名、メーカー名、仕様等を更新する。但し、例えば中古品のように特定のサイトにおいてユーザによる登録、更新、削除等が行われる商品については必ずしもこのように巡回によりデータの収集、更新をしなくても良い。
【0042】
ステップ3では、センターサーバー6は、ステップ2で更新のされた各提供元ショップ2の商品データを提供元商品データ集合体としてまとめて提供元ショップ商品データベース39に保存する。但し、提供元商品データ集合体としてまとめずに各提供元ショップ2毎に保存されても良い。
ステップ4ではこの処理を定期的に一定頻度で繰り返す。これにより、各提供元ショップ2の負担無く商品データを取得し更新等ができる。但し、この処理はCSVデータの提供によったり、あるいは、人の手による登録、更新、削除等で行われても良い。これらの混在で行われても良い。また、各提供元ショップ2が商品データを更新したときに、少なくとも1回の巡回や、更新をした商品データだけのデータ取得を指示するようにしてもよい。
【0043】
次に、提供先ショップ1の商品データを収集し、この商品データを更新する方法を
図8のフローチャートに基づき説明する。
図8のステップ5では、巡回プログラム21が提供先ショップ1のサイトに存在するwebページを巡回し、このwebページに掲載されている商品データを収集する。ステップ6では、巡回プログラム21は、収集した最新のデータで前回取得した商品データの商品名、価格、説明文、送料、ポイント、ジャンル名、メーカー名、仕様等をステップ2と同様に更新する。
【0044】
ステップ7では、センターサーバー6は、同一の商品について商品データの削除があったか否か、一旦削除のされた商品データについて復活があったか否かを判定する。商品データの削除は販売終了や在庫切れ等の場合に生ずる。一旦削除のされた商品であってもその後に再入荷があれば商品詳細ページの復活や入荷に伴う記載内容の変更が起こり得る。そして、ステップ8では、センターサーバー6が、この削除があった商品データについては削除があった旨を、また、復活があった商品データについては復活があった旨を提供先ショップ商品データベース41に保存する。このように削除があった旨や復活があった旨を保存するのは商品の重複掲載を停止するためである。
【0045】
ステップ9では、販売終了や在庫切れのあった商品等はデータベースから一旦削除することが望ましい。復活の場合のあることを想定するためである。そして、ステップ10ではこの処理を定期的に一定頻度で繰り返す。これにより、提供先ショップ1の負担無く商品データを取得し更新等ができる。但し、この処理はCSVデータの提供によったり、あるいは、人の手による登録、更新、削除等で行われても良い。これらの混在で行われても良い。また、提供先ショップ1が商品データを更新したときに少なくとも1回の巡回や、更新をした商品データだけのデータ取得を指示するようにしてもよい。
なお、提供元商品データ集合体にはこの提供先ショップ1の商品データを加えるようにしてもよい。
【0046】
次に、販売店リストを用意する処理方法について
図9のフローチャートに基づき説明する。
図9において、ステップ15で商品データ解析プログラム23の処理を開始し、この商品データ解析プログラム23はステップ17で提供元商品データ集合体を読む。そして、ステップ19で、商品データ解析プログラム23は提供先ショップデータベース35に保存されている提供先ショップ1について、提供先ショップ商品データベース41に保存されている商品データよりi番目の商品を読む。ステップ21では、商品データ解析プログラム23はこのi番目の商品に相当する提供元ショップ2の商品を提供元商品データ集合体より見つける。
【0047】
このときの解析は、例えば、商品データ解析プログラム23が巡回プログラム21で収集した多数の商品データから、同一商品にまとめるために用いる特徴を表す要素を抽出するようになっている。これは、各提供元ショップ2では同じ商品を販売していることが多くあり、この特徴を表す要素を使って同じ商品を一つの集合としてまとめるものである。
【0048】
ここに、要素とは、商品名については空白で仕切ったときのそれぞれの単語が該当する。メーカー名については株式会社等の名称を取り除いた単語が該当する。型式についてはその型式を示すテキスト自体が要素に該当する。仕様についてはそれぞれの仕様の項目に対応する内訳の仕様データが要素に該当する。商品説明については説明文中の名詞が要素に該当する。JANコードも要素に該当する。特徴を表す要素の例を
図10に示す。
【0049】
特徴を表す要素はそれぞれの商品に対応しており、少なくとも一つの要素で構成されている。この特徴を表す要素は手動にて設定するようにしても良いが、一部の要素を手動による設定とし、残りの要素を商品データの自動解析から得られるように、組み合わせた形で設定するようにしても良い。自動による場合、それぞれの商品の商品名や型式、仕様、数量(容量)を示す単位、メーカー名に対し共通する要素をもって特徴要素とすることが望ましい。また、AI(人口知能)が商品データを解析することで自動設定するようにしても良い。なお、特徴を表す要素は型式だけの要素やJANコードのみで構成することも可能である。
【0050】
また、商品画像を特徴要素に加えるようにしても良い。この場合には、例えば、商品画像を縦、横複数の画素データに分離する。この画素データをもって対比を行う。
商品データ解析プログラム23では商品毎に生成したこの商品の特徴を表す要素を各提供元ショップ2から収集した商品データに対し当て、その商品データの中からこれらの要素を有する商品を同一の商品として抽出するようになっている。ここで同一の商品として抽出された各提供元ショップ2の商品データは、それぞれの商品を販売している少なくとも一つのショップを含む販売店リストとしてまとめられ、販売店リストデータベース31に保存されるようになっている。特徴を表す要素を設定し難い商品データの場合には、同一の若しくは関連する商品データ同士を手動でまとめるようにしてもよい。このように手動で設定する商品データと自動で設定する商品データとを混在させてもよい。
【0051】
なお、この販売店リストに掲載されているショップ毎の価格を安い順に並べれば、それぞれの商品単位に価格比較ができる。この販売店リストに掲載されるショップは中古品を取り扱うショップや個人であっても良い。
ステップ23では、センターサーバー6により、このi番目の商品については既に販売店リストデータベース31に販売店リストが存在するか否かが判断される。そして、販売店リストが存在する場合にはステップ25に進み、センターサーバー6は、この存在する販売店リストに対し、ステップ21で見つかった提供元ショップ2の商品とこのi番目の商品(提供先ショップ1の商品)とを関連付ける。
【0052】
一方、ステップ23で販売店リストが存在しない場合にはステップ27に進み、センターサーバー6は、ステップ21で見つけた商品データをもって、新規の販売店リストとして販売店リストデータベース31に保存する。
ステップ29ではセンターサーバー6は、関連付けのされた商品を提供元ショップ2の商品データより削除する。個別商品を残すためである。但し、関連付けのされた商品と個別商品とが、提供先ショップ1の検索結果リストや一覧ページに重複して掲載されても良いとする場合には、ステップ29の処理は省略されても良い。ステップ31では、センターサーバー6により提供先ショップ1の商品データの残りがあるか否か判断され、残りがある限りセンターサーバー6はステップ19からの処理を繰り返す。
【0053】
そして、ステップ35では、センターサーバー6は販売店リストとして関連付けられなかった商品を個別商品として個別商品データベース45に保存する。以上の処理により、販売店リストが生成されると共に個別商品も生成される。なお、ここで生成された販売店リストに属する商品と個別商品のデータは前述した
図7、
図8の処理により常に更新される。
【0054】
次に、提供元ショップ2の残りの商品からも販売店リストを作成する方法について
図11のフローチャートに基づき説明する。
図11において、ステップ41ではセンターサーバー6が提供元ショップ2の残りの商品データを読む。ステップ43では、センターサーバー6は提供先ショップ1の商品であって、一旦削除後に提供先ショップ1側で復活した商品について、提供元ショップ2側の商品として掲載可能となっている場合にはこの販売店リスト付きの商品データや個別商品を削除する。販売店リストの2重登録を防ぐためである。但し、販売店リスト付きの商品データや個別商品が、提供先ショップ1の検索結果リストや一覧ページに重複して掲載されても良いとする場合には、ステップ43の処理は省略されても良い。ステップ45では、センターサーバー6は提供元ショップ商品データベース39に保存されている提供元ショップ2の商品データよりi番目の商品を読む。ステップ47で、センターサーバー6はこのi番目の商品に相当する提供元ショップ2の商品を提供元ショップ2の残りの商品データから見つける。ここでの処理はステップ21の商品解析方法と同様である。
【0055】
次に、ステップ49では、センターサーバー6により、このi番目の商品には既に販売店リストが存在するか否かが判断される。そして、販売店リストが存在する場合にはステップ51に進み、センターサーバー6はこの存在する販売店リストに対し、ステップ47で見つかった提供元ショップ2の商品を加える。一方、ステップ49で販売店リストが存在しないと判断された場合にはステップ53に進み、センターサーバー6はステップ47で見つけた商品データをもって、新規の販売店リストとして販売店リストデータベース31に保存する。
【0056】
ステップ55ではセンターサーバー6が関連付けのされた商品を提供元ショップ2の商品データより削除する。個別商品を残すためである。但し、関連付けのされた商品と個別商品とが、提供先ショップ1の検索結果リストや一覧ページに重複して掲載されても良いとする場合には、ステップ55の処理は省略されても良い。ステップ57ではセンターサーバー6により、提供元ショップ2の商品データの残りがあるか否か判断され、残りがある限りステップ45からの処理を繰り返す。そして、ステップ59では、センターサーバー6は販売店リストとして関連付けられなかった商品を個別商品として個別商品データベース45に保存する。
なお、この場合、後述するステップ101と同様に、提供先-提供元対応テーブル37より提供先ショップ1の提供先ショップidに対応する提供元ショップ2の提供元ショップidを読む。そして、個別商品は各提供先ショップ1毎に、その属する提供元ショップ2に該当する商品データを抽出し保存する。即ち、各提供先ショップ1毎の個別商品データベース45を作成するようにしても良い。
以上の処理により、
図9の処理が行われた後の提供元ショップ2の残りの商品データからも販売店リストが生成されると共に個別商品が生成される。なお、ここで生成された販売店リストに属する商品と個別商品は前述した
図7、
図8の処理によりデータは常に更新される。
なお、販売店リストを作成するに際しては、提供元商品データ集合体と提供先ショップ1の商品データとをまとめた形で一つの集合体を生成し、この集合体に対して上記のステップ19以降、若しくはステップ45以降と同様に商品単位に関連付けを行うことで販売店リストと個別商品とを生成するようにしてもよい。
【0057】
次に、提供先ショップ1のwebページで行われる検索の処理と一覧ページの処理方法とについて
図12のフローチャートに基づき説明する。
図12において、ステップ71では、提供先ショップ1のwebサイト9を訪れたユーザが検索を行う。この際には、提供先ショップ1のサーバー7は、ユーザによりwebページの検索入力欄に投入された検索キーワードについて、ステップ73で提供先ショップ1の顧客データベース81を検索する。この際の検索では、検索キーワードにジャンル名や仕様での検索項目が加えられても良い。
ここで、サーバー7は検索結果データと検索件数を一時保存する。この顧客データベース81は提供先ショップ1が元々保有していた商品のデータベースである。本実施形態を適用する以前には、この顧客データベース81だけの検索により検索結果リストをユーザに対し提供していたものである。なお、顧客データベース81はサーバー7には含めずに、提供先ショップ1が元々保有していた形のまま別個のサーバーに存在しても良い。既存の提供先ショップ1保有のサーバーの改造を出来るだけ避けそのまま利用するためである。
【0058】
一方、ステップ75では、サーバー7によりこの検索キーワードがセンターサーバー6に対し渡される。この際の検索では、検索キーワードにジャンル名や仕様での検索項目が加えられても良い。ステップ77では、センターサーバー6で受信されたこの検索キーワードについて、センターサーバー6により販売店リストデータベース31と個別商品データベース45に対して検索が行われる。そして、ステップ79で、センターサーバー6は、この検索キーワードに一致した商品の販売店リストと、販売店リストに関連付けられていない個別商品とを抽出する。
但し、個別商品データベース45が全提供先ショップ1についてまとめられたものである場合には、前述と同様に、提供先-提供元対応テーブル37より提供先ショップ1の提供先ショップidに対応する提供元ショップ2の提供元ショップidを読む。そして、個別商品は、この提供先ショップ1に属する提供元ショップ2に該当する商品データを抽出する。
ステップ81では、センターサーバー6はこれらの商品データと検索件数をAPIで提供する。このとき、商品データは検索結果リストの1ページに掲載される例えば20品分ずつ等を提供することが望ましい。送信時間の短縮とサーバー負荷の軽減のためである。これらの商品データには中古品を加えても良い。
【0059】
ステップ83では、提供先ショップ1のサーバー7がAPIにアクセスして商品データを受信する。ステップ85では、このサーバー7が、受信した商品データを提供先ショップ商品データベース87と個別商品データベース89に保存する。ステップ87では、サーバー7がwebページ作成部79においてこの商品データを基にwebページを作成する。但し、このとき商品データはステップ73で検索された結果の商品データと一緒にまとめられることが望ましい。検索件数もステップ73で検索された結果の件数とAPI経由の商品データの件数とで合計されることが望ましい。商品データの検索結果の並び順は提供先ショップ1の自由に行える。例えば、提供先ショップ1の商品データを先に出して、その後にAPI経由で受信した商品データを加えても良いし、あるいは、適宜所定の条件に従い混在する形で商品データを加えても良い。ステップ89では作成されたwebページが検索結果リストとしてユーザに対し提供される。このときの検索結果リストの概念図を
図13で説明する。
【0060】
図13において、例えば、従来の検索結果が1,000件であり、このときに掲載された商品1~商品5・・・は顧客データベース81だけの検索の結果である。これに対し、本実施形態では、例えば検索結果がAPI経由で受信した商品データを加えて2,000件となる。このときに加えられた商品データの内訳は、図中の商品10が、提供先ショップ1では商品取り扱いは無いものの、新しく生成された商品詳細ページで販売店リストを有する商品データである。また、商品11が提供先ショップ1では取り扱いは無いが、提供元ショップ2から提供された個別商品データを基に作成された商品詳細ページである。このように検索結果の件数を大幅に増加できる。従って、商品を漏れなく探したいと考えているユーザにとっては効率の良い検索が行える。更に、既存の商品1~商品5・・・の内の多くの商品の商品詳細ページには販売店リストが追加されている。
但し、図示しないが、ステップ73で検索された結果の商品データとAPI経由で受信した商品データとは一緒にせずに、API経由で受信した商品データは別枠や、商品詳細ページに掲載された商品の関連商品として表示されても良い。また、販売店リストが追加された商品だけを一緒にして、個別商品については別枠で表示する等されても良い。
なお、センターサーバー6において、提供先ショップ商品データベース41に保存されているデータ、個別商品データベース45に保存されているデータ、及び販売店リストデータベース31をまとめて検索キーワードで検索を行い、この検索結果のデータをAPI経由で提供先ショップ1に対し送信するようにしても良い。この場合には提供先ショップ1側での検索の負担は無くなる。
図12のフローチャートは検索結果ページの作成について説明したが、一覧ページの作成についても同様であるので詳しい説明は省略する。但し、一覧ページの作成の場合には、検索キーワードとして例えばジャンル名、若しくはジャンルコードで商品データの検索を行う。また、一覧ページの作成については、提供先ショップ1の商品の露出を優先させるため等の理由から、掲載可能な商品を一定数に制限し手動で選択されるようにしてもよい。
【0061】
提供先ショップ1の規模が小さい場合は検索結果の全商品データをAPIやCSVファイル等で提供しても良い。しかしながら、規模が大きい場合に、全商品データを受信して提供先ショップ商品データベース87に保存とすると通信負担も大きく、また、一覧ページの場合には商品データが古くなるおそれがある。そこで、検索結果や一覧ページの商品データを、提供先ショップ1から送信リクエストのあった都度、例えば1ページ単位(1ページ20品分等を掲載)に送信することが望ましい。この送信リクエストは例えば1ページ単位にされても良い。このように限定した商品数を提供することでリアルタイム性を確保でき通信負担も少なくできる。
以上により、提供先ショップ1では自店の元々保有しているサーバー設備をそのまま使うことが可能である。設備の変更は少なくて済む。仮に、提供先ショップ1側のデータベースの容量が小さくても大きな規模の商品データを扱える。検索の対象とする件数は、従来通り提供先ショップ1の元々保有している商品データのみなので検索の負荷も増えない。従って、既存のサーバー設備であっても検索速度をそのまま維持できる。また、センターサーバー6のデータベースが扱うデータ分についてはデータの更新を考える必要がない。
【0062】
なお、提供先ショップ1の顧客データベース81には、個別商品データベース45に保存されているデータ、及び販売店リストデータベース31に保存されているデータの内の提供先ショップ1に関連するデータを加えておくようにしてもよい。即ち、センターサーバー6より提供先ショップ1に対しCSVファイルやAPI等により商品データの提供を行う。この際には、提供先ショップ1の商品データと個別商品データベース45に保存されているデータ、及び販売店リストデータベース31に保存されているデータのすべてをセンターサーバー6側でまとめた上で提供してもよい。
但し、提供先ショップ1の商品データの一部又はすべて、例えば価格、在庫数、送料及びポイント等の内の少なくともいずれか一つの項目については提供先ショップ1側での管理を優先させるためにCSVファイルに含まないことも可能である。特に、価格及び在庫数の内の少なくともいずれか一つの項目については含めないことが望ましい。
あるいは、CSVファイルに含めていたとしてもインポートされる際にそのデータで提供先ショップ1の商品データが更新されないとしてもよい。
【0063】
また、後述するように、販売店リストはテキストである商品説明文中に、例えばhtmlソースコードの形式で埋め込みされた形で提供してもよい。
そして、提供先ショップ1のサーバー7が、ユーザによりwebページの検索入力欄に投入された検索キーワードについて、ステップ73で提供先ショップ1の顧客データベース81を検索するようにしてもよい。この場合には、ステップ75~ステップ89の処理は省略できる。このため、改造は不要にできる。一覧リストもこのCSVファイルやAPI等により提供された商品データを基に作成されてもよい。
なお、提供先ショップ1のサーバー設備は改造して使うのではなく、新規に提供先ショップ1のサーバー設備を設けるようにしてもよい。この場合には、センターサーバー6内に提供先ショップ1のwebサイトを設けるようにしてもよい。そして、このwebサイトでは提供先ショップ1の設定した独自ドメインを使うこともできる。
【0064】
次に、商品詳細ページの作成方法について
図14のフローチャートに基づき説明する。
図14において、ステップ91では、ユーザが提供先ショップ1のwebサイト9を訪問する。ステップ93では、ユーザが提供先ショップ1のwebサイト9で検索結果や一覧リスト等から商品aを一つ選びクリックする。このときの商品aは前述の通り提供先ショップ1の商品である場合と、提供元ショップ2の商品である場合とがある。ステップ95では、提供先ショップ1の提供先ショップidと、この商品aに相当する商品idとが提供先ショップ1のサーバー7によりデータベース80から抽出され、センターサーバー6に対し送信される。
【0065】
ステップ97では、センターサーバー6がこの受信した商品idに基づき販売店リストデータベース31の販売店リストテーブルを検索する。そして、ステップ99では、センターサーバー6がこの商品aの販売店リストが存在するか否かを判断する。ステップ99で商品aの販売店リストが存在すると判断された場合にはステップ101に進む。ステップ101では、センターサーバー6が、
図4に示す提供先-提供元対応テーブル37より提供先ショップ1の提供先ショップidに対応する提供元ショップ2の提供元ショップidを読む。そして、ステップ103では、センターサーバー6は、この商品aの販売店リストから提供元ショップ2に該当する商品データを抽出する。提供元ショップ2は複数のこともある。なお、提供元ショップ2がフリマのような場合には、提供元ショップ2の一店に対し、提供先ショップ1が複数関連付けされることもある。
但し、提供先-提供元対応テーブル37を設けずに、提供先ショップ1毎に独立したサーバー(若しくはデータベース)を設置する。そして、それぞれのサーバー毎に予め指定をした提供元ショップ2について、この商品aの販売店リストから提供元ショップ2に該当する商品データを抽出するようにしても良い。また、この指定をした提供元ショップ2についての商品データの抽出処理は、センターサーバー6では行わずに提供先ショップ1側のサーバー7で行うようにしても良い。若しくは、提供先-提供元対応テーブル37を設けずに、提供先ショップ1毎に提供元ショップ2のデータベースをまとめる。そして、このデータベースに対してこの商品aの販売店リストから提供元ショップ2に該当する商品データを抽出するようにしても良い。
【0066】
その後、ステップ105では、センターサーバー6は、予めセンターサーバー6に登録されている提供先ショップ1のデフォルトの並び順に従い商品データを整列する。このデフォルト順は例えば、価格の安い順、提供元ショップ2の商品名順、クリック数順、提供元ショップ2の評価順等であり、提供先ショップ1の任意若しくはセンターサーバー6の所定の判断条件により決められたものである。但し、この並び替えは提供先ショップ1のサーバー7側にて行われても良い。ステップ107では、センターサーバー6が、この商品データを販売店リスト存在符号と共にAPIで提供する。一方、ステップ99で商品aの販売店リストが存在しないと判断された場合にはステップ109に進む。そして、ステップ109では、センターサーバー6は販売店リスト不存在符号をAPIで提供する。
【0067】
ステップ111では、提供先ショップ1のサーバー7が通信部75を介してAPIにアクセスする。ステップ113ではサーバー7が販売店リスト存在符号を確認する。ステップ115で販売店リスト存在符号が存在した場合にはステップ117に進み、サーバー7がセンターサーバー6より商品データをAPIを介して受信する。このとき受信した商品データにはショップid等が含まれている。ショップidはセンターサーバー6により商品名に加える等されても良い。ショップid、商品コード、及びショップ名のいずれか少なくとも一つを加えても良い。このショップid等は提供元ショップ2の商品のみについて加えるようにしてもよい。商品コードには役務コードも含む(以下、同旨)
ステップ119では、サーバー7は、この商品aが提供先ショップ1に属する商品か否かを判断する。
【0068】
但し、この商品aが提供先ショップ1に属する商品か否かはセンターサーバー6側で判断を行うことも可能である。そして、提供先ショップ1に属する場合にはステップ121に進み、サーバー7は、この商品aの提供先ショップ1の商品データに整列済の販売店リストを加える。そして、ステップ125で、提供先ショップ1のサーバー7のwebページ作成部79がこの商品データを取り込み商品詳細ページを作成する。
【0069】
このときの商品詳細ページの概略図を
図15に示す。即ち、
図15において、商品詳細ページ100には、この提供先ショップ1が元々所有している商品aの商品画像、価格、商品説明文と購入ボタン101等がページの見易い中心部分に掲載され、この商品を販売する少なくとも一つの提供元ショップ2がこの商品の販売店リスト103として付記される。
この販売店リスト103には、提供元ショップ2のこの商品aの販売店名、販売価格、送料が掲載されるが、商品名、商品画像等が付記されても良い。また、販売店リスト103はリンク先で別ページとして掲載されても良い。このリンク先は別サイトであっても良い。更に、この販売店リスト103に掲載された提供元ショップ2をクリックしたときには、例えば、後述する
図18に示すようなこの提供元ショップ2の商品aの詳細説明文等を含む、より詳しい商品データが提供先ショップ1の商品詳細ページとして閲覧できるようにしてもよい。
そして、この提供元ショップ2の商品詳細ページには購入ボタン101が配設されてもよい。販売店リスト103に掲載された提供元ショップ2をクリックしたときにカートにリンクするとしてもよいが、この場合には改造が必要となる。上記のように提供先ショップ1の商品詳細ページにリンクとすることで改造は不要にできる。
【0070】
なお、この商品詳細ページは提供先ショップ1のサイトに掲載されるが、別サイトに構成することも可能である。但し、
図18に示すような形で商品詳細ページにショップ名を追加することがサーバー7の改造に繋がる場合には、このショップ名や、このショップ名を含むコメント文(例えば、「この商品はA店より配送」等)をセンターサーバー6側で商品名中や商品説明文の適所(例えば上部)に自動で追加記載することで、改造を回避するようにしてもよい。文字は目立つように強調・装飾されたり、括弧で囲われたりするのが望ましい。このとき、ショップid、商品コード、及びショップ名のいずれか少なくとも一つを加えるようにしても良い。このショップid等は提供元ショップ2の商品のみについて加えるようにしてもよい。
【0071】
なお、販売店リスト103のデータ、及び、提供先ショップ1が元々所有している商品aの商品画像へのリンクURL、価格、商品説明文等のテキストはAPIやCSVファイル等の形式でセンターサーバー6側で用意する。そして、提供先ショップ1のサーバー7側でこのデータを手動若しくは自動で読むようにしても良い。この際、この商品説明文テキストの適所(例えば下部)には、例えばhtmlソースコードの形式で記載された販売店リスト103のデータを含むようにしてもよい。このhtmlソースコードを商品説明文テキスト中に含む処理はセンターサーバー6側の演算部11で行われることが望ましい。この場合には、サーバー7でCSVファイル等を読むことで、特別な改造を行うことなく、商品説明文中に販売店リスト103を表示することができる。但し、提供先ショップ1側のwebページ作成プログラムが商品説明文を生成する際に、テキストのみの対応でhtmlソースコードに対応していない場合には、このwebページ作成プログラムをhtmlソースコードに対応可能とする改造を行うだけで済む。
【0072】
これにより、ユーザが探し求めた商品aの商品詳細ページに複数のショップが掲載されていることで、ユーザにとっては相場感も得易く購入され易い。販売店数が増加するため、いずれかのショップで購入される可能性が高くなる。在庫が無いために販売の機会を損失するおそれも少なくできる。
更に、ポイントの付与やカード決済等のこの提供先ショップ1が独自に行っているサービスを、この提供元ショップ2での商品購入にも適用することも可能であり、ユーザへのサービスの一層の充実を図ることができる。
【0073】
一方、ステップ119の判断で、この商品aが提供先ショップ1に属さない商品であると判断された場合には、ステップ123に進み、サーバー7は販売店リストに属するショップの内の一つを代表のショップとして抽出し、それに整列済の販売店リストを加える。そして、ステップ125で、提供先ショップ1のサーバー7のwebページ作成部79がこの商品データを取り込み商品詳細ページを作成する。このときの商品詳細ページの概略図を
図16に示す。
【0074】
即ち、
図16において、商品詳細ページ110にはこの提供先ショップ1が保有していないが、代表のショップとして抽出された提供元ショップ2が保有している商品aの商品画像、価格、商品説明文と購入ボタン101等がページの見易い中心部分に掲載される。そして、この商品を販売している提供元ショップ2のショップ名113が付記されている。この代表のショップとしての提供元ショップ2の選択方法は任意であるが、例えば安い順や販売実績の多い順等によりサーバー7若しくはセンターサーバー6により1店舗が選択される。
【0075】
更に、この商品aを販売する残りの少なくとも一つの提供元ショップ2がこの商品の販売店リスト115として付記される。ここに提供元ショップ2のこの商品aの販売店名、販売価格、送料が掲載されるが、商品名、商品画像等が付記されても良い。また、販売店リスト115はリンク先で別ページとして掲載されても良い。更に、この販売店リスト115に掲載された提供元ショップ2をクリックしたときには、例えば、後述する
図18に示すようなこの提供元ショップ2の商品aの詳細説明文等を含む、より詳しい商品データが提供先ショップ1の商品詳細ページとして閲覧できるようにしてもよい。そして、この提供元ショップ2の商品詳細ページには購入ボタン101が配設されてもよい。
この場合、元々この商品aの販売を提供先ショップ1ではしていなかったが、提供元ショップ2の商品データに基づき作成された商品詳細ページをもって販売することができる。従って、在庫が無くても商品の販売が可能となり、売上機会の増大に繋がる。また、作成された商品詳細ページは検索結果リストや一覧リストにも掲載可能であり、取り扱い可能な商品として充実させることができる。検索対象の商品点数が増えることでユーザによる商品検索の精度も向上する。
提供先ショップ1にとって、新規ジャンルを開拓する足掛かりとなり、本格的に参入する前にその効果を事前に予測することができる。
【0076】
提供先ショップ1で在庫が無い場合であってもユーザは販売店リスト115で購入ができる。従って、提供先ショップ1での在庫切れに伴う購入機会の損失を防ぐことができる。
提供先ショップ1にとっては在庫を常に確保する必要が少なくなり、在庫管理の負担も軽減する。
ステップ127では、リクエストのあったユーザの情報端末に対してこの商品aの商品詳細ページ100、110が表示される。
【0077】
一方、ステップ115で販売店リスト存在符号が見つからなかった場合にはステップ129に進み、サーバー7は販売店リスト不存在符号を確認する。そして、ステップ131では、サーバー7は、この商品aは提供先ショップ1に属する商品か否かを判断する。提供先ショップ1に属する商品の場合にはステップ133に進み、サーバー7は提供先ショップ1の商品aの商品詳細ページをユーザに表示する。
【0078】
このときの商品詳細ページの概略図を
図17に示す。即ち、
図17において、商品詳細ページ120にはこの提供先ショップ1が元々所有している商品aの商品画像、価格、商品説明文と購入ボタン101等がページの見易い中心部分に掲載されている。即ち、このページの構成はこの提供先ショップ1が本実施形態の適用前から元々実施しているものである。
ステップ131でこの商品aが提供先ショップ1に属さない商品だった場合には、ステップ135に進み、サーバー7がAPIを介してセンターサーバー6より個別商品データを受信する。個別商品データは、個別商品データベース45に保存されていた商品データである。
【0079】
ステップ137では、この受信をした提供元ショップ2の商品で商品詳細ページを作成する。
このときの商品詳細ページの概略図を
図18に示す。即ち、
図18において、商品詳細ページ130にはこの提供先ショップ1が保有していないが、提供元ショップ2が保有している商品aの商品画像、価格、商品説明文と購入ボタン101等がページの見易い中心部分に掲載される。そして、この商品を販売している提供元ショップ2のショップ名133が付記されている。
【0080】
この場合、元々この商品aの販売を提供先ショップ1ではしていなかったが、提供元ショップ2の個別商品データに基づき作成された商品詳細ページをもって販売することができる。従って、在庫が無くても商品の販売が可能となり、売上機会の増大に繋がる。リピータの確保にも繋がり易くなる。また、検索結果リストや一覧リストにも掲載可能であり、取り扱い可能な商品として充実させることができる。検索対象の商品点数が増えることでユーザによる商品検索の精度も向上する。
提供先ショップ1にとっては在庫を常に確保する必要が少なくなり、商品点数が増えても在庫管理の負担は軽減する。在庫切れの不安は軽減する。
なお、センターサーバー6側で、商品aが販売店リストがあるか否かを判断し、また、この商品aが提供先ショップ1に属する商品か否かを判断する。サーバー7では、その判断結果をAPIを介して読んだ上でその判断結果に基づき、
図15~
図18の各商品詳細ページを作成するようにしても良い。更に、センターサーバー6側で各商品詳細ページを作成しAPIで渡すようにしても良い。更に、サーバー7の機能はセンターサーバー6側に配設されてもよい。この場合、提供先ショップ1のwebサイトはセンターサーバー6に構築される。
【0081】
次に、商品詳細ページ作成の別方法について
図19のフローチャートに基づき説明する。なお、
図14と同一要素のものについては同一符号を付して説明は省略する。
図14までに説明をした商品詳細ページ作成の処理では、商品データ解析プログラム23が提供元ショップ商品データベース39に保存されている提供元商品データ集合体について解析を行うことで同一の商品を見つけることで販売店リストを生成する。その後、この販売店リストから提供先ショップ1に応じた提供元ショップ2に絞った形で商品詳細ページを作成した。
【0082】
これに対し、別方法では、提供先ショップ1に応じた提供元ショップ2の商品テーブルに対して解析を行うことで同一の商品を見つけ、その結果を論理加算した販売店リストで商品詳細ページを作成するものである。
図19において、ステップ91で、ユーザが提供先ショップ1のwebサイト9を訪問し、ステップ93で検索結果や一覧リスト等から商品aをクリックする。ステップ95では、提供先ショップidと、この商品aに相当する商品idとがセンターサーバー6に対し送信される。
【0083】
ステップ101では、センターサーバー6が、提供先-提供元対応テーブル37より提供先ショップ1の提供先ショップidに対応する提供元ショップ2の提供元ショップidを読む。そして、ステップ141では、センターサーバー6は、各提供元ショップ2のそれぞれの商品テーブルを読む。この商品テーブルに属する商品データは提供元ショップ商品データベース39に保存されており、巡回プログラム21等により常に更新されたデータである。但し、全提供元ショップ2の商品テーブルを読むようにしても良い。また、
図14において説明したように、提供先-提供元対応テーブル37を設けずに提供先ショップ1毎に独立したサーバー(若しくはデータベース)を設置する等しても良い。
【0084】
ステップ143では、商品データ解析プログラム23は、この商品テーブルの商品データを商品idに属する型式、JANコード、商品名、商品画像の内少なくとも一つにより絞る。このときの解析方法はステップ21での処理と同様である。ステップ145では、センターサーバー6は、抽出した結果をオアして販売店リストを作成する。そして、この作成した販売店リストを販売店リストデータベース31に保存する。なお、ステップ143で絞った結果が0件のこともあるが、このときには販売店リストは作成されない。
【0085】
ステップ99では、センターサーバー6がこの商品aの販売店リストが存在するか否かを判断する。ステップ99で商品aの販売店リストが存在すると判断された場合にはステップ105に進む。ステップ105では、センターサーバー6は、予めセンターサーバー6に登録されている提供先ショップ1のデフォルトの並び順に従い商品データを整列する。ステップ107では、センターサーバー6が、この商品データを販売店リスト存在符号と共にAPIで提供する。
【0086】
一方、ステップ99で商品aの販売店リストが存在しないと判断された場合にはステップ109に進む。そして、ステップ109では、センターサーバー6は販売店リスト不存在符号をAPIで提供する。ステップ111では、提供先ショップ1のサーバー7が通信部75を介してAPIにアクセスする。
ステップ113以後、
図14のフローチャートと同様の処理を行い、4つの態様の商品詳細ページを作成する。
なお、提供先ショップ1のwebページで行われる検索の処理で述べたように、センターサーバー6より提供先ショップ1に対し、提供先ショップ1の商品データと個別商品データベース45に保存されているデータ、及び販売店リストデータベース31に保存されているデータのすべてをセンターサーバー6側でまとめた上で、定期的にこれらのデータをCSVファイルに保存して提供したり、API等で提供を行うようにしてもよい。
【0087】
この場合、
(1)商品名中にショップid、商品コード、及びショップ名のいずれか少なくとも一つを記載する。従って、提供元ショップ2の商品であることが判断され易い。
(2)ショップ名を含むコメント文を商品名中や商品説明文中の適所に記載する。例えば、商品詳細ページが提供元ショップ2の商品のページである場合にはコメント文が挿入され、提供元ショップ2の商品で無い場合にはコメント文は挿入されない。
(3)商品説明文中の適所には、例えばhtmlソースコードの形式で記載された販売店リスト103のデータを含む。そして、例えば、販売店リスト103のデータが存在する場合にこのhtmlソースコードを商品説明文中に含み、存在しない場合にはこのhtmlソースコードを商品説明文中に含まない。
(1)~(3)の処理のいずれか少なくとも一つの処理を行った商品データを、CSVファイル若しくはAPI経由でセンターサーバー6側から提供先ショップ1に対し提供することが望ましい。
【0088】
但し、上記したショップidやコメント文、htmlソースコード等は、商品名や商品詳細ページに記載する以外にも型式欄、価格、送料、ポイント等の提供先ショップの通販サイトの商品詳細ページ中に掲載されるテキストデータに対し追記されるようにされてもよい。また、コメント文や販売店リスト103、ショップ名等は、画像欄等に画像化されたテキストデータとして表示されてもよい。
このことにより、提供先ショップ1で販売された商品をセンターサーバー6や提供元ショップ2で確実に特定できる。また、ユーザにとっては提供元ショップ2の商品であり、配送元が提供元ショップ2であることが理解され易い。更に、商品詳細ページで販売店リスト103を開示するのに特別なスペースを改めて設ける必要が無くなる。ショッピングカートも提供先ショップ1が元々備えているものをそのまま使える。(1)~(3)の処理により4つの態様の商品詳細ページにも対応できる。このため、提供先ショップ1では改造無く本システムを導入できる。但し、提供先ショップ1の商品データの一部又はすべて、例えば価格や在庫数等のリアルタイム性の高い項目については、提供先ショップ1側での管理を優先させるためにCSVファイルやAPIに含まないことも可能である。若しくは、かかる項目にはデータを記載せずに空欄としてもよい。また、これとは逆に、CSVファイルやAPIに含めるデータを商品詳細文と商品名等に限定するとして、商品詳細文と商品名等についてのみ更新可能としてもよい。
【0089】
更に、CSVファイルやAPIについては、すべての項目とその項目に属するデータを含めた形で提供先ショップ1がエクスポートを行う。この場合、エクスポートされたデータはセンターサーバー6で解析のために利用することができる。
提供先ショップ1によるエクスポート、及び、エクスポートされたデータのセンターサーバー6へのアップロードは手動で行われても良いが、自動で行われるようにしてもよい。このエクスポートされたデータは提供先ショップ1の商品データと提供元ショップ2の商品データとに分離されてもよい。
一方、センターサーバー6が提供したCSVファイルやAPIについては、提供先ショップ1側でインポートされる。この際、インポートは全データについて行い、インポートした項目の内の提供先ショップ1の商品データの価格や在庫数等のリアルタイム性の高い項目についてはデータの更新をしないとすることも可能である。あるいは、提供元ショップ2の商品データだけについて更新を行い、提供先ショップ1の商品データについてはデータの更新をしないとされてもよい。
【0090】
このときのセンターサーバー6からのデータのダウンロード及び提供先ショップ1側でのインポート処理も手動で行われても良いが、自動で行われるようにしてもよい。
更に、CSVファイル若しくはAPIのフォーマットは4つの態様の商品詳細ページのそれぞれの作成に対応した4つのパターンのデザインテンプレートを用意してもよいが、一つのデザインテンプレートとする等より少ない共通化したデザインテンプレートで対応することもできる。この場合、4つの態様の如何によっては不要となる項目もできるが、不要となる項目については例えば空欄とすることで対応する。あるいは、態様により必要なhtmlソースコードをwebページ作成部79が、デザインテンプレートの所定部分に対し自動で加えたり、加えなかったりしてもよい。
【0091】
例えば、CSVファイル中に販売店リストのデータが存在するか否かにより、webページ作成部79が、商品詳細ページのデザインテンプレートの所定部分(例えば商品説明文の右外側の適所)に対し販売店リストのhtmlソースコードを加えたり、加えなかったりする。これにより、販売店リストが存在する場合と存在しない場合とについて共通化したデザインテンプレートを用いることができる。
共通化したデザインテンプレートで対応することで、提供先ショップ1では改造を無くしたり、若しくは最小限にできる。このように4つの態様を共通化したデザインテンプレートで対応した場合や販売店リストを商品詳細ページに含めたり、ショップid等を商品名に含めた場合等には、ステップ113、ステップ129の販売店リスト不存在符号やステップ115、ステップ131の提供先ショップに属する商品か否かの判断は不要にできる。
また、既存の提供先ショップ1により改造をせずに構成する場合には、ステップ125で説明したように、販売店リストの各提供元ショップ2から直接ショッピングカートに連携することは困難である。そこで、販売店リストの各提供元ショップ2からリンクされた個別の商品詳細ページを用意し、この商品詳細ページに配設された購入ボタンからショッピングカートに連携されることが望ましい。
【0092】
なお、販売店リストは必ずしも作成若しくは掲載されなくても良い。また、検索結果リスト、一覧ページ、関連商品欄には、個別商品についてのみ
図17と
図18に示す商品詳細ページを掲載することも可能である。また、販売店リストの作成を行うか否か、若しくは販売店リストを商品詳細ページ等に掲載するか否かや、個別商品についてのみ商品詳細ページを掲載するか否かを、提供先ショップ1の後述する管理画面201において選択できるようにしてもよい。更に、提供先ショップ1の商品と同じ提供元ショップ2の商品が存在する場合には、検索結果リスト等には提供先ショップ1の商品を掲載し、この同じ提供元ショップ2の商品を掲載しないようにしてもよい。そして、この掲載の可否も管理画面201において選択自在としてもよい。
【0093】
更に、販売店リストに提供先ショップ1自身の商品データを掲載するか否かも管理画面201において選択自在としてもよい。また、販売店リストに提供元ショップ2自身の商品データを掲載するか否かを提供元ショップ2の後述する管理画面203において選択自在としてもよい。
更に、提供先ショップ1の管理画面201を通じて提供先ショップ1側でジャンル、メーカー名、ブランド名、仕様、商品名等の内の少なくとも一つを指定可能とする。検索キーワードによる検索も可能とすることが望ましい。そして、センターサーバー6では、この指定をされたジャンル等のデータを提供先ショップ1側から受信した後、このジャンル等で販売店リストデータベース31と個別商品データベース45について商品データを絞る。但し、提供先ショップ1の希望や選択によっては個別商品データベース45についてのみ商品データを絞るようにしても良い。
【0094】
その後、センターサーバー6は、この絞った結果の商品データをAPIやCSVファイルで提供先ショップ1のサーバー7に対して送信する。提供先ショップ1のwebページ作成部79では、受信した商品データを取り込み一覧ページ、関連商品としてwebページを作成しユーザに対し表示する。一覧ページの作成は、元々有していた商品との混在をする。但し、前述した通り別枠で表示をしても良い。
しかしながら、APIやCSVファイルで受信した商品の一覧リストを選択自在に一旦提供先ショップ1の管理画面201に表示させ、提供先ショップ1側で必要な商品を選択してもらうようにしても良い。この場合、必要なジャンルを指定することで、そのジャンルに属する商品が選択されるようにしてもよい。
【0095】
また、この際には、提供元ショップ2の商品が提供先ショップ1のどのジャンルに属するのかを選択できるようにしてもよい。
ここで選択された商品に関するデータはセンターサーバー6に送信される。この場合、選択された商品に関する商品データのみがセンターサーバー6で絞られた後、センターサーバー6よりAPIを通じて提供される。若しくは、選択された商品については、提供先ショップ1のサーバー7の演算部71で商品データを絞るようにしても良い。提供先ショップ1のwebページ作成部79では、絞られた商品データを取り込み一覧ページ、関連商品としてwebページを作成しユーザに対し表示する。
なお、商品データはAPI経由ではなく、センターサーバー6と提供先ショップ1のサーバー7間でCSVファイルにより行われても良い。
このことにより、提供先ショップ1では、例えば提供先ショップ1で元々掲載しているジャンルと共通した提供元ショップ2側のジャンルの内の必要な商品データのみを掲載できるようになり、提供先ショップ1側のサイトの商品掲載ポリシーを踏襲する形で販売力の強化を図ることができる。
【0096】
但し、このような提供先ショップ1の管理画面201を通じての処理はセンターサーバー6で行うことも可能である。また、提供元ショップ2側でも同様に、提供元ショップ2から提供先ショップ1に対して提供可能な商品やジャンルを選択可能としてもよい。
また、この際には提供元ショップ2の商品が提供先ショップ1のどのジャンルに属するのかを選択できるようにしてもよい。この提供先ショップ1に対して提供可能な商品やジャンルの選択、ジャンルの関連付けはセンターサーバー6側で行えるようにしてもよい。 なお、提供元ショップ2の管理画面203では、提供先ショップ1に対し商品データを提供するときの商品の販売価格を提供元ショップ2自身の通販サイトの価格とは異なる価格に調整可能としてもよい。
【0097】
次に購入処理について説明する。
図15~
図18の商品aの商品詳細ページにおいて購入ボタン101がクリックされると図示しないショッピングカートに商品aが入れられる。また、販売店リスト103、115欄に掲載の提供元ショップ2の図示しない購入ボタンがクリックされると、同様にショッピングカートにこの提供元ショップ2の商品aが入れられる。
なお、この提供元ショップ2をクリックした場合、
図18に示すようなこの提供元ショップ2の商品aの詳細説明文等を含む、より詳しい商品データが提供先ショップ1の商品詳細ページとして閲覧できるようにしてもよい。そして、この商品詳細ページで購入ボタン101がクリックされてもよい。
その後、提供先ショップ1の決済処理が行われる。商品aの購入があった旨は提供元ショップ2に連絡がされるので、提供元ショップ2は商品aの発送の処理を行う。
【0098】
なお、提供先ショップ1側で決済処理を行うのではなく、商品購入における決済処理は提供元ショップ2側で行うものとされてもよい。この場合、例えば、商品aの商品詳細ページにおいてユーザにより購入ボタン101若しくは販売店リスト103、115欄に掲載されたショップがクリックされると、この購入ボタン101や販売店リスト103、115欄に埋め込まれたリンク先の提供元ショップ2側の商品詳細ページに進む。ユーザは、そこで商品の購入が可能である。そして、このクリックの都度に一定の金額が販売手数料として発生するようにしても良い。クリック数のカウントは提供先ショップ1側で行うか、センターサーバー6側で行うことが可能である。
あるいは、いわゆるアフィリエイト処理と同様に、商品購入における決済処理は提供元ショップ2側で行うものとし、ユーザが提供先ショップ1の商品aの商品詳細ページ経由で提供元ショップ2で購入をしたことをセンターサーバー6側で確認することで販売手数料が発生するようにしても良い。
【0099】
次に、提供先ショップ1と提供元ショップ2間の管理システムについて説明する。
図20には、提供先ショップ1のA店と、このA店と提携をした提供元ショップ2-1、提供元ショップ2-2、提供元ショップ2-3の関係を示す。提供元ショップ2-3については、提供先ショップ1のB店と提供先ショップ1のC店とも提携を有している場合である。そして、各店のサーバーには本販売支援システムの管理ツールがインストールされている。但し、管理ツールは提供先ショップ側にだけインストールされてもよい。または、各店のサーバーに管理ツールをインストールするのではなく、各ショップの管理ツールはセンターサーバー6に配設されてもよい。
【0100】
提供先ショップ1のA店で提供元ショップ2の商品aが購入された旨は、購入のあった時点で提供先ショップ1のサーバー7の通信部75を介して、提供先ショップ1のショップ名、この商品aの商品情報、購入をしたユーザの氏名、商品aの配送先等のデータが自動送信若しくはセンターサーバー6を介して解析がされ、提供元ショップ2のサーバー4の通信部55で受信がされる。そして、この旨のデータは提供先ショップ1のサーバー7の管理部77に保存されると共に、表示・操作部73で制御される管理画面201で閲覧ができる。この旨のデータはまた、提供元ショップ2のサーバー4の管理部57にも保存されると共に、表示・操作部53で制御される管理画面203でも閲覧ができる。なお、管理画面201や管理画面203はセンターサーバー6を介しブラウザにて閲覧ができるようにされてもよい。
【0101】
しかし、通信ではなく、あるいは、通信と併用して購入のあった際に提供先ショップ1のサーバー7より自動配信されるメールにて提供元ショップ2のサーバー4側に伝達されても良い。このメールはサーバー7よりユーザに向けて配信される販売確認のメールの写しであってもよい。通信ではなくメールだけが配信された場合には、メール文から必要な情報をサーバー4のプログラムが抽出できるように予め定義をしておく。但し、メール文はセンターサーバー6側に配信され、そこで解析され、解析した結果がサーバー4側に伝えられるようにしてもよい。そして、解析した結果をセンターサーバー6の管理画面201や管理画面203にて閲覧ができるようにされてもよい。
メール文には提供先ショップ1のショップ名、商品aの商品情報、購入金額、購入日時、購入をしたユーザの氏名、商品aの配送先等のテキストが記載されている。なお、ステップ117で説明したようにセンターサーバー6側でショップid等が商品名に加えられている場合には、このコード等を解析することでショップ名を判断することができる。
【0102】
また、提供元ショップ2で受注のあった商品aをユーザに対して発送した場合には管理画面203に表示される図示しない発送完了のボタンをクリックする。このとき、前述とは逆に提供元ショップ2のサーバー4の通信部55を介して送信がされ、提供先ショップ1のサーバー7で受信がされる。発送完了の旨のデータは提供先ショップ1のサーバー7の管理部77に保存されると共に、表示・操作部73で制御される管理画面201で閲覧ができる。
【0103】
この旨のデータはまた、提供元ショップ2のサーバー4の管理部57にも保存されると共に、表示・操作部53で制御される管理画面203でも閲覧ができる。発送完了の旨は、提供元ショップ2のサーバー4、若しくは提供先ショップ1のサーバー7よりユーザに向けてメール配信される。
なお、管理画面203がセンターサーバー6に配設された場合には、発送完了のボタンはセンターサーバー6を介した管理画面203に表示される。また、管理画面201がセンターサーバー6に配設された場合には、発送完了の旨のデータはセンターサーバー6を介した管理画面201で閲覧ができる。そして、この場合、発送完了の旨は、センターサーバー6よりユーザに向けてメール配信される。
また、提供元ショップ2のサーバー4の管理部57、提供先ショップ1のサーバー7の管理部77では、商品の販売履歴を基に演算部51、演算部71により計算された在庫数や、販売手数料が保存される。この在庫数や、販売手数料についてもセンターサーバー6の演算部11で計算されてもよい。
【0104】
次に、販売履歴データの管理について説明する。
図21では、提供先ショップ1のサーバー7の管理部77に保存されている販売履歴データが管理画面201に表示された様子を概念図で示している。管理画面201では、提供先ショップ1(自社)で取り扱いのある商品の販売履歴と各提供元ショップ2の商品の販売履歴とが時系列に記録されている。
【0105】
例えば、提供先ショップ1のwebサイト9において、1月6日9時には自社取り扱いの商品が売れた。そして、1月6日10時には、提供元ショップ2-1の商品1が売れた。このため、提供元ショップ2-1の商品1の販売個数を1つインクリメントする。続いて、1月7日8時には、提供元ショップ2-2の商品2が売れた。このため、提供元ショップ2-2の商品2の販売個数を1つインクリメントする。以下、同様に販売のあった旨が記録されている。
【0106】
但し、サーバー7の管理部77では、自社取り扱いの商品の販売履歴と各提供元ショップ2の商品の販売履歴とを別々に管理して表示するようにしても良い。また、商品1をクリックすると商品1だけについての販売履歴も閲覧できる。ショップ名をクリックしたりタブを切り替えることで、各ショップ毎にまとめた販売履歴や販売実績も閲覧できる。
サーバー7の演算部71では販売手数料が計算可能であり、例えば提供元ショップ2-1の商品1がこの時点までに合計3個売れたとすると、販売手数料の単価が100円だったとして100円×3個=300円と計算がされる。
【0107】
また、
図22には提供元ショップ2-3側のサーバー4の管理部57に保存されている販売履歴データが管理画面203に表示された様子を概念図で示している。管理画面203では、各提供先ショップ1で購入された商品の販売履歴と提供元ショップ2-3の商品(自社)の販売履歴と在庫数が時系列に記録されている。
但し、サーバー4の管理部57においても、自社取り扱いの商品の販売履歴と各提供先ショップ1の商品の販売履歴とを別々に管理して表示するようにしても良い。
例えば、当初、提供元ショップ2-3の商品3についての在庫数が5個であったとする。そして、
図22では、1月9日11時に提供先ショップ1のA店のサイトで、この提供元ショップ2-3の商品3が1個売れたことが履歴として表示されている。なお、この販売の旨は
図21に示すように、提供先ショップ1側にも1月9日11時に商品3の売れたことが履歴として保存される。
【0108】
この時点で、提供元ショップ2-3側のサーバー4の演算部51が商品3の在庫を1個デクリメントして4個とする。
1月9日12時には、提供元ショップ2-3(自社)で商品3が1個売れた。このため、演算部51が商品3の在庫を1個デクリメントして3個とする。続いて、1月9日13時には、提供先ショップ1のB店のサイトで、この提供元ショップ2-3の商品3が1個売れた。このため、演算部51が商品3の在庫を1個デクリメントして2個とする。
このようにして、販売履歴と在庫の管理がまとめて閲覧可能である。
なお、管理画面201、管理画面203がセンターサーバー6に配設された場合には、演算部51、演算部71はセンターサーバー6に備えられる。
【0109】
図23には、提供元ショップ2-3を例に、提供元ショップ2が同時に提供先ショップ1にもなっている場合を示している。この場合、例えば
図20において、A店と提供元ショップ2-3とは互いに提供先と提供元を兼ねるようにしても良い。
この場合であっても同一の管理画面203で管理が可能である。但し、提供元ショップ2としての管理画面と提供先ショップ1としての管理画面を別に閲覧可能としても良い。タブで切り替えられるようにしても良い。
なお、このショップ同士のいわゆる相互販売の関係は、例えばこの提供元ショップ2-3において複数の提携先との間で設定されても良い。また、ショップが提供元ショップ2の立場を選ぶか、提供先ショップ1の立場を選ぶかはこのショップ自身の判断で自由に決められる。
【0110】
また、商品在庫の有無や在庫の個数はセンターサーバー6が提供元ショップ2のwebページにて判断しても良いが、提供元ショップ2側からセンターサーバー6側にこれらのデータの送信がされても良い。在庫の無くなった商品についてはAPIを介してセンターサーバー6より提供先ショップ1に対してその旨の送信がされる。しかしながら、この場合にはAPIからこの商品の商品データの提供をしなくするとされても良い。
【0111】
更に、販売履歴と在庫の管理データは本販売支援システムで提携のショップやモールだけではなく、提携していないショップやモールのデータも含めて履歴管理されるようにしても良い。この場合には、このショップやモールより、メールで販売データを受信し、前述したようにメール内容を自動で解析して掲載する。
この販売データのメールは、このショップやモールより直接受信しても良いが、転送メールを受信するようにしても良い。
以上により、提供先ショップ1は複数の提供元ショップ2が参加した通販モールにできる。このとき、既存の提供先ショップ1の通販システムをそのまま利用し、改造が無く、若しくは少ない改造でモール化を実現できる。センターサーバー6内に提供先ショップ1を新しく配設した場合でも同種の商品のまとめられた、あるいは、複数の提供元ショップ2の商品が取り扱われる購入のされ易いモールを実現できる。また、ショップ同士の間での相互販売や提携したショップとの間の提携相手側の商品を取り扱った販売が、実商品の移動の無い状態でも改造無く、若しくはわずかの改造だけで簡単に実現できる。
【0112】
なお、相互販売、提携販売をしている提携先に対し、販促のために行う自店のキャンペーンの内容を管理画面201、203を通じて知らせて賛同をしてくれるショップを募るようにしてもよい。キャンペーンの告知は、提供先ショップ1、提供元ショップ2を問わずに可能である。
この場合、キャンペーンの期間はショップ間で同じにして複数のショップ同士で共通したキャンペーンを行うことが望ましい。賛同のキャンペーンを行うかどうかは互いに自由に決められる。
具体的には、図示は省略するが、管理画面201、203において、「キャンペーン提案を発信する」タブと「他店からのキャンペーン提案を読む」タブを設ける。「キャンペーン提案を発信する」タブをクリックすると、開かれたページにおいて、まず、キャンペーンの期間が設定可能なようになっている。そして、このキャンペーンの対象とする範囲を自店のすべての商品について行うのか、一部の商品について行うのか、特定のジャンルについて行うのか等が設定可能なようになっている。
【0113】
また、キャンペーンの内容を選択することができる。このキャンペーンの内容は例えば送料無料とする、おまけを付ける、合計金額が幾ら以上で送料無料とする、金額の何%の現金還元する、値引する、ポイントを付与する等である。この際に原資の必要な場合にはこの原資の負担元を選択できるようになっている。また、キャンペーンの内容はテキストボックスにテキスト入力をして自由に記述ができるようになっている。そして、送信相手先はすべての提携先のショップを対象とするのか、あるいは、ポップアップ画面に表示された提携先ショップの送信相手先候補の内から選択をして送信相手先を決めるのかが選択できるようになっている。これらの選択をしてから送信するボタンを押すと、指定された送信相手先に対してこのキャンペーンの内容が送信されるようになっている。
【0114】
一方、「他店からのキャンペーン提案を読む」タブをクリックすると、他店からのキャンペーン提案が閲覧できる。このページにはキャンペーン提案をしたショップ名、キャンペーンの期間、キャンペーン内容の要点、詳細ページに進むリンクとがリスト形式にまとめて記載されている。そして、詳細ページに進むリンクをクリックするとこの提案内容が詳細に分かるようになっている。そこで、自店でもこのキャンペーンに賛同する場合には、賛同ボタンを押す。この際、返答の必要な項目が存在する場合については選択形式、若しくはテキストボックスへのテキスト入力で返答を行う。
これにより、提携先ショップ1において、自店の商品だけではなく、賛同した複数の提供元ショップ2の商品についてもまとめて自店の商品と同一内容のキャンペーンを実施できる。あるいは、賛同した複数のショップ間で互いに同一の時期に同一の内容のキャンペーンを実施できる。このため、相互販売、提携販売をしているショップ同士の間で共創関係が築かれ、共通するキャンペーンの下に販売力の強化が図れる。
【0115】
次に、ショップが、デリバリーや資料請求、クーポン適用、テイクアウト、予約、注文、外国人購入用、ライブコマース、動画による広告等の仕組みを導入する方法について説明する。
まず、既存のショップにおいて、これらの仕組みを導入する方法について説明する。
センターサーバー6では、既存のショップに対してこれらの仕組みを導入する旨の申請が行えるようになっている。ここに、デリバリーはネットを介して食事を自宅や会社まで届ける仕組みであり、資料請求はユーザがネットを介して必要な資料の請求ができる仕組みであり、クーポン適用は、発行されたクーポンをネットを介してユーザが利用できるようにする仕組みであり、テイクアウトは、商品の持ち帰りをネットを介して可能とする仕組みであり、予約は、宿泊の予約、飲食のテーブル席の予約、商品購入の予約等がネットを介して行えるようにする仕組みである。また、現金還元は、ネット上で現金値引で商品が購入できる仕組みであり、価格交渉は、システム上で仮想におかれた店員との間でネット上で価格の交渉ができる仕組みである。外国人購入用は、海外又は国内にいる日本語に習熟していない外国人ユーザからの国内販売商品の注文、購入ができる仕組みである。
【0116】
次に、ネットを介して資料請求する場合を例に以下説明する。
図24のフローチャートに示すように、ステップ151では、
図7のステップ1~ステップ4と同様に、例えば資料請求を行いたいという旨の申請のあったショップK店よりセンターサーバー6は、商品データを収集する。このときの収集はショップK店の通販サイトに対して巡回プログラム21により自動で行ってもよいが、CSVファイルの提供や人手による作業で行ってもよい。毎回の巡回ではなく、更新のあったときだけデータ取得やデータ入力をしてもよい。
そして、ステップ153では、収集されたK店の商品データについて、センターサーバー6の商品データ解析プログラム23は、
図25に示すような商品詳細ページ140に掲載される商品説明文141中の適所(例えば商品説明文141中の最上位部分)に対し、資料請求ボタン143の画像URL、ショップidや商品コードをパラメータとして含むリンク先のURLがhtmlの形式で記載されたソースコードを自動で埋め込む。資料請求ボタン143の画像はセンターサーバー6のデータベース30に準備されている。商品コードはそれぞれの商品詳細ページ140に掲載される商品に応じて埋め込まれる。但し、商品説明文141中には、資料請求ボタン143を表示するためのスクリプトをソースコードとして埋め込んでも良い。スクリプトは例えばジャバスクリプト(登録商標)で構成され、商品詳細ページ140中に資料請求ボタン143を配設してもよいが、一旦ポップアップ画面を表示し、その画面中に資料請求ボタン143を配設する等してもよい。また、商品詳細ページ140中にリンクを生成し、このリンクをクリックすることでポップアップ画面を表示するようにしてもよい。
ステップ151で収集をした商品データを、前回取得した商品データとの間での一致を判断すれば、商品データが追加、削除、更新されたことが分かる。これに合わせてセンターサーバー6の商品データ解析プログラム23では、これらの追加、削除、更新のあった商品データについての編集を行う。この際、追加、更新のあった商品データについては資料請求ボタン143用のソースコードを自動で埋め込む。
【0117】
ステップ155では、この処理の行われた商品データを、センターサーバー6はCSVファイルに保存し、このCSVファイルをK店に対し提供、若しくはAPI経由でK店のサーバーに対し提供する。ステップ157では、K店ではこのCSVファイルをインポートし、若しくはAPI経由で商品データを取得することで、K店のサーバーのwebページ作成部がデザインテンプレートに対してこの商品データを流し込み、商品詳細ページ140を自動作成する。CSVファイルをインポートする場合は、手動若しくは自動で対応可能である。
【0118】
次に、
図26のステップ161では、このK店の通販サイトを訪れたユーザが、この商品詳細ページ140において資料請求ボタン143をクリックする。この場合、ステップ163では、ショップidや商品コードをパラメータとして含むリンク先のURLがセンターサーバー6に送信される。そして、ステップ165でセンターサーバー6が、このURLを受信し、ステップ167でショップidや商品コードが解析される。ステップ169では、ユーザ対応・管理プログラム25が動作し、センターサーバー6側でショップidや商品コードに対応する必要項目と内容がユーザ対応・管理データベース47より読まれる。
【0119】
なお、この資料請求に必要な項目と内容については、K店が予めセンターサーバー6の管理画面において登録をしておくことが望ましい。ここで設定された事項の内のユーザ向けの事項については、ユーザ対応・管理プログラム25の処理の過程でユーザに対して表示が行われる。即ち、ユーザ対応・管理データベース47より読まれた必要項目と内容に基づき、資料請求の処理の過程で表示されるユーザに対する問い合わせや、必要項目の選択や登録、お知らせ等を含む画面が作成される。その後、ステップ171で表示された画面に対し、ユーザによる必要項目の選択や登録等の応答が行われる。その後、資料請求の処理が完了した場合には、ステップ173で、センターサーバー6よりユーザ及びK店に対し請求の完了した旨が画面及びメールにより通知される。
これにより、K店では改造無く容易に資料請求ボタン143を追加できる。資料請求ボタン143に限らず、デリバリー用ボタン、クーポン適用ボタン、テイクアウト用ボタン、予約用ボタン、現金還元用ボタン、価格交渉用ボタン、購入ボタン、外国人購入用ボタン、ライブコマース開始ボタン等も同様に適用が可能である。一つだけボタンを配設するのではなく、これらの複数のボタンを処理の必要な分だけ配設してもよい。
【0120】
次に、相互販売、提携販売、モール化を行っている提供先ショップ1が購入、デリバリー、資料請求、クーポン適用、テイクアウト、予約、注文、外国人購入等の仕組みを導入する際に、提供先ショップ1と提供元ショップ2間や、各提供元ショップ2毎に異なる内容の購入等の処理画面をユーザに対し表示する方法について説明する。
相互販売、提携販売、モール化を行う際には、提供先ショップ1の既存の購入等の処理システムをそのまま使うことが可能である。この場合、提供先ショップ1と各提供元ショップ2の間で購入等の処理の仕様が同一であったり、一様に統一ができれば、従来通りの提供先ショップ1の同一の仕様に基づく処理をそのまま行うということで問題はない。
しかしながら、例えばデリバリー等を行う同業者同士で相互販売を行う場合には、提供先ショップ1と各提供元ショップ2の間や、各提供元ショップ2同士の間に配達や製造時間等において仕様上のずれ等が生ずることがある。以下は、この仕様上のずれをセンターサーバー6において管理画面の設定で補うことで、相互販売、提携販売への参加を促進する方法である。なお、異業種の事業者間において相互販売が行われる場合には、より仕様上の相違は鮮明となるが、同様の設定方法で各提供元ショップ2毎に独自の仕様を決めることで、参加を促進できるものである。
【0121】
デリバリーについて一例をあげれば、デリバリーにおける配達までの準備時間や配達料、配達を行う事業者が提供先ショップ1と各提供元ショップ2のそれそれの間で異なっていたと仮定する。このような場合に、センターサーバー6で提供する
図27に示すような提供元ショップ2の管理画面205において、各提供元ショップ2はそれぞれ、事前に自店で対応の可能な注文を受けてからの商品の製作完了までの時間の設定や配達時間の設定、配達料、配達を行う事業者の仕様の設定等を行う。但し、この仕様の設定内容は事業者の要望等如何により変更され得るものである。このため、事業内容毎にセンターサーバー6側で仕様を各事業者が選択し易いようにまとめて、各事業内容毎に必要な設定項目や仕様を予め用意しユーザ対応・管理データベース47に保存しておくことが望ましい。設定項目は例えば、「注文を受けてから製作完了までの標準時間」や「配達までの標準時間」であり、仕様は「5分」、「10分」、「15分」等である。この仕様は事業者により選択できることが望ましいが、自由記入ができるようにしてもよい。
なお、事業者に対し管理画面205を表示するに際しては、センターサーバー6が予め登録されている各事業者の事業内容をまずデータベース30から読み、その事業内容に一致する設定項目や仕様をユーザ対応・管理データベース47から抽出して各事業者に応じた管理画面205のwebページを自動で作成して表示する。
また、各事業内容毎に各事業者間で共通できる部分と共通できない部分とに分離しておき、事業者には共通部分をまず先に設定若しくは記入してもらい、共通できない部分はその後に特殊事項として設定若しくは記入してもらうことが望ましい。ここで事業者により設定や入力された情報はユーザ対応・管理データベース47に保存される。
【0122】
次に、フローチャートに従ってデリバリー等の仕組みを導入する方法を説明する。
図28のフローチャートに示すように、ステップ181では、
図7のステップ1~ステップ4や
図8のステップ5~ステップ10と同様に、デリバリーを行いたいという旨の申請のあった提供先ショップ1と各提供元ショップ2よりセンターサーバー6は、商品データを収集する。このときの収集は巡回プログラム21により自動で行ってもよいが、CSVファイルの提供や人手による作業で行ってもよい。毎回の巡回ではなく、更新のあったときだけデータ取得やデータ入力をしてもよい。
【0123】
ステップ183では、提供元ショップ2の商品データの内、予め提供先ショップ1により選択された商品のみをセンターサーバー6にて抽出する。即ち、提供先ショップ1は、データ取得をした商品の全体を以降の処理の対象としてもよいが、自店で掲載を希望する必要な商品のみを選択するようしてもよい。自店で必要な商品の選択はセンターサーバー6の管理画面にて行える。なお、提供元ショップ2の商品データは、提供元ショップ2により選択されたものであってもよい。
その後、センターサーバー6では、ステップ183で選択された各提供元ショップ2の商品データと提供先ショップ1の商品データに対して、ステップ185で以下の編集を行う。即ち、商品データ解析プログラム23はこの商品データに対して、デリバリーボタンの画像URL、ショップidや商品コードをパラメータとして含むリンク先のURLがhtmlの形式で記載されたソースコードを自動で生成する。
そして、この生成したソースコードを提供先ショップ1と各提供元ショップ2の商品説明文161中の適所(例えば上部)に自動で追加記載する。
図29には、提供元ショップ2の商品説明文161の上部に対し、生成したデリバリーボタン163を配設した画面例を示す。この場合には改造は不要である。なお、ソースコードは上記したようにスクリプトで構成してもよい(以下、同旨)。
【0124】
なお、もともと提供先ショップ1が商品詳細ページに掲載している
図5等に示す購入ボタン101は、商品詳細ページから消すように改造がされてもよい。
また、
図30の提供元ショップ2の商品詳細ページ170の例に示すように、生成したデリバリーボタン173用のソースコードは、もともと配置されていた購入ボタン101や注文ボタン等のソースコードに代えて、その同じ箇所に対し埋め込むようにサーバー7側の改造を行ってもよい。あるいは、デリバリーボタン173が購入ボタン101や注文ボタン等と併存して表示されるようにしてもよい。デリバリーボタン173が商品詳細ページ170のヘッダ部分等の上部に表示されるようにしてもよい。これらの場合、コメント文と共にボタンが表示されるのが望ましい。バナーとして表示されてもよい。デリバリーボタン163、173の画像はセンターサーバー6のデータベース30に準備されている。このようにデリバリーボタン173用のソースコードを差し替えたり埋め込む点は、ショップが相互販売、提携販売、モール化を行わない場合であっても適用可能である。
なお、デリバリーボタン173用のソースコードはデリバリーボタンの画像URL、ショップidをパラメータとして含むリンク先のURLがhtmlの形式で記載されたソースコードであり、商品コードに相当するパラメータ部分を空欄にした状態で提供先ショップ1に対して提供されることが望ましい。そして、提供先ショップ1側のサーバー7のwebページ作成部79では、この空欄部分に対して提供先ショップ1側で割り振っている商品コードを埋め込んだ形で商品詳細ページ170を生成する。商品コードは、それぞれの商品詳細ページ170に掲載される商品に対応して生成される。この商品コードはステップ181で収集された商品データからセンターサーバー6側で既に認識されているので、センターサーバー6では商品毎に円滑にデリバリーの処理ができる。但し、商品コードは、提供先ショップ1においてセンターサーバー6側で生成したものを用いても良い。この場合でも共通した商品コードで処理ができるので、センターサーバー6側では商品毎に円滑にデリバリー等の処理ができる。
また、センターサーバー6では、商品詳細ページ170のURLを取得し、そのURL中に含まれる商品コードを解析するようにしてもよい。このURLは、デリバリーボタン173等のリンクボタンがクリックされることにより、センターサーバー6に対しリンク用URLに付属のパラメータとして送信元URLが送信されるので、センターサーバー6側でこの送信元URLを取得できる。また、商品詳細ページ170のURLはスクリプトにより取得をし、センターサーバー6に送信するようにしてもよい。ショップ名は、URL中のドメインを抽出することで特定できる。このようにして取得をした商品コードとショップのデータについて、センターサーバー6側ではデータベース30を参照して商品を特定でき、商品毎に円滑にデリバリー等の処理ができる。リンク用URLを含むソースコードは、ショップ側のすべての商品詳細ページに対して共通の一行程度のソースコードとして提供できる。
ショップが相互販売、提携販売、モール化を行っている場合であってもすべての商品詳細ページに対して共通のソースコードを埋め込めば良いので簡単である。デザインテンプレート利用であれば1カ所だけ修正すればよい。
なお、センターサーバー6側で商品を特定するに際しては、商品詳細ページ170中の適所にスクリプトを埋め込んでおき、タイトル又は商品名を取得することで行なっても良い。タイトルを抽出した場合には、このタイトルから商品名を抽出する。これにより、商品を判断してもよい。このタイトルからはショップ名も抽出できる場合もあるが、商品詳細ページ170のソースコード中よりショップ名が抽出されてもよい。
また、商品詳細ページ140、160、170には資料請求ボタン143やデリバリーボタン163、173を配設するのではなく、アンカーテキストを埋め込むようにしてもよい。この場合、ソースコードには資料請求ボタンやデリバリーボタンの画像URLではなく、アンカーテキストを含むようにする。
【0125】
ステップ187では、センターサーバー6において、ショップ名や、このショップ名を含むコメント文(例えば、「この商品はA店の商品でA店より配送します」等)を商品名中や商品説明文161、171の適所(例えば上部)に自動で追加記載する。この追加記載は
図29の商品説明文161中の上部や
図30の商品説明文171中の上部に埋め込んだコメント文165に示すように、各提供元ショップ2の商品データに対して行い、提供先ショップ1の商品データに対しては不要である。文字は目立つように強調・装飾されたり、括弧で囲われたりするのが望ましい。コメント文165の埋め込みについては、センターサーバー6において商品説明文161、171中へのテキストやタグの挿入により行われるので、提供先ショップ1側での改造は不要である。但し、挿入に限るものではなく、目立ち易いように商品説明文161、171の一部のテキストや画像等について削除や変更等の編集がされてもよい。また、ショップ名やコメント文は、ステップ185で生成をしたソースコード中に埋め込むようにしても良い。更に、ショップ名やコメント文は、前述したスクリプトにより表示されたポップアップ画面等に表示されてもよい。ショップ名やコメント文には他言語の翻訳文が記載されてもよい。
更に、提供先ショップ1や提供元ショップ2の商品データに対しては、例えば商品説明文161、171中の下部等に、商品説明文161、171中に記載された商品説明のテキストの一部又はすべてを、センターサーバー6において他言語に翻訳したテキストを埋め込むようにしてもよい。商品説明文141についても同様である。この場合についても同様にショップ側での改造は不要である。そして、この翻訳したテキストの上部や下部に資料請求ボタン143やデリバリーボタン163、173を配設してもよい。
また、ステップ151で収集をした商品データについて、この商品データの追加、削除、更新のされたことを判断することで、これに合わせて自動的に翻訳したテキストの埋め込みも可能である。従ってショップ側での手間は不要である。
【0126】
ステップ189では、この処理の行われた商品データを、CSVファイルとして、若しくはAPI経由でセンターサーバー6は提供先ショップ1に対して提供する。ステップ191では、提供先ショップ1が手動若しくは自動でこのCSVファイルをインポートし、またはAPI経由で商品データを取得することで、webページ作成部79がデザインテンプレートに対してこの商品データを流し込み、商品詳細ページ160、170を自動作成する。
デリバリー用ボタンに限らず、資料請求ボタン、クーポン適用ボタン、テイクアウト用ボタン、予約用ボタン、現金還元用ボタン、価格交渉用ボタン、購入ボタン、外国人購入用ボタン、ライブコマース開始ボタン、動画による広告ボタン等も同様に適用が可能である。商品詳細ページ160、170にはこれらの内の少なくとも一つのボタンを配設してもよい。また、複数のボタンを並べて配設してもよい。
【0127】
なお、デリバリー用ボタンを埋め込むのではなく、販売店リスト103、115をデリバリー対応可能な販売店のリストとしてもよい。そして、この販売店リスト103、115に掲載のショップをクリックした場合には、センターサーバー6で用意しているこのショップ用のデリバリー処理が上記と同様に動作するようにしてもよい。また、この販売店リスト103、115に掲載のショップをクリックした場合には、センターサーバー6で提供元ショップ2の商品データに基づく商品詳細ページが生成されてユーザに対し表示され、そのページ中にデリバリー用ボタンが配設されてもよい。
更に、販売店リスト103、115に掲載のショップをクリックした場合には、提供先ショップ1が、例えば
図17、
図18に示すような個別の商品詳細ページ120、130を生成する。そして、そのページに上述した方法によりデリバリー用ボタンを埋め込むようにしてもよい。
あるいは、商品詳細ページ160、170にはデリバリー対応の可能な販売店リストを含むwebページをリンク先としたURLを埋め込んだボタン、若しくはアンカーテキストが配設されてもよい。
【0128】
図31のステップ201では、この提供先ショップ1の通販サイトを訪れたユーザが、商品詳細ページ160、170においてデリバリーボタン163、173をクリックする。但し、ボタンではなくアンカーテキストがクリックされるようにしてもよい。
この場合、ステップ203では、ショップidや商品コードをパラメータとして含むリンク先のURLがセンターサーバー6に送信される。そして、ステップ205でセンターサーバー6が、このURLを受信し、ステップ207でショップidや商品コードが解析される。ステップ209では、センターサーバー6のユーザ対応・管理プログラム25が動作し、このショップidや商品コードを基に例えば注文画面を生成し、ユーザの使用するパソコン3やスマートフォン5等の情報端末に配信する。
但し、商品詳細ページ160、170には、デリバリーボタン163、173の代わりにリンクを埋め込み、このリンクがクリックされたときにはセンターサーバー6側で作成した商品詳細ページを出すようにしてもよい。この商品詳細ページには商品説明文、コメント文、商品名、注文に際しての注意事項等を掲載する。また、これらに対する他言語の翻訳文を掲載してもよい。そして、この商品詳細ページ中に掲載されたデリバリーボタンをクリックした後に注文画面を生成するようにしてもよい。商品詳細ページ140についても同様である。ステップ211では、この注文画面に対してユーザが注文数を入力してセンターサーバー6へ送信する。そして、ステップ213ではセンターサーバー6が注文数データを受信する。
【0129】
ステップ215では、
図27の管理画面205において、予め事業者毎に設定されユーザ対応・管理データベース47に保存されている設定仕様データが読まれる。ステップ217では、現在の注文数と注文の日時が読まれる。その後、ステップ219では、設定仕様データの内容を基に現在の注文数と注文の日時から、ユーザ対応・管理プログラム25が製品完成までの時間及び配達までの時間を演算する。但し、この演算は多数の実績データを基にAIが推定するようにしてもよい。ステップ221では、この演算結果並びに設定仕様データに基づき
図32に示すような、ユーザに対するこの提供元ショップ2の問い合わせ画面207がユーザ対応・管理プログラム25により自動的に生成される。この問い合わせ画面207中には、購入される商品が提供元ショップ2の商品である旨が記載され、事前に提供元ショップ2が登録した情報に基づきデリバリーに必要な表示がされる。
【0130】
このことにより、各提供元ショップ2毎に応じたきめ細かな情報を有する問い合わせ画面207を表示できる。また、ユーザにとってはこの商品を提供するショップや配達元を確実に把握できる。ステップ223では、この問い合わせ画面207に対してユーザが応答し「次へ」ボタンを押すと、決済処理に進み、その後、ステップ225で注文が確定する。その後、ステップ227ではユーザ及び提供先ショップ1と提供元ショップ2に対し注文の確認メールが配信される。
以上により、相互販売、提携販売、モール化で提供先ショップ1と各提供元ショップ2がそれぞれ異なる内容のデリバリー仕様、テイクアウト仕様や予約仕様等を希望する場合であっても容易に対応ができる。
【0131】
次に、デリバリー等についてネット上で注文を受けた場合とリアル店舗で注文を受けた場合の融合方法について説明する。
以下、
図33の商品詳細ページ180に示すようなラーメン店の場合をショップの例として説明する。
このラーメン店(A店)の例では、商品データの多くがこのwebページ内に記載されており、注文ボタンの類は存在しないものと仮定する。このwebページ内の適所にデリバリーボタン183を配設する。デリバリーボタン183用のソースコードはデリバリーボタンの画像URL若しくはアンカーテキスト、ショップidや事業種類コードをパラメータとして含むリンク先のURLがhtmlの形式で記載されたソースコードである。パラメータには複数の商品をまとめたグループ毎のグループidが含まれても良い。このソースコードはセンターで生成されラーメン店(A店)に対して提供される。
事業種類コードは、
図34に示すような、各事業内容毎に予め用意されユーザ対応・管理データベース47に保存された設定項目や仕様に関連付けられたコードである。但し、ショップが同一の事業種類しか行っていないような場合には事業種類コードは不要である。また、デリバリーボタン用のソースコードは、商品詳細ページ180に掲載のすべての商品に対してwebページに埋め込まれても良い。
【0132】
商品詳細ページ180においてデリバリーボタン183がクリックされると、センターサーバー6のユーザ対応・管理プログラム25は商品詳細ページ190を生成し、ユーザの使用する情報端末に提供する。この商品詳細ページ190は、ステップ151で説明したような方法でデータ取得され、データベース30に保存されている商品データをユーザ対応・管理プログラム25が読み生成する。そして、この商品詳細ページ190に掲載の各商品には注文ボタン191が配設されている。この商品詳細ページ190は1商品の掲載でもよいが、
図33に示すように商品詳細ページ180の記載内容に合わせて複数商品を掲載することも可能である。
【0133】
ユーザによりこの注文ボタン191がクリックされると、ステップ201以降とほぼ同様の処理が行われる。注文ボタン191以外に、資料請求ボタン、クーポン適用ボタン、テイクアウト用ボタン、予約用ボタン、現金還元用ボタン、価格交渉用ボタン、外国人購入用ボタン、ライブコマース開始ボタン、動画による広告等を並べて配設してもよい。 また、商品詳細ページ190には相互販売や提携販売による提供元ショップ2の商品データが掲載されてもよい。この場合には、この商品詳細ページ190の適所には、「この商品データは提供元ショップ2の商品で提供元ショップ2より配送します」等のコメント文を記載できる。この商品詳細ページ190はセンターサーバー6において作成されるので、コメント文の記載箇所はセンター側で任意にできる。商品詳細ページ190はセンターサーバー6において他言語にて作成されてもよい。
また、ステップ181のように商品データの収集をし、この商品データの追加、削除、更新のされたことを判断することで、商品詳細ページ190に掲載の商品についても自動的に商品データの追加、削除、更新が可能である。従ってショップ側での手間は不要である。
【0134】
次に、このラーメン店(A店)の注文や売上等の管理方法について説明する。
このラーメン店(A店)の管理画面205には、ラーメン店の事業種類コードであるコード1に対応する商品と設定項目がユーザ対応・管理データベース47(
図34参照)から読まれて表示される。なお、このラーメン店(A店)の管理画面205の具体的な画面例については省略する。
ラーメン店(A店)側では事前にこの管理画面205に表示された設定項目毎に仕様を選択若しくは入力する。例えば、醤油ラーメンについては、この店での製作時間は5分なので選択ボックスで5分、10分、15分、20分と表示された中から5分を選択する。入力されたデータは、
図35に示すように、ユーザ対応・管理データベース47に保存される。管理画面205ではこの醤油ラーメンについて他に、同時に作成が可能な件数を入力する。この店で、醤油ラーメンについて同時に作成が可能な件数は5個なのでユーザ対応・管理データベース47では5個が入力されている。また、この店で最大で受けられる注文件数は何件まで可能かがユーザ対応・管理データベース47に設定されている。この店では10件と設定されている。但し、同時に何種類の商品が処理できるのかが設定されるようにしてもよい。
【0135】
なお、通常ラーメン店では実店舗を持っていることが多い。このため、ネットの注文だけではなく、実店舗からの注文にも対応することが望ましい。実店舗からの注文は、センターサーバー6とインターネット10を介して接続されたタッチパネル型パソコン3又はスマートフォン5等の情報端末で行う。この注文処理は情報端末に対し所定のアプリをダウンロードすることで行われるのが望ましい。
図36に情報端末に表示された画面例を示す。注文画面210において、商品画像211には商品名や写真が描かれている。インクリメントボタン213をクリックすると、件数表示欄215の件数が1件ずつ増加するようになっている。一方、デクリメントボタン217をクリックすると、件数表示欄215の件数が1件ずつ減少するようになっている。この実店舗の客席用のテーブルには番号が付されている。そして、テーブル番号入力欄219に、注文をした顧客が座っているテーブル番号を入力することで、誰の注文であるかが分かるようになっている。テーブル番号の入力方法は、数字入力や画像のクリック等任意である。その後、送信ボタン221をクリックすると、注文のあった商品の商品id、注文件数、テーブル番号、注文日時がセンターサーバー6に送信され、ユーザ対応・管理データベース47に保存されるようになっている。
【0136】
次に、センターサーバー6のユーザ対応・管理プログラム25は、ユーザ対応・管理データベース47に保存されているデータを読み、以下の処理を行う。
ユーザ対応・管理プログラム25は、ユーザ対応・管理データベース47より読み込んだデータを基に
図37の工程図画面240を作成し、情報端末に表示する。
図37の工程図画面240では、例えば異なる時刻にネットと実店舗とで注文を受けた3つの商品が、時系列に完成に向けて進行する様子が描かれている。工程図画面240には現在処理中の案件が受注した日時順に左方より表示されている。
【0137】
商品aの工程には例えばネットで注文されたユーザαの商品である旨が表示される。また、商品b、商品cの工程にはそれぞれテーブル番号3番、6番のユーザの注文である旨が表示される。商品a、b、cの工程図は時間の経過と共に左側にシフトする。
図37の例では、現在時刻に商品a、b、cが仕掛かっている。商品a、b、cのそれぞれの工程の長さは、各商品毎に予めA店により設定された製作時間に対応した長さになっている。但し、製作時間を無視して同じ長さで受注日時順に表示されてもよい。長さは短くても良い。
【0138】
簡単のためにA店での最大注文件数は3件であるとして説明する。この場合、4件目の注文からは待機案件欄250に入る。停止/再生ボタン241をクリックすると工程図をその位置で固定できる。例えば、製作作業を一時停止するような場合に使用する。もう一度クリックするとその時点から動作する。記録・再生ボタン243をクリックすると工程の流れの記録ができる。これにより、後から工程のチェックや設定の見直しができる。また、スクロールバー245のノブ245aを左右に移動させると商品a、b、cの工程が連動して左右に移動する。例えば、製作が遅れそうな場合にはノブ245aを右に移動させて調整する。製作が早く終わりそうなときにはノブ245aを左に移動させて調整する。スクロールバー245の矢印ボタン245b、245cは、クリックするとその方向にノブ245aが予め定めた単位時間分移動する。
【0139】
そして、製作が完了したら、完了した商品を左方向にドラッグ&ドロップすると完了マークが一瞬出てその後データが画面より消える。この点、工程図画面240の左側に完了箱を表示し、そこにドラッグ&ドロップするようにしてもよい。完了した商品はユーザ対応・管理データベース47に完成した商品として保存される。このとき、同時に待機案件欄250では、ユーザ対応・管理プログラム25が次に待機している商品dが抽出される。このため、
図38に示すように、この待機案件欄250からは商品dが消える。そして、この商品dは工程図画面240に商品aの工程が消えたその商品aの後ろに続くように表示される。従って、A店では商品作成の工程の管理ができる他、次に作るべき商品や待機している商品が分かる。
【0140】
商品の製作工程については、強制的な割り込みをかけることができる。例えば
図38に示すように、商品fは本来商品eよりも後の注文である。しかしながら、事情により商品fを早く製作したいときには、商品fを待機案件欄250より現在処理中を示す工程図画面240に向けて左側にドラッグ&ドロップする。これにより、
図39に示すように、自動的に商品dに代えて商品fが入る。そして、商品dは逆に待機案件欄250に戻る。このため、待機案件欄250では商品dが依然次の待機となる。
【0141】
次に、商品をまとめて作成する場合について説明する。同じ商品や類似した商品を複数人分まとめて一度に作れるときにはまとめての処理をする。例えば、同じ醤油ラーメンを5人分一度にまとめて作成する。あるいは、トッピングの異なる類似のラーメン同士を一度に作成する等の場合である。
図40において、例えば、商品d1、d2、d3がすべて同じ種類の醤油ラーメンであり一度に作成ができる場合には、ユーザ対応・管理プログラム25は待機案件欄250にある商品d1、d2、d3を待機案件欄250から消す。そして、工程図画面240に商品d1・d2・d3のまとめた工程として移す。このとき、A店では商品d1、d2、d3の3個分を一気にまとめて作成する。A店の場合、一度に作成ができる件数は、ユーザ対応・管理データベース47では5個と設定されているので3個までならばまとめて作成が可能である。このとき1個同じ商品を追加で作成するとどの程度時間が増加するかを設定してもよい。例えば、1個追加だと1分時間が増加し、2個追加だと2分時間が増加する・・等である。なお、実店舗では、商品の完成を決済と連動させるようにしてもよい。ユーザ対応・管理プログラム25は商品の注文状況が分かるので、ネットと実店舗の売上の合計金額が直ぐに出せる。
【0142】
次に、配達やテイクアウトの処理について説明する。
配達については、
図41に示すように、各商品の完了予定時刻が工程図から分かるので、ユーザ対応・管理プログラム25が空いている配達員に完了予定時刻を通知する。なお、テイクアウトの場合には、ユーザに対して商品の完了予定時刻を通知する。配達の場合、配達員はその完了予定時間までに商品の受取りに店に行けば良い。ユーザ対応・管理データベース47には地図データを予め保存し、ユーザ対応・管理プログラム25がA店の地図上の位置と配達先であるユーザの住所とから地図上の距離を読み取り、この距離から配達時間を推定して注文をしたユーザに対し到着予定時刻を知らせることも可能である。商品の完了予定時刻と配達予定時刻とを通知してもよい。上述した商品の完了予定時刻と配達予定時刻の演算は、
図31のステップ219に示す演算方法の一態様に相当する。
これにより、ショップは簡単にデリバリー等の仕組みを導入できる。また、ネットでの注文のみならず実店舗での注文についても工程管理ができる。
【0143】
次に、ショップのwebページを外国人に向けて公開するときの処理について説明する。
図42に、ユーザである外国人向けに、webページで掲載のテキストの原文と翻訳文の対訳で、商品詳細ページの内容を示した例を示す。
図42において、商品詳細ページ260には、画像1と画像2の間に日本語の原文1と原文2、画像2と画像3の間に原文3、画像3の下に原文4が記載されている。商品詳細ページ260はショップが自身のサーバーで公開しているページである。サーバーには提供先ショップ1のサーバー7、提供元ショップ2のサーバー4が含まれる。原文1と原文2とは文章としては連続しており、原文1と原文2の間に線等によるデザイン的な仕切りは設けられてない。商品説明文261中には、センターサーバー6が生成する原文と翻訳文との対訳の掲載された商品詳細ページ270に進むためのリンクボタン263と、外国人向けのwebページが用意されていることを案内するコメント文265が埋め込まれている。このリンクボタン263とコメント文265は、ステップ153やステップ185で説明をした通りの方法で、商品データ解析プログラム23により商品説明文261中に埋め込まれたものである。そして、商品詳細ページ260は、センターサーバー6よりこの商品データの提供を受けたショップサーバーのwebページ作成部が作成したものである。なお、コメント文265やリンクボタン263は、アイコンとしてコメントを記載してもよい。
【0144】
商品詳細ページ270に掲載の画像1、2、3及び原文1、2、3、4は、商品詳細ページ260に掲載のものを転載したものである。原文は、基本的には商品詳細ページ260のhtmlのソースコード中に記載されている改行記号の存在箇所で区切る。また、画像の箇所でテキストを分ける。但し、改行記号までの行数が予め設定をした行数を超えているような長文の場合には、予め設定をした数行程度の次に初めて出現する「。」の存在箇所で区切ることが望ましい。
原文1の下段にはセンターサーバー6で機械翻訳された翻訳文1が配設される。
この機械翻訳はリアルタイムに行っても良いし、センターサーバー6に訳文として保存されているものを抽出して掲載しても良い。リアルタイムの場合には、ボタンで要求のあった商品についてだけ翻訳が行われるので、センターサーバー6の翻訳に対する負荷が軽くて済む。
但し、翻訳文1は人が一部若しくは全体を翻訳するようにしてもよい。商品詳細ページ270に掲載の画像と原文の出現順序は、商品詳細ページ260のhtmlのソースコード中の画像と原文の出現順序と同じになるように掲載することが望ましい。但し、画像だけ、あるいは原文だけをまとめて掲載してもよい。また、
図42の例では対訳は同一ページ内の縦方向に原文と翻訳文が並ぶようにしているが、原文と翻訳文とを縦の間仕切り線を隔てて左側と右側に並べるようにしても良い。この場合、原文1と翻訳文1の先頭行の位置、原文2と翻訳文2の先頭行の位置・・・等は、対比し易くするため同じ高さにすることが望ましい。そして、「カートに入れる」ボタン271がクリックされると、センターサーバー6で用意した購入処理に進む。
【0145】
また、商品説明文261中若しくは商品詳細ページ270には、ユーザの使用したい言語が選択可能なように選択ボックス267が配置されてもよい。そして、ここで選択された言語について翻訳文が生成される。言語は一度選択されればその言語に維持されるのが望ましい。なお、選択ボックス267で言語が選択されたときには直ちにその言語で作成された商品詳細ページが表示されてもよい。
なお、上記では、商品詳細ページ270をセンターサーバー6が生成してユーザの情報端末に表示するとして説明したが、原文と翻訳文の対訳についての商品データは、センターサーバー6で生成しショップ側に提供し、この商品データをショップサーバーが商品詳細ページ260のデザインテンプレートに流し込んでwebページを作成しユーザの情報端末に表示するようにしてもよい。この場合、ステップ153やステップ185で説明したのと同様に商品データ解析プログラム23がショップの商品データに対して、翻訳文と購入ボタン、コメントを埋め込む。翻訳文は
図42のように原文のブロックに対応させて原文のブロックと翻訳文のブロックを並べて表示してもよいが、ブロックに分離せずに商品説明文261中の最下部にまとめて配設してもよい。ここで埋め込まれた購入ボタンがクリックされた場合にはセンターサーバー6での購入処理が動作するが、購入ボタンはセンターサーバー6では埋め込まずに、ショップの購入ボタン101で購入されるようにしてもよい。
ブロック毎に原文と翻訳文とが対訳とされることでユーザは見易く、情報に対する判断を的確に行うことができる。
なお、原文と翻訳文のユーザへの見せ方については、センターサーバー6で生成した商品詳細ページには翻訳文のみをまず掲載する。そして、この商品詳細ページ中の適所に対訳ボタンを配置して、これがクリックされたら商品詳細ページ270に示すような原文と翻訳文の対比文が表示されるようにしてもよい。この際、例えば原文の方には背景色を付け、一方、翻訳文の方はそのまま白色で掲載すると見易い。
以上の処理を行うに際しては、ショップ側でのシステムの改造は不要である。また、外国人向けの処理として、海外からのアクセスに限らず、国内にいる外国人に対しても利用が可能である。
なお、
図30の例やデリバリーボタン173の例で説明したように、コメント文265やリンクボタン263はホームページの適所に配設されても良い。更に、コメント文265やリンクボタン263は、相互販売、提携販売、モール化が行なわれている提供先ショップ1と提供元ショップ2の各商品詳細ページに対して配設されても良い。このコメント文265については、外国人がこの商品を購入可能である旨のメッセージの他、この商品が提供元ショップ2から発送される旨のメッセージ、この商品が輸出禁制品である旨のメッセージ、ライブコマースを開催する旨のメッセージ等を掲載可能である。また、複数のメッセージを含めて記載されてもよい。
このメッセージは、センターサーバー6の管理画面において、ショップがテキストボックスに文字入力することで内容を編集可能である。あるいは、予め用意されたテキストを選択するようにしてもよい。このメッセージがセンターサーバー6により詳細文中に埋め込まれる場合には、ショップ側での改造は不要である。一方、このメッセージがホームページの適所に配設された場合には、必要なスクリプトがソースコードとして提供され、ショップ側が商品詳細ページ中に埋め込む。このメッセージは、商品毎に編集可能としてもよいし、すべての商品について共通したものとしての編集もできることが望ましい。
【0146】
次に、ショップの商品データを外国人が検索可能とする処理について説明する。
図43において、ショップの既存のwebページ280には検索入力欄281と検索ボタン283が掲載されている。これに隣接してリンクボタン285を配設する。また、言語選択ボックス267を配設するのが望ましい。リンクボタン285がユーザによりクリックされると、センターサーバー6で作成され、センターサーバー6より提供される検索ページ290に遷移する。ユーザが検索入力欄291に所定の言語で入力し検索ボタン293をクリックするとセンターサーバー6のデータベース30が検索され、検索ページ290に検索結果リストが表示される。所定の言語は、言語選択ボックス267で選択された言語であることが望ましい。
なお、ステップ151やステップ181で収集されたすべての商品の商品名や説明文は、対象となる少なくとも一つの言語に翻訳してセンターサーバー6のデータベース30に保存しておく。但し、商品名のみが翻訳されてもよい。
しかし、検索入力欄281、291に入力されたキーワードがセンターサーバー6で翻訳語に翻訳されてその翻訳語について検索がされるようにしてもよい。検索入力欄281、291に日本語でキーワードが入力され、センターサーバー6で外国語に翻訳されてから検索が行われてもよいし、外国語でキーワードが入力され、センターサーバー6で日本語に翻訳されてから検索が行われてもよい。
この場合、全ての商品データについての翻訳をしないで済むのでセンターサーバー6の翻訳に対する負荷が軽くて済む。また、日本語の単語と外国語の単語とが1対1の関係で無く、複数の候補が出現した場合には、ユーザに対しこの候補を示し、選択をさせることが望ましい。そして、このユーザにより選択されたキーワードについて、センターサーバー6のデータベース30に対し検索が行われる。検索は商品名のみについて行なわれるようにしてもよい。
検索結果リストはwebページ280若しくは検索ページ290に配設された言語の選択が可能な選択ボックス267で選択された言語で表示されてもよいし、日本語で表示されてもよい。言語は一度選択されればその言語に維持されるのが望ましい。但し、言語の選択が無くても、検索入力欄に入力されたキーワードで言語の種類を判断し、その言語について検索されてもよい。検索結果に表示された商品名295をクリックすると商品詳細ページ270が表示される。検索入力欄281、検索ボタン283、リンクボタン285、言語の選択ボックス267は、webページ280に埋め込まれたスクリプトにより生成されたポップアップ画面に配設されてもよい。
【0147】
次に、ショップの既存のwebページから直接外国人が検索可能とする処理について説明する。
図44に示すショップの既存の商品詳細ページ300の商品説明文301中には、直接外国人が自国語で検索が可能な検索入力欄303と検索を行うための検索ボタン305、コメント文307が埋め込まれている。言語の選択ボックス267が埋め込まれても良い。このコメント文307はテキスト又は画像で構成され、検索入力欄303に所定の言語でのキーワードを入力し、検索ボタン305で検索ができることが表示されている。検索入力欄303に所定の言語でキーワードが入力され、ユーザにより検索ボタン305がクリックされると、センターサーバー6のデータベース30に保存されている商品データがこのキーワードで検索される。そして、検索された結果が検索結果リストのwebページとしてセンターサーバー6で生成される。
【0148】
また、商品説明文301中にはパンくずリスト309を掲載することもできる。そして、このパンくずリスト307をユーザがクリックすると、一覧ページ等にリンクできるようになっている。この一覧ページはショップサーバーで作成されたwebページであってもよいが、センターサーバー6で作成されたwebページとすることもできる。
この検索入力欄303、検索ボタン305、コメント文307、選択ボックス267、パンくずリスト309は、ステップ153やステップ185で説明をした通りの方法で、商品データ解析プログラム23により商品説明文301中に埋め込まれたものである。そして、商品詳細ページ300は、センターサーバー6よりこの商品データの提供を受けたショップサーバーのwebページ作成部が作成したものである。
検索入力欄303、検索ボタン305、コメント文307、選択ボックス267、パンくずリスト309は商品説明文301中の下部に埋め込まれても良い。但し、この場合、コメント文307だけはメッセージを目立つ箇所に配置するために上部に残しても良い。
なお、商品説明文261や商品説明文301中にはポップアップ画面を生成するスクリプトを埋め込み、リンクボタン263、コメント文265、言語の選択ボックス267、検索入力欄303、検索ボタン305、コメント文307、パンくずリスト309等を含むポップアップ画面が生成されてもよい。
ショップが相互販売、提携販売、モール化を行っている提供先ショップ1の場合、センターサーバー6では、すべての提供元ショップ2の商品データを翻訳してもよいが、希望する提供元ショップ2の商品データのみを翻訳してもよい。また、希望する提供元ショップ2の商品データの商品詳細ページにのみ、翻訳用のコメント文265、リンクボタン263、リンクボタン285や、検索入力欄303、検索ボタン305、コメント文307、パンくずリスト309等を埋め込むようにしてもよい。以上の処理を行う場合でもショップ側でのシステムの改造は不要である。
【0149】
次に、外国人が検索を行う際に的確な訳語での検索を可能とする方法について説明する。
図45に示すように、詳細文中の原文である日本語の文章は、例えば、句点「。」毎に範囲を区切る。そして、各範囲毎に連番符号311を付す。その範囲の文章に対応する外国語の訳文についても同じ符号313を付す。商品名についても同様である。詳細文と商品名はデータベース30より抽出されてもよいが、リアルタイムにショップの商品詳細ページより抽出されてもよい。
符号313にはセンターサーバー6へのリンクが貼られており、符号313がクリックされたときにはセンターサーバー6側でどの箇所の文章が選択されたのかが分かるようになっている。そして、訳文の符号313がクリックされたとき、その符号313に該当する箇所の原文である日本語の文章が、
図46に示すように分節や用語毎に分離され、ホームページ上に選択自在に表示される。この際、原文である日本語と訳語との対応する分節や用語同士については、同じ背景色が施されて表示されることが望ましい。但し、同じ背景色に限るものではなく、同じ数字や符号等が施されて表示されてもよい。そして、各日本語の分節や用語の頭には、チェックボックス315が設けられている。商品名についても同様である。
【0150】
チェックボックス315が指定されると、この指定された日本語の分節や用語が自動で検索入力欄に入る。但し、指定された日本語の分節や用語がクリップボードに入るとされてもよい。この際の指定は、訳語と同じ背景色の付された日本語の用語を指定すればよいので簡単である。但し、訳語側を選択することで、対応する日本語の分節や用語が自動で検索入力欄に入るようにしてもよい。また、訳語側が選択されたときに、対応する日本語の分節や用語が目立つ色や枠で囲まれて表示されるようにしてもよい。この日本語の分節や用語で良ければこれを選択する。あるいは、日本語側と訳語側の両方を選択可能としてもよい。日本語の分節や用語が複数選択されたときには検索入力欄にオアで入る。
検索ボタンが押されると日本語のデータベースについて検索が行われる。検索結果は検索結果リストとして表示がされるが、このとき外国語での翻訳文をデータベースから抽出して表示してもよいし、リアルタイムに外国語に翻訳をして表示してもよい。
仮に、翻訳について対応関係が明確でない用語や対応関係の欠落した用語、同じ用語としての背景色が施されていない状況が含まれている場合や、色の付されていない歯抜け状態の用語があったとしても、隣接する対応色同士で囲まれた狭い範囲内に存在する用語を指定することで、外国人であっても文脈の中での妥当な日本語の用語を選択可能である。
このことにより、外国人は文章の中から妥当な用語を選択して検索ができるので簡単である。この用語は、文章として把握された形の中で翻訳されている用語なので、用語の翻訳精度は高い。従って、精度の高い日本語での検索が行える。また、日本語のデータベースに対する検索で済み、検索負荷は少ない。
【0151】
なお、先述したように、センターサーバー6で生成した商品詳細ページには翻訳文のみをまず掲載する。そして、この翻訳文には各範囲毎に連番符号313を付しておく。符号313がクリックされたときには同様に符号311の付された日本語文章の対訳が出る。この日本語文章の分節や用語の頭には、チェックボックス315が設けられているとされてもよい。
また、上記した外国人による検索方法は、パソコンやスマートフォン向けのアプリケーションプログラムとして提供されてもよいし、ブラウザに対するプラグインアプリケーションとして提供されてもよい。
【0152】
次に、販売店リストを介して外国人が商品を購入可能とする処理について説明する。
図47に示すように、商品詳細ページの適所に配設された、前述の海外発送対応可能である旨や外国人が購入可能である旨のリンクやボタンがクリックされたり、言語選択ボックス267で言語が選択されたとき、あるいは、IPアドレスを解析することで、外国人による購入や海外からのアクセスであると判断されたとき、販売店リスト317には外国人購入ボタン319若しくはリンクやアンカーテキストが、現地ショップ若しくはこのショップの商品を掲載する商品詳細ページに進むリンクとは別に表示される。但し、この判断によらず、販売店リスト317には最初から外国人購入ボタン319が配設されてもよい。そして、外国人購入ボタン319若しくはリンクやアンカーテキストがクリックされたときには、この選択されたショップに対する外国人購入用の商品詳細ページが開かれる。但し、商品詳細ページを開くとはせずに、直接購入処理を動作させてもよい。また、この外国人購入用の商品詳細ページや購入処理はセンターサーバー6で作成し開示するが、外国人購入ボタン319若しくはリンクやアンカーテキストを表示するページについても、センターサーバー6で作成し開示してもよい。
【0153】
ショップが相互販売、提携販売、モール化を行っている場合には、提供先ショップ1と提供元ショップ2の各商品詳細ページに表示される販売店リスト103、115に対して、外国人購入ボタン319若しくはリンクやアンカーテキストが表示される。
但し、販売店リスト103、115から個別商品の詳細ページに進み、そのページに配設されている外国人購入ボタン若しくはリンク263やアンカーテキストが利用されるようにしてもよい。販売店リスト103、115は、商品データ解析プログラム23がまとめたものである。
しかし、この処理は、いわゆる価格比較サイトに掲載の図示しない販売店リストに対して適用することも可能である。そして、前述したように、販売店リストを掲載している商品詳細ページの適所に外国人が購入可能である旨のリンクやボタン、あるいは、言語選択ボックス267を配設し外国人購入用の処理を行なう。このことにより、外国人が容易に商品を販売するショップを見つけたり、最安の商品を見つけての購入ができる。
この販売店リストについても、パソコンやスマートフォン向けのアプリケーションプログラムに提供されてもよいし、ブラウザに対するプラグインアプリケーションで提供されてもよい。
【0154】
次に、上記した相互販売、提携販売、モール化や多様化を含むサービスをショップに対して効率良く導入する方法について説明する。
まず、ショップにとっての導入の効果を予測するために、ショップの商品販売や商品購入需要面についての現時点での状況評価を行う。そして、この評価を行うに際しては、事前にそれぞれの商品毎に購入データを解析し、基本属性を算出する。即ち、POSデータやクレジットカード、ポイントデータ、キャッシュレス決済等の決済データに基づき商品毎に基本属性を解析しておく。この基本属性は、商品毎に、どのような属性の人が購入したのかを解析したデータである。この基本属性は、一つの同じ商品についての購入データを多くのショップから集めて、この商品を購入した人の属性に紐付けて解析したデータである。属性は、例えば、年齢層、性別、趣味嗜好、業種、用途、国内需要若しくは海外需要、購入者数、売上高、訪問者数、海外訪問者数等である(以下、同旨)。この属性には、後述するアクセス解析ツールを用いて得られたデータを加えても良い。
【0155】
基本属性を解析するには、
図48に示すように、同じ商品1について、多数のショップにおける購入データを集めて解析を行う。
図48の例は、この商品1を購入した購入者の性別と年齢層についてまとめたデータ例である。この商品1は、全国のショップで10,000人の人によって購入されたと仮定する。POSデータ等の解析結果から、購入者の性別は90%が女性で、また、年齢層で見ると20代の人が1,000人購入をしているので、20代の人の購入率は10%であることが分かる。属性に基づく解析は、他に趣味嗜好、業種、用途、国内需要若しくは海外需要、海外訪問者数等について行っても良い。趣味嗜好としては、例えば、山好きの人、海好きの人、ゲームの好きな人、読書の好きな人、体を動かすことの好きな人、音楽好きな人等である。業種は事務、技術、営業等である。用途は若い女性向け、年配者向け等である。
【0156】
図48において、年齢層に基づく購入者数の解析結果は、理解し易さのために正規化をしている。商品1の年齢層毎の正規化データは例えば
図48に示すように、10代が10%、20代が10%、30代が20%、40代が20%、50代が30%、60代が10%である。そして、
図48には、この正規化されたデータに基づき、商品1についての基本属性グラフ321が作成されている。このように算出された年齢層毎の正規化された基本属性データは、商品1以外の多くの商品についても同様に解析が行われる。そして、これらの解析結果のデータはセンターサーバー6に保存される。但し、センターサーバーは独立したものとしてもよい。
【0157】
次に、この基本属性データを用いて、各通販ショップ毎に販売属性を求める方法について説明する。販売属性とは、この通販ショップがどういう属性(例えば年齢層や性別等)の人に向けた商品、あるいは、どういう属性の人に受ける商品を通販サイトに掲載しているのかを分析したものである。但し、販売属性は、通販ショップのジャンルについて分析されてもよい。
販売属性を求めるに際しては、まず、通販ショップ1について取り扱われている商品データをホームページから収集、若しくはCSVファイルで収集する。この通販ショップ1は提供先ショップ1や提供元ショップ2、若しくはこれらの候補ショップに相当する。そして、この通販ショップ1に属する商品毎に上記の商品毎の正規化された基本属性データを読み、集計する。例えば、簡単のためにこの通販ショップ1では、商品1、商品2、商品3の3品を自店の通販サイトに掲載していると仮定する。そして、
図49に示すように、これら3品の商品の基本属性をセンターサーバー6より読み、属性が年齢層の場合には各年齢層毎に小計する。
【0158】
図49の例では、10代については、商品1の基本属性10%と商品2の基本属性5%と商品3の基本属性5%をセンターサーバー6より読み小計すると20%となる。同様に、他の年齢層についても集計をする。そして集計後に正規化すると、通販ショップ1の年齢層毎の正規化データは、例えば
図49に示すように、10代が7%、20代が8%、30代が12%、40代が33%、50代が27%、60代が13%となる。そして、この正規化されたデータに基づき、
図49には通販ショップ1の年齢層についての販売属性グラフ323が作成される。販売属性グラフ323を見ると、この通販ショップ1では、40代-50代のユーザをターゲットにした商品が多く掲載された通販サイトであることが分かる。
なお、販売属性として、この通販ショップ1における売れ筋商品の取り扱い率、利益率の高い商品の取り扱い率を算出し、販売属性グラフ323と共にグラフ表示してもよい。ここに、売れ筋商品の取り扱い率とは、この通販ショップ1が取り扱っている商品の内の売れ筋商品として一般的に認識されている商品件数のこの通販ショップ1の全商品件数に対する割合である。利益率の高い商品の取り扱い率とは、この通販ショップ1が取り扱っている商品の内の利益率が高いと想定される商品件数のこの通販ショップ1の全商品件数に対する割合である。
【0159】
次に、各ショップ毎の購入属性を求める方法について説明する。
購入属性とは、このショップやジャンルでは、実際にどういう属性(例えば、年齢層、性別等)の人が購入する可能性が高いのか、その購入需要を属性について分析した特性である。購入属性は、例えば通販ショップ1が導入しているPOSデータやクレジットカード、ポイントデータ、キャッシュレス決済等の決済データに基づき
図50のように解析を行う。即ち、通販ショップ1での購入データを分析し、求めたい属性が年齢層の場合には、10代の購入者数が100人、20代の購入者数が400人・・等と年齢層毎の購入者数の分析を行う。そして、その結果は購入属性グラフ325に作成される。見易さのために正規化をしているが、正規化しなくてもよい。
【0160】
この購入者数を基に年齢層毎の訪問者数を推定する。訪問者数を推定するに際しては経験値若しくは実測値からデータ変換を行う。例えば、一般的に訪問者数のα%が実際に購入したとすると、購入者数÷α%で通販ショップ1のサイトの訪問者数を推定することができる。ジャンル毎の購入者数を求めれば、同様にジャンル毎の訪問者数を推定することができる。α%は一定のものではなく、環境因子や取引状況等如何で実情に即して補正されることが望ましい。
また、上記は、POSデータやクレジットカード、ポイントデータ、キャッシュレス決済等の決済データを基に訪問者数を推定するとして説明したが、ブラウザのプラグインや管理ツールとして解析されたデータを用いて訪問者数を得るようにしてもよい。これには、例えば、グーグルアナリティクス等のwebサイトのアクセス解析ツールを用いた解析があげられる。趣味嗜好等の属性についても同様に取得してもよい。このようにアクセス解析ツールを用いて得られた属性データは、POSデータ等から得られた属性データと共に用いられても良い。一方の属性データの取得が難しかったり、不確実性の高い場合には、他方の属性データを用いるというようにしてもよい。購入属性は、通販ショップ1で商品購入のされた人数をまとめた購入者属性と、通販ショップ1を訪問した訪問者の数をまとめた訪問者属性とに分けるようにしてもよい。
【0161】
また、通販ショップ1では実際の購入者の数が少なかったり、POS等の導入をしたばかりのようなときには十分な購入データがない。このような場合には、購入属性についても販売属性を算出したのと同様の方法で算出し推定値とする。即ち、通販ショップ1で実際に購入のあった商品データに対して、商品毎の正規化された基本属性データを読み、集計する。これにより、一般的な購入属性の傾向として利用できる。
また、ジャンル毎の訪問者数を次のように推定してもよい。ジャンル毎の購入者をPOSデータ等より年齢層毎に分析する。この分析データを基にジャンル毎の各年齢層毎の購入者数を求める。このデータを基に上記と同様に購入者数÷α%でジャンル毎の年齢層毎の訪問者数を推定する。但し、この場合のα%は、ジャンル毎の経験値若しくは実測値に基づく数値を採用することが望ましい。
【0162】
次に、購入属性と販売属性を基にショップの売上増加に繋げる方法について説明する。
購入属性は購入者数を基に作成したグラフであるが、POSデータ等から算出した購入者数を基に訪問者数を推定した場合には、購入者数と訪問者数とは補正をしない段階では比例関係にあるので、購入属性のグラフは訪問者数のグラフと同じ特性となる。この場合には、購入属性のグラフを訪問者数のグラフと言い換えることができる。
図51には、訪問者数を現す購入属性に対しK人のしきい値を設定した例を示す。Kの値は例えば月間5万人であり、実情に即して適宜変更可能な値である。
図51では簡単化のために20代の年齢層についての購入属性のみを示し、他の年齢層の購入属性は省略している。
図51では、20代の訪問者数がK人のしきい値を超えている例を示している。この場合、20代のユーザの購入需要が高いと推測できる。購入属性を購入者属性と訪問者属性とに分けた場合には、K人のしきい値はそれぞれに設定される。
【0163】
一方、
図51には同じ20代の年齢層についての対比として販売属性も示している。この販売属性のしきい値としてS%を設定する。Sの数値の設定方法は、例えば、
図49に示す属性毎の正規化欄の数値の平均値をとり、その平均値のβ倍とする。βの値は例えば1.5である。また、このSの数値の別設定方法として、
図51に示すように、各年齢層の中で20代が最大のピーク値を有していると仮定したときに、このピーク値の例えばS%を販売属性のしきい値として設定する。Sの値は例えば60である。この販売属性のしきい値や、その設定方法についても適宜実情に則して変更が可能である。そして、
図51の例では、20代の販売属性がしきい値であるS%を超えているので20代での販売属性が強いと判断できる。即ち、20代向けの商品を多く取り揃えたショップであると判断できる。
【0164】
図51の例のように、20代の訪問者数がK人のしきい値を超え、かつ、20代の販売属性がしきい値であるS%を超えている場合には、この20代について販売属性と購入属性との特性の傾向が共にしきい値超えで一致している。このため、このまま通販ショップ1の販売を継続しても20代の売上について収益が見込めるため問題はない。しかしながら、このように20代の訪問者数が多いことから、この特性を生かして、例えば20代のユーザの少ない他店の商品を、相互販売、モール化、提携販売を通じて売ってあげることを考慮してもよい。
また、20代に基本属性の強い商品を、通販ショップ1の通販サイトに追加掲載することを提案することができる。この提案は、商品データのサイトへの追加の提案であってもよいが、実際にその商品の仕入れを提案してもよい。基本属性の属性を判断するに際しては、属性の種類により、同じ属性を有するか否かで判断したり、あるいは、同じ属性で所定のしきい値を超える等の強さを有するか否かで判断することが望ましい。また、同じ属性を有する、あるいは、しきい値を超えている商品の内の過去に売れている商品の類似商品や、一緒に使用される目的の商品等の仕入れを優先的に提案してもよい。
【0165】
通販ショップ1の属性を解析し評価することで、そのショップ特有の属性にあった商品を仕入れることができる。この際には、売れ筋商品を提案したり、利益率の高い商品を仕入れることを提案してもよい。利益率、販売金額が想定できれば、通販ショップ1についての売上金額の増分や利益金額を算出したり表示することもできる。仕入れの商品候補として複数の商品を表示してもよい。
また、このように20代の購入需要が高いサイト同士であったとしても提携を提案してもよい。このとき、互いの有する商品が相違する場合には、相互販売等により商品の充実が図れ、販売増にも繋がる。一方、互いの有する商品が重複する場合には販売店リストを作成してもよい。この場合、ニッチな商品群(例えばいわゆるロングテール商品等)、売れ筋商品を選択してバランスよく提案することが望ましい。通販ショップ1の有するジャンルとは異なる新規ジャンルの作成を提案してもよい。
【0166】
なお、提携候補先は複数を提案してもよい。提携候補先のショップや、サイトに追加する商品データ、仕入れ候補の商品は自動での検出が可能である。属性に基づき検出する場合には、年齢層と性別の組み合わせ、年齢層、性別、趣味嗜好、人数、商品数、売上高等のように複数の属性について絞り込みや検索をしてもよい。この属性は、演算により得られたデータ、アクセス解析ツールから取得したデータ、後述するようなショップにより入力されたデータに基づいてもよい。
更に、通販ショップ1の販売属性が
図49、購入属性が
図50である場合には、
図50から分かるように、通販ショップ1の40代から50代の購入属性が弱いので、通販ショップ1に対しては40代から50代向けの商品の販売の得意な提供先ショップ1と提携をして商品を売ってもらうことを提案できる。この提供先ショップ1の候補は、40代から50代の購入属性がしきい値以上のサイトで見つけることが望ましい。提供先ショップ1の候補は自動での検出が可能である。
【0167】
一方、
図50から分かるように、通販ショップ1の20代から30代向けの商品の購入需要が高いのだから、他のショップでこの年齢層の販売の不得意なショップの商品を提供先ショップ1として販売してあげることができる。このときの提携先となる提供元ショップ2の候補としては20代から30代向けの商品の購入属性が弱いサイトである。このサイトが20代から30代の販売属性が強いサイトであればより一層望ましい。20代から30代向けの商品が集まっている可能性があるためである。候補となる提供元ショップ2は自動での検出が可能である。属性の判断は、より細かく20代から30代の女性向け等として判断されてもよい。販売属性と購入属性の各グラフは、男性と女性とについて分けて年齢層毎に作成されてもよい。
しかし、提供元ショップ2の候補は必ずしも購入属性が弱いサイトに限定する必要はない。購入属性が強いサイトを提供元ショップ2としてもよい。
【0168】
また、このように20代から30代向けの商品の購入需要が高い通販ショップ1に対しては、20代から30代向けの商品を実際に仕入れることを提案してもよい。20代から30代向けの商品であることは、商品の基本属性の属性(年齢層の20-30歳の部分)が所定のしきい値を超えていることで判断できる。この際には、利益率の高い商品や購入率の高い商品(売れ筋)を商品候補として複数提案し、選択した商品を仕入れるようにしてもよい。20代の女性等、他の属性(女性等)も加味して判断されてもよい。
なお、図示はしないが、購入属性(あるいは訪問者数)のピーク値が全年齢層について常にK人のしきい値未満の場合には、全年齢層について購入属性の良好な提供先ショップ1で売ってもらうことが売上増加に繋がり望ましい。
一方、購入属性(あるいは訪問者数)の下限値が全年齢層について常にK人のしきい値以上の場合には、全年齢層について訪問者数がK人以上で購入属性が良好な状態なので、提供先ショップ1として提供元ショップ2の全商品を販売してあげることができる。
また、
図52には、モール化を図ったE店に対してF店、G店、H店を提携ショップとして加える例を示す。
図52に示すように、E店の販売属性での弱点部分が広範囲であったとしても、F店、G店、H店の提携ショップの販売属性の突出した特徴部分により弱点が補える。
更に、
図53には、ショップやジャンルの特徴を相互販売等の提携により一層強化させた例を示す。
図53において、I店の販売属性や購入属性はもともと突出した特徴を有しているが、J店との提携により、点線で示すようにこの特徴を倍増させることができる。
【0169】
また、提供先ショップ1の候補や提供元ショップ2の候補は、自店が提携を希望する相手先ショップの特徴やテーマ等の属性を、
図54に示すように管理ツールにて指定することで絞り込みや検索が可能である。同様に、サイトに掲載や仕入れを希望する商品について、あるいは、ジャンルについても属性について絞り込みや検索が可能としてもよい。
図54において、「通販サイトのテーマ」327は選択自在な選択ボックスとしてもよいし、テキスト入力が可能としてもよい。提供先ショップ1の候補や提供元ショップ2の候補は、ショップで選択されたテーマにより自動的に絞られた形で表示される。テーマは例えば、産直、地域、ブランド、特産、地酒、サイズに特化したファッション、現金値引等である。テーマはショップ側にて選択してもよいが、運営者側にて選択されてもよい。
【0170】
更に、
図54の年齢層選択329に示すように、自店が提携を希望する相手先ショップの年齢層を選択できるようにしてもよい。そして、選択した年齢層は、希望する年齢層の順に優先順位を付けるようにしてもよい。この場合には、選択された年齢層により提供先ショップ1の候補や提供元ショップ2の候補が絞られる。但し、この年齢層は、購入属性と販売属性とに分けて選択可能とされてもよい。
同様に、性別選択331、趣味嗜好選択335、業種選択337、用途選択339、サービス選択341等での指定も可能である。また、訪問者数設定333では、希望する提携相手先のショップの訪問者の全体人数と年齢層毎の人数が指定可能なようになっている。ジャンル毎の人数を指定可能としてもよい。なお、図示はしないが、希望する提携相手先のショップの商品数や売上高を指定可能としてもよい。但し、選択されたデータは、このように候補を絞るために用いるのではなく、全体のショップデータからの絞り込みのために利用されてもよい。
【0171】
また、上記では、
図54で提携相手先に求める属性等を指定するとして説明したが、かかる指定は、自店の特徴、テーマ等を示す属性データとして、他のショップによる検索が可能なように自店側についての情報の登録が可能とされてもよい。自動での属性データの算出がうまくできないようなケースについては、ここで手動登録をされたデータが検索に用いられても良い。
相互販売、提携販売、モール化で相手側のショップと提携をしようとする際には、この相手側に対する提携の条件として購入属性のK値を指定したり、販売属性のS%を指定することができる。例えば、相手側のショップに対し、同じ属性aについて購入属性が月間2万人未満で、かつ、販売属性は50%以上であることを希望する。あるいは、購入属性については条件を指定しないが、すべての属性(例えは年齢層)について、販売属性が60%以上であることを希望する等である。候補ショップが複数件検索結果に表示されたときには、この候補ショップに対して更に別の属性bで絞るようにしてもよい。また、ジャンル毎に購入属性と販売属性を算出し、購入属性のK値を指定したり、販売属性のS%を指定してもよい。売れ筋商品の取り扱い率や利益率の高い商品の取り扱い率を指定してもよい。
【0172】
このように、通販サイト毎に購入属性と販売属性をまとめ、対比等による評価をすることで、通販サイトの購入需要や販売面での弱点や強い点を図表化したり明確化することができる。商品の購入需要にマッチングした商品構成になっているかを簡単に判断できる。そして、提携を希望する相手側のショップの候補を簡単に希望通りに絞り込むことができる。
これにより、通販サイトの強い面を活用して一層の販売の強化を図ったり、商品の購入需要と商品構成とがミスマッチングしていて、購入需要が弱い面については購入需要の補強をすることができ、売上増に繋げられる。
相互販売、提携販売、モール化は改造無しで行えるので、他店の商品を自店で売ってあげる、あるいは、自店の商品を他店で売ってもらうという処理が簡単に行える。同様に、処理の停止や、やり直しも簡単に行える。この処理は、ショップ単位、ジャンル単位、商品単位に行える。これにより、ショップが希望する、ショップとしての特徴部分を自由にデザインし形成することも可能となる。また、提携による商品毎の販売を試験的に行い、解析してからその後にその商品を実際に仕入れる等することもできる。この解析は属性毎に精度よく行える。従って、ショップのリスクの低減に繋がる。
【0173】
なお、前述した購入属性、販売属性により解析のされた趣味嗜好等の属性評価は、いわゆるアフィリエイト広告にも利用することができる。この場合に、アフィリエイト広告主は、購入属性、販売属性の解析結果と趣味嗜好等の一致するメディアに対し掲載をすることで効果的な広告を打つことができる。
また、海外からのアクセスである旨、ユーザの国名、アクセス数、趣味嗜好、年齢層等の属性を評価することで、外国人が商品を購入可能とする処理についても利用できる。これにより、上記した外国人購入用プログラムを導入したり、海外ユーザに受ける商品を判断できる。
更に、前述した購入属性、販売属性による解析や評価は、通販モールの参加店に対して行うこともできる。また、商品だけではなく役務サービスについても適用できる。通販ショップに限らず、実店舗についての適用もできる。
なお、本発明は、本発明の精神を逸脱しない限り種々の改変をなすことができ、そして、本発明が当該改変されたものにも及ぶことは当然である。
【符号の説明】
【0174】
1 提供先ショップ
2 提供元ショップ
3 パソコン(情報端末)
4 提供元ショップサーバー
5 スマートフォン(情報端末)
6 センターサーバー
7 提供先ショップサーバー
9 提供先ショップのwebサイト
10 インターネット
11 、51、71演算部
15 、55、75通信部
20 商品データ収集・解析部
21 巡回プログラム
23 商品データ解析プログラム
25 ユーザ対応・管理プログラム
30 センターサーバーのデータベース
31 販売店リストデータベース
33 提供元ショップデータベース
35 提供先ショップデータベース
37 提供先-提供元対応データベース
39 提供元ショップ商品データベース
41 提供先ショップ商品データベース
43 販売履歴管理データベース
45 個別商品データベース
47 ユーザ対応・管理データベース
57、77 管理部
59 提供元ショップサーバーの顧客データベース
60 提供元ショップサーバーのデータベース
61 提供元ショップ販売履歴管理データベース
63 提供先ショップ販売履歴管理データベース
65 提供元ショップ商品データベース
79 webページ作成部
80 提供先ショップのデータベース
81 提供先ショップの顧客データベース
83 提供元ショップ販売履歴管理データベース
85 提供先ショップ販売履歴管理データベース
87 提供先ショップ商品データベース
89 個別商品データベース
100、110、120、130、140、160、170、190、260、270、300 商品詳細ページ
101 購入ボタン
103、115、317 販売店リスト
113、133 提供元ショップのショップ名
141、161、171、261、301 商品説明文
143 資料請求ボタン
163、173 デリバリーボタン
165、265、307 コメント文
191 注文ボタン
201、203、205 管理画面
207 問い合わせ画面
210 注文画面
213 インクリメントボタン
217 デクリメントボタン
219 テーブル番号入力欄
240 工程図画面
245 スクロールバー
250 待機案件欄
263、285 リンクボタン
271 「カートに入れる」ボタン
280 ショップの既存のwebページ
281、291、303 検索入力欄
283、293、305 検索ボタン
290 検索ページ
309 パンくずリスト
311 原文に付す連番符号
313 訳文に付す連番符号
315 チェックボックス
319 外国人購入ボタン
321 基本属性グラフ
323 販売属性グラフ
325 購入属性グラフ