JP2023060800A

JP2023060800A - 販売支援システム

Info

Publication number: JP2023060800A
Application number: JP2022046116A
Authority: JP
Inventors: 美恵子露崎; Mieko Tsuyusaki
Original assignee: Daha Co Ltd
Current assignee: Daha Co Ltd
Priority date: 2021-10-18
Filing date: 2022-03-22
Publication date: 2023-04-28

Abstract

【課題】ネット上での取り扱いの商品や役務の件数を充実させ、売上の増大を図ることが可能で、かつ、販売形態の追加、刷新、多様化や工程管理を簡単に図れる販売支援システムを提供する。【解決手段】センターサーバーで保存された商品データについて、所定の処理を開始するためのソースコードを生成するコード生成手段と、コード生成手段で生成されたソースコードをセンターサーバーに保存されている商品データの所定の箇所に対して埋め込む埋め込み手段と、埋め込み手段でソースコードを埋め込んだ商品データを、センターサーバーよりショップに対して提供する商品データ提供手段と、商品データ提供手段で提供された商品データを基に、ｗｅｂページをショップサーバーが作成するｗｅｂページ作成手段と、ｗｅｂページ作成手段で作成されたｗｅｂページにおいて、ユーザにより所定の処理の開始が要求されることで、所定の処理が行なわれる。【選択図】図２８

Description

本発明は販売支援システムに係わり、特にネット上での取り扱いの商品や役務の件数を充実させ、売上の増大を図ることが可能で、かつ、販売形態の追加、刷新、多様化や工程管理等を簡単に図れる販売支援システムに関する。

従来、ショップはユーザの便宜を図るために、また、受注の機会を逃さないために、出来るだけ在庫切れが生じさせないようにする必要があった。このため、一定量の在庫を常に保有したり、また、効率の良い在庫管理を行うために需要の予測を行ったり等の工夫をしている。

ＷＯ２０１８／０３８０８４公報

しかしながら、在庫を常に確保するには費用もかかり、在庫管理も煩雑であった。
また、商品や役務を扱う販売事業者がユーザの商品探しや役務探しに対し便宜を十分に図ったり、売上を延ばすためには、一つの方策として取り扱う商品や役務の件数を増大させ販売可能な商品や役務を充実させることが望まれる。
こうすることで商品や役務の購入や予約、デリバリー、テイクアウト、カタログ請求等の頻度が増えるし、リピータの確保にも繋がり易くなると考えられる。
しかし、各販売事業者には取り扱う商品や役務の件数に限界があるし、商品や役務の件数を充実させるには費用もかかり、在庫管理の負担や倉庫費用等も急激に増えるおそれがある。
また、現在稼働中のお店をそのままの形で他の販売事業者参加型のモールや相互販売ができるように変えることができれば、在庫管理の負担無く取り扱う商品や役務の件数を充実できる。しかしながら、稼働中のお店の販売システムをモール化や相互販売の実現のために大幅に改造する必要が生ずる。更に、ホームページに掲載する際にも同種類の商品や役務等でまとめたり、ジャンル構成や一覧リストの統一化を図ったり等技術的にも解決しなければならない課題は多い。
更に、各販売事業者にとって現在行っている事業形態よりも、ネット上で商品購入、予約、デリバリー、テイクアウト、クーポン適用、カタログ請求、ライブコマース、価格比較等の販売の形態を拡げたり刷新したり、外国人にも販売をしたい等の多様化を図りたい場合がある。また、商品や役務の製作や配達に関する工程を管理したい場合がある。この場合、各販売事業者にとってシステム構築や改造等の負担のかかるおそれがあった。これらの販売作業を行う人的負担も十分に避けない場合もあった。
更に、上記したモール化、相互販売、多様化を図る場合に、どのようにすれば効率的であるかが判断できることが望ましい。また、このモール化等の導入をしたショップにとって、どの程度効果があり売上増に繋がるのかが予測できたり、提案できることが望ましい。更に、新規追加商品の仕入れについても効率的な判断や提案のできることが望ましい。

本発明はこのような従来の課題に鑑みてなされたもので、ネット上での取り扱いの商品や役務の件数を充実させ、売上の増大を図ることが可能で、かつ、販売形態の追加、刷新、多様化や工程管理等を簡単に図れる販売支援システムを提供することを目的とする。

このため本発明（請求項１）は、ショップの商品データが保存され、該商品データのｗｅｂページが生成されるショップサーバーと、前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、該商品データ収集手段により集められた商品データを保存するセンターサーバーと、該センターサーバーで保存された前記商品データについて、所定の処理を開始するためのソースコードを生成するコード生成手段と、該コード生成手段で生成されたソースコードを前記センターサーバーに保存されている商品データの所定の箇所に対して埋め込む埋め込み手段と、該埋め込み手段で前記ソースコードを埋め込んだ商品データを、前記センターサーバーより前記ショップに対して提供する商品データ提供手段と、該商品データ提供手段で提供された前記商品データを基に、前記ｗｅｂページを前記ショップサーバーが作成するｗｅｂページ作成手段と、該ｗｅｂページ作成手段で作成された前記ｗｅｂページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする。

商品データ収集手段により集められた商品データに対して、センターサーバーでは、所定の処理を開始するためのソースコードを生成する。そして、この生成されたソースコードをセンターサーバーに保存されている商品データの所定の箇所に対して埋め込む。ショップサーバーでは、センターサーバーより提供されたこの商品データを基に、ｗｅｂページを作成する。
このことにより、ショップではｗｅｂページに対して所定の処理を行うことが簡単にでき、若しくは所定の処理を改造無く組み込める。

また、本発明（請求項２）は、ショップの商品データが保存され、該商品データのｗｅｂページが生成されるショップサーバーと、前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、該商品データ収集手段により集められた商品データを保存するセンターサーバーと、前記商品データについて所定の処理を開始するためのソースコードを前記ショップサーバーが前記商品データのｗｅｂページの所定の箇所のソースコードに対して差し替える、若しくは前記商品データのｗｅｂページの所定の箇所に埋め込む差替え等手段と、該差替え等手段で前記ソースコードの差し替え等のされた前記ｗｅｂページを前記ショップサーバーが作成するｗｅｂページ作成手段と、該ｗｅｂページ作成手段で作成された前記ｗｅｂページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする。

商品データについて所定の処理を開始するためのソースコードを、ショップサーバーが商品データのｗｅｂページの所定の箇所のソースコードに対して差し替える、若しくは商品データのｗｅｂページの所定の箇所に埋め込む。そして、ソースコードの差し替え等のされたｗｅｂページをショップサーバーが作成する。
このことにより、ショップではｗｅｂページに対して所定の処理を簡単に組み込める。

更に、本発明（請求項３）は、ショップの商品データが掲載されたｗｅｂページを保存し、該ｗｅｂページをインターネットを介してユーザの閲覧に供するショップサーバーと、前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、該商品データ収集手段により集められた商品データを保存するセンターサーバーと、前記ｗｅｂページに埋め込まれ、所定の処理を開始するためのリンクを生成するソースコードと、前記リンクのリンク先であり、前記商品データの少なくとも一つを掲載したｗｅｂページを前記センターサーバーが作成するｗｅｂページ作成手段と、該ｗｅｂページ作成手段で作成された前記ｗｅｂページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする。

これにより、ｗｅｂページ中に所定の処理を行うためのボタンやアンカーテキスト等が配設されていない場合であっても、所定の処理を簡単に導入ができる。商品データの更新も簡単である。

更に、本発明（請求項４）は、前記ショップが、商品データの提供元である少なくとも一つの提供元ショップと、該商品データの提供先である提供先ショップとで構成され、前記提供元ショップから提供された商品データと前記提供先ショップの商品データを基に前記ｗｅｂページ作成手段で前記ｗｅｂページが作成されることを特徴とする。

提供先ショップでは提供元ショップから提供された商品データをセンターサーバーを介して取り扱える。このため、提供先ショップにおける取り扱い商品点数が増加し、ショップはモール化や相互販売、提携販売が簡単に実現できる。そして、提供先ショップと提供元ショップの商品データを基に、ｗｅｂページを作成することができる。このため、提供先ショップの商品データのみならず、提供元ショップから提供された商品データについても簡単に所定の処理を行うプログラムが組み込める。

更に、本発明（請求項５）は、前記ショップの前記商品データ中の所定の箇所若しくは前記ソースコードを介して生成された画面に、前記センターサーバーが前記ショップのショップ名、コメント文、検索入力欄、検索ボタン、パンくずリスト、リンクボタン、販売店リスト、言語の選択ボックス及び所定の言語の翻訳文のいずれか少なくとも一つを埋め込む処理を行うことを特徴とする。

ショップの商品データ中の所定の箇所、若しくはソースコードを介して生成された画面に、センターサーバーがショップのショップ名、コメント文、検索入力欄、検索ボタン、パンくずリスト、リンクボタン、販売店リスト、言語の選択ボックスや所定の言語の翻訳文を埋め込むことで、ショップ側での改造の負担が無くショップや商品に関する情報等を追加できる。また、ショップにおいて、他のショップの商品が取り扱われる場合には、ユーザがこれらの情報を基にこの他のショップの商品を認識できたり、この他のショップを配達元として確認できる。
ショップの商品データ中の所定の箇所に販売店リストを埋め込んだ場合には、ショップ側での改造の負担が無く、この販売店リスト中に記載のショップについても所定の処理を行うプログラムが簡単に組み込める。また、ショップは改造無く簡単に所定の処理を行うプログラムが組み込める。

更に、本発明（請求項６）は、前記センターサーバーに用意された管理画面と、該管理画面において、前記ショップがユーザに対して問い合わせを行うために必要な仕様データを各ショップ毎に予め設定する仕様データ設定手段と、該仕様データ設定手段で設定された前記仕様データに基づき、ユーザに対しての問い合わせを含むページを生成する問い合わせ生成手段と、該問い合わせ生成手段で生成された前記ページが、前記所定の処理を行うプログラムにおいて前記ユーザに対して表示される問い合わせ表示手段と、該問い合わせ表示手段で表示された前記ページの前記問い合わせに対する前記ユーザの返答結果が前記センターサーバーに保存される返答結果保存手段を備えて構成した。

ショップが販売、予約、デリバリー、資料請求等の処理の過程において、ユーザに対して問い合わせを行うために必要な仕様データを各ショップ毎に管理画面で予め設定する。これにより、ショップは自店の独自の仕様を他店の仕様、若しくはセンターサーバーの仕様に合わせることなく維持できる。提供先ショップに対し提供元ショップが参加するモール化、相互販売、提携販売を行った場合には、各店それぞれに販売、予約、デリバリー、資料請求等の処理に独自の仕様があることが想定されるが、このような場合であっても各店が独自の仕様を維持しつつ参加できる。

更に、本発明（請求項７）は、前記センターサーバーに用意された管理画面と、該管理画面において、前記ショップが前記商品データの工程管理を行うために必要な仕様データを各ショップ毎に予め設定する仕様データ設定手段と、該仕様データ設定手段で設定された前記仕様データに基づき、前記ショップに対しての商品の製作順序、商品の製作時間、商品の製作完了及び商品の配達の少なくともいずれか一つを含む工程を管理するページを生成する工程管理生成手段と、該工程管理生成手段で生成された前記ページが、前記ショップに対して表示される表示手段を備えて構成した。

このことにより、ショップは所定の処理が簡単に行えるようになる上に、商品の工程管理も簡単に行えるようになる。表示手段で表示されたページに対する応答結果を保存すれば、調整や解析用に使えたり、商品の注文状況が分かるので売上の管理にも使える。

更に、本発明（請求項８）は、前記所定の処理を行うプログラムにより、前記ｗｅｂページに掲載されている原文が複数のブロックに分離され、該ブロック毎に前記原文と該原文に対する翻訳文とが並べてユーザに対し表示されることを特徴とする。

ブロック毎に原文と翻訳文とが対訳とされることでユーザは見易く、情報に対する判断を的確に行うことができる。
更に、本発明は、複数のショップについてその保有する商品を保存するデータベースと、該データベースに保存された前記ショップの商品を同じ種類の商品毎にまとめるまとめ手段と、該まとめ手段でまとめた前記ショップの商品を販売店リストとしてｗｅｂページに生成するｗｅｂページ生成手段と、前記ｗｅｂページ若しくは前記販売店リスト中に配設された外国人購入用のリンクとを備え、該リンクのユーザによるクリックに基づき外国人購入用の処理が動作することを特徴とする。

更に、本発明（請求項９）は、年齢、性別、趣味嗜好、業種、用途の少なくともいずれか一つの属性を含む複数の購入者の購入情報を基に、商品毎に属性別の購入度合いがまとめられた基本属性と、ショップでユーザにより購入された複数の商品と、該複数の商品について前記ショップでの購入の情報又は前記基本属性を基に属性別にまとめられた購入属性と、該購入属性を基にユーザによる購入需要の大小を判定する判定手段を備えて構成した。

ショップでの購入の情報や基本属性を基に属性別に購入属性をまとめる。そして、この購入属性を基にユーザによる購入需要の大小を判定する。これにより、このショップにおける購入需要を属性別に評価できるようになる。このため、このショップの購入需要が大きい属性の場合には、この購入需要の大きさを活用して一層の販売の強化を図ったり、購入需要が小さい属性の場合には、購入需要の補強を図ることができ、ショップの売上増に繋げられる。

更に、本発明（請求項１０）は、前記判定手段で前記購入需要が大きいと判断された属性について前記基本属性を基に同じ属性を有する商品データの追加、若しくは仕入れを判断、又は、前記ショップのサイトに他店の商品データを販売のために掲載することを特徴とする。

ショップの購入需要が大きいと判断された属性については、基本属性を基に同じ属性を有する商品データを追加したり、実際にその商品の仕入れを判断できる。また、ショップのサイトに他店の商品データを販売のために掲載することもできる。これにより、ショップの商品を充実でき、売上増に繋げることができる。

更に、本発明（請求項１１）は、前記判定手段で前記購入需要が小さいと判断されたとき、前記ショップの商品データを他店の通販サイトに販売のため掲載することを特徴とする。

ショップの購入需要が小さいと判断された属性については、ショップの商品データを他店の通販サイトに販売のため掲載する。これにより、このショップでは、販売利益を得ることができ、売上増に繋げられる。

更に、本発明（請求項１２）は、年齢、性別、趣味嗜好、業種、用途の少なくともいずれか一つの属性を含む複数の購入者の購入情報を基に、商品毎に属性別の購入度合いがまとめられた基本属性と、ショップで取り扱われている複数の商品データを収集する商品データ収集手段と、前記複数の商品データについて前記基本属性を基にまとめた販売属性と、前記ショップでユーザにより購入された複数の商品と、該複数の商品について前記ショップでの購入の情報又は前記基本属性を基に属性別にまとめられた購入属性と、前記販売属性と前記購入属性とを前記属性について対比する対比手段とを備えて構成した。

複数の商品データについて販売属性を基本属性を基にまとめる。一方、ショップでの購入の情報や基本属性を基に購入属性をまとめる。そして、この販売属性と購入属性とを属性について対比する。このように、ショップ毎に購入属性と販売属性をまとめ、対比等による評価をすることで、ショップの購入需要や販売面での弱点や強い点を図表化したり明確化することができる。商品の購入需要にマッチングした商品構成になっているかを簡単に判断できる。これにより、ショップの購入需要の強い面を活用して一層の販売の強化や商品の充実を図ったり、商品の購入需要と商品構成とがミスマッチングしていて、購入需要が弱い面については購入需要の補強をすることができ、売上増に繋げられる。

以上説明したように本発明によれば、商品データ収集手段により集められた商品データに対して、センターサーバーでは、所定の処理を開始するためのソースコードを生成し、この生成されたソースコードをセンターサーバーに保存されている商品データの所定の箇所に対して埋め込むことで、ショップではｗｅｂページに対して所定の処理を行うプログラムが簡単に、若しくは改造無く組み込める。

本販売支援システムのシステム構成図販売店リストの例センターサーバーの構成図提供先－提供元対応テーブルにおけるデータの関係性を示す図提供元ショップのサーバーの構成図提供先ショップのサーバーの構成図各提供元ショップの商品データの収集、更新、データ集合体の生成方法を示すフローチャート提供先ショップの商品データの収集、更新方法を示すフローチャート販売店リストを用意する処理方法を示すフローチャート特徴を表す要素の例提供元ショップの残りの商品から販売店リストを作成する方法を示すフローチャート提供先ショップのｗｅｂページで行われる検索の処理と一覧ページの処理方法を示すフローチャート検索結果リストの概念図商品詳細ページの作成方法を示すフローチャート（その１）商品詳細ページの作成方法を示すフローチャート（その２）商品詳細ページの作成方法を示すフローチャート（その３）商品詳細ページの概略図（その１）商品詳細ページの概略図（その２）商品詳細ページの概略図（その３）商品詳細ページの概略図（その４）商品詳細ページ作成の別方法を示すフローチャート（その１）商品詳細ページ作成の別方法を示すフローチャート（その２）商品詳細ページ作成の別方法を示すフローチャート（その３）提供先ショップと提供元ショップ間の関係を示す図提供先ショップの販売履歴データを示す概念図提供元ショップの販売履歴データを示す概念図提供元ショップが同時に提供先ショップにもなっている場合の販売履歴データを示す概念図ネットを介して資料請求する場合を示すフローチャート（その１）商品詳細ページの商品説明文中の適所に対し、資料請求ボタンのソースコードを埋め込む例ネットを介して資料請求する場合を示すフローチャート（その２）管理画面における仕様の設定等の例相互販売、提携販売、モール化で提供先ショップがデリバリー等の仕組みを導入した場合を示すフローチャート（その１）商品説明文にデリバリーボタンを配設した画面例デリバリーボタンを配設した画面例デリバリー等の仕組みを導入した場合を示すフローチャート（その２）問い合わせ画面の例デリバリー等の仕組みのホームページ適用例事業種類コードにより分類されたデータベース例事業者毎の管理データの例情報端末の注文画面例工程図画面（その１）工程図画面（その２）工程図画面（その３）工程図画面（その４）工程図画面（その５）原文と翻訳文の対訳の掲載された外国人向けのｗｅｂページの例ショップの商品データを外国人が検索可能とした例ショップの既存のｗｅｂページから直接外国人が検索可能とした例符号の付された対訳リストの例分節や用語毎に分離され、ホームページ上に選択自在に表示された日本語の例販売店リストに海外ユーザ購入ボタンが表示された例基本属性の解析方法を説明する図販売属性の解析方法を説明する図購入属性の解析方法を説明する図購入属性と販売属性の対比モール化を図ったときの効果例ショップの特徴を提携により一層強化させた例管理ツールにおける属性の設定

以下、本発明の第１の実施形態について説明する。図１に本販売支援システムのシステム構成図を示す。
図１において、インターネット１０にはユーザの使用するパソコン３やスマートフォン５等の情報端末が接続されている。また、このインターネット１０には、商品データの提供元となるショッピングモール、ショップ、メーカー等の通販サイトを運営する提供元ショップ２のサーバー４が接続されている。ここに、商品データには役務データを含み、通販サイトには役務提供等の事業者サイトを含んでもよい（以下、同旨）。役務提供等の事業者には例えば、レストラン、食堂、クリーニング店、花屋、お菓子屋、学習塾、ホテル等の各サービス業を含む。図中、提供元ショップ２－１、２－２、２－３と示しているのは提供元ショップ２が複数であることを示している。これらの提供元ショップ２は独自のｗｅｂサイトを運営しているが、必ずしもサイトを持たなくても良い。

この提供元ショップ２のサーバー４から提供された商品データはインターネット１０を介してセンターサーバー６で受信されるようになっている。また、センターサーバー６は、提供元ショップ２のｗｅｂサイトを巡回し、ホームページから所定の定義に基づき商品データを収集するようになっている。
そして、このセンターサーバー６では商品データについて所定の解析が行われるようになっている。その後、後述する商品毎の販売店リストを含む形や販売店リストを含まない個別の商品等の形で提供先となる提供先ショップ１のサーバー７に対しＡＰＩ（Application Programming Interface）やＣＳＶファイル等でセンターサーバー６から商品データが提供されるようになっている。ここに、販売店リストは、例えば図２に示すように同一の商品ａを取り扱い販売しているショップをまとめたリストである。ここに、商品ａには役務データを含み、また、ショップには役務を取り扱う事業者の営む店を含んでもよい（以下、同旨）。
提供先ショップ１はショッピングモールやショップ等の通販サイトを運営しており、提供先ショップ１独自のｗｅｂサイト９を有している。但し、ｗｅｂサイト９を有さずに新規に通販サイトを構築することも可能である。そして、提供先ショップ１のサーバー７は、センターサーバー６のＡＰＩやＣＳＶファイル等を通じて、販売店リストを含む商品データをダウンロードできるようになっている。但し、販売店リストを含まない個別の商品等の商品データのみがダウンロードされてもよい。ここに、提供先ショップ１は複数の提供元ショップ２の参加した通販モール化や、ショップ同士の間で互いの商品を販売する相互販売や、提携したショップ間の内の一方のみで商品を販売する提携販売が実現できるようになっている。

センターサーバー６の構成図を図３に示す。このセンターサーバー６には、演算を行う演算部１１、表示・操作部１３、外部とのインターネット１０を介してデータ通信を行う通信部１５に加え、商品データ収集・解析部２０には巡回プログラム２１及び商品データ解析プログラム２３が構築されている。巡回プログラム２１では提供元ショップ２や提供先ショップ１のｗｅｂページに掲載された商品データを定期的に巡回し、ｗｅｂページのｈｔｍｌソースコードから所定の定義に従い商品名、メーカー名、型式、価格、送料、仕様、商品説明、商品画像、商品詳細ページのＵＲＬ、ジャンル名、ＪＡＮコード等の商品データを収集するようになっている。

なお、商品データ収集・解析部２０において、この商品データは巡回による以外にもＣＳＶファイルによる提供や手動でも登録が可能なようになっている。巡回方式を採用するのは、提供元ショップ２の人手間を省くことで便利にするためである。しかしながら、巡回を行わずにＣＳＶファイルによる提供や手動での登録を行うようにしても良い。また、巡回を行いつつＣＳＶファイルによる提供や手動での登録が行えるようにしても良い。データの更新時にのみ登録を行うようにしても良い。

商品データ解析プログラム２３では巡回プログラム２１で収集した多数の商品データから、後述する所定のロジックにより同じ商品を取り扱うショップを一つの集合の販売店リストとしてまとめたり、販売店リストの生成されていない商品（以下、個別商品と言う）を抽出したりするものである。また、ｈｔｍｌソースコードを生成したり、商品説明文テキスト中に埋め込む処理等も行う。
ユーザ対応・管理プログラム２５では、ユーザとの応対や、ユーザやショップの管理を自動で行うプログラムが搭載されている。このプログラムは、例えば、予約プログラム、注文プログラム、デリバリープログラム、カタログ請求プログラム、クーボン適用プログラム、現金還元プログラム、テイクアウトプログラム、価格交渉プログラム、外国人購入用プログラム等である。

また、センターサーバー６のデータベース３０には、複数の販売店リストを保存した販売店リストデータベース３１、提供元ショップ２のショップ名、サイトＵＲＬ、商品販売条件等を保存した提供元ショップデータベース３３、提供先ショップ１のショップ名、サイトＵＲＬ、商品販売条件等を保存した提供先ショップデータベース３５、図４に示すように、提供先ショップ１毎にいずれの提供元ショップ２が提携しているのかその関係を保存した提供先－提供元対応データベース３７、提供元ショップ２が販売中の商品データを保存した提供元ショップ商品データベース３９、提供先ショップ１が販売中の商品データを保存した提供先ショップ商品データベース４１、提供元ショップ２若しくは提供先ショップ１が希望する場合にこれらのショップの販売履歴管理データをバックアップする販売履歴管理データベース４３、提供元ショップ２の内で販売店リストの生成されていない個別商品を保存する個別商品データベース４５、ユーザ対応・管理プログラム２５で利用されるユーザ情報、管理情報を保存するユーザ対応・管理データベース４７が備えられている。

一方、提供元ショップ２のサーバー４は図５に示すように、センターサーバー６を含むインターネット１０での通信を行うための通信部５５、元々本実施形態の適用以前より提供元ショップ２が行っていた通販システムの運用に必要な管理部５７、顧客データベース５９を備える。

また、本実施形態ではデータベース６０を備える。但し、データベース６０は、元々提供元ショップ２が保有していたサーバーとは独立したサーバーとして構築されても良い。
このデータベース６０には、提供元ショップ２が取り扱う商品の提供元ショップ２における販売履歴を管理する提供元ショップ販売履歴管理データベース６１、提供元ショップ２が取り扱う商品の提供先ショップ１における販売履歴を管理する提供先ショップ販売履歴管理データベース６３、提供元ショップ２が取り扱う商品を保存している提供元ショップ商品データベース６５を備える。但し、このデータベース６０の一部又はすべてはセンターサーバー６に保存されてもよい。

また、提供先ショップ１のサーバー７は図６に示すように、センターサーバー６を含むインターネット１０での通信を行うための通信部７５、元々本実施形態の適用以前より提供先ショップ１が行っていた通販システムの運用に必要な管理部７７、顧客データベース８１を備える。また、本実施形態ではｗｅｂページ作成部７９とデータベース８０を備える。但し、ｗｅｂページ作成部７９とデータベース８０は、元々提供先ショップ１が保有していたサーバーとは独立したサーバーとして構築されても良い。
なお、ｗｅｂページ作成部７９には、図示しないが、商品詳細ページを作成する商品詳細ページ作成部と、一覧ページを作成する一覧ページ作成部と、検索結果リストを作成する検索結果リスト作成部を有する。
このデータベース８０には、提供元ショップ２が取り扱う商品の提供先ショップ１における販売履歴を管理する提供元ショップ販売履歴管理データベース８３、提供先ショップ１が取り扱う商品の提供先ショップ１における販売履歴を管理する提供先ショップ販売履歴管理データベース８５、提供先ショップ１が取り扱う商品を保存している提供先ショップ商品データベース８７、ダウンロードした各商品を保存する個別商品データベース８９を備える。但し、このデータベース８０の一部又はすべてはセンターサーバー６に保存されてもよい。

次に、各提供元ショップ２の商品データを収集し、この商品データを更新し、データ集合体を生成する方法を図７のフローチャートに基づき説明する。
図７のステップ１（図中Ｓ１と略す。以下同旨）では、巡回プログラム２１が各提供元ショップ２のサイトに存在するｗｅｂページを巡回し、このｗｅｂページに掲載されている商品データを収集する。ステップ２では、巡回プログラム２１は、収集した最新のデータで前回取得した商品データの商品名、価格、説明文、送料、商品購入により付与されるポイント、ジャンル名、メーカー名、仕様等を更新する。但し、例えば中古品のように特定のサイトにおいてユーザによる登録、更新、削除等が行われる商品については必ずしもこのように巡回によりデータの収集、更新をしなくても良い。

ステップ３では、センターサーバー６は、ステップ２で更新のされた各提供元ショップ２の商品データを提供元商品データ集合体としてまとめて提供元ショップ商品データベース３９に保存する。但し、提供元商品データ集合体としてまとめずに各提供元ショップ２毎に保存されても良い。
ステップ４ではこの処理を定期的に一定頻度で繰り返す。これにより、各提供元ショップ２の負担無く商品データを取得し更新等ができる。但し、この処理はＣＳＶデータの提供によったり、あるいは、人の手による登録、更新、削除等で行われても良い。これらの混在で行われても良い。また、各提供元ショップ２が商品データを更新したときに、少なくとも１回の巡回や、更新をした商品データだけのデータ取得を指示するようにしてもよい。

次に、提供先ショップ１の商品データを収集し、この商品データを更新する方法を図８のフローチャートに基づき説明する。
図８のステップ５では、巡回プログラム２１が提供先ショップ１のサイトに存在するｗｅｂページを巡回し、このｗｅｂページに掲載されている商品データを収集する。ステップ６では、巡回プログラム２１は、収集した最新のデータで前回取得した商品データの商品名、価格、説明文、送料、ポイント、ジャンル名、メーカー名、仕様等をステップ２と同様に更新する。

ステップ７では、センターサーバー６は、同一の商品について商品データの削除があったか否か、一旦削除のされた商品データについて復活があったか否かを判定する。商品データの削除は販売終了や在庫切れ等の場合に生ずる。一旦削除のされた商品であってもその後に再入荷があれば商品詳細ページの復活や入荷に伴う記載内容の変更が起こり得る。そして、ステップ８では、センターサーバー６が、この削除があった商品データについては削除があった旨を、また、復活があった商品データについては復活があった旨を提供先ショップ商品データベース４１に保存する。このように削除があった旨や復活があった旨を保存するのは商品の重複掲載を停止するためである。

ステップ９では、販売終了や在庫切れのあった商品等はデータベースから一旦削除することが望ましい。復活の場合のあることを想定するためである。そして、ステップ１０ではこの処理を定期的に一定頻度で繰り返す。これにより、提供先ショップ１の負担無く商品データを取得し更新等ができる。但し、この処理はＣＳＶデータの提供によったり、あるいは、人の手による登録、更新、削除等で行われても良い。これらの混在で行われても良い。また、提供先ショップ１が商品データを更新したときに少なくとも１回の巡回や、更新をした商品データだけのデータ取得を指示するようにしてもよい。
なお、提供元商品データ集合体にはこの提供先ショップ１の商品データを加えるようにしてもよい。

次に、販売店リストを用意する処理方法について図９のフローチャートに基づき説明する。
図９において、ステップ１５で商品データ解析プログラム２３の処理を開始し、この商品データ解析プログラム２３はステップ１７で提供元商品データ集合体を読む。そして、ステップ１９で、商品データ解析プログラム２３は提供先ショップデータベース３５に保存されている提供先ショップ１について、提供先ショップ商品データベース４１に保存されている商品データよりｉ番目の商品を読む。ステップ２１では、商品データ解析プログラム２３はこのｉ番目の商品に相当する提供元ショップ２の商品を提供元商品データ集合体より見つける。

このときの解析は、例えば、商品データ解析プログラム２３が巡回プログラム２１で収集した多数の商品データから、同一商品にまとめるために用いる特徴を表す要素を抽出するようになっている。これは、各提供元ショップ２では同じ商品を販売していることが多くあり、この特徴を表す要素を使って同じ商品を一つの集合としてまとめるものである。

ここに、要素とは、商品名については空白で仕切ったときのそれぞれの単語が該当する。メーカー名については株式会社等の名称を取り除いた単語が該当する。型式についてはその型式を示すテキスト自体が要素に該当する。仕様についてはそれぞれの仕様の項目に対応する内訳の仕様データが要素に該当する。商品説明については説明文中の名詞が要素に該当する。ＪＡＮコードも要素に該当する。特徴を表す要素の例を図１０に示す。

特徴を表す要素はそれぞれの商品に対応しており、少なくとも一つの要素で構成されている。この特徴を表す要素は手動にて設定するようにしても良いが、一部の要素を手動による設定とし、残りの要素を商品データの自動解析から得られるように、組み合わせた形で設定するようにしても良い。自動による場合、それぞれの商品の商品名や型式、仕様、数量（容量）を示す単位、メーカー名に対し共通する要素をもって特徴要素とすることが望ましい。また、ＡＩ（人口知能）が商品データを解析することで自動設定するようにしても良い。なお、特徴を表す要素は型式だけの要素やＪＡＮコードのみで構成することも可能である。

また、商品画像を特徴要素に加えるようにしても良い。この場合には、例えば、商品画像を縦、横複数の画素データに分離する。この画素データをもって対比を行う。
商品データ解析プログラム２３では商品毎に生成したこの商品の特徴を表す要素を各提供元ショップ２から収集した商品データに対し当て、その商品データの中からこれらの要素を有する商品を同一の商品として抽出するようになっている。ここで同一の商品として抽出された各提供元ショップ２の商品データは、それぞれの商品を販売している少なくとも一つのショップを含む販売店リストとしてまとめられ、販売店リストデータベース３１に保存されるようになっている。特徴を表す要素を設定し難い商品データの場合には、同一の若しくは関連する商品データ同士を手動でまとめるようにしてもよい。このように手動で設定する商品データと自動で設定する商品データとを混在させてもよい。

なお、この販売店リストに掲載されているショップ毎の価格を安い順に並べれば、それぞれの商品単位に価格比較ができる。この販売店リストに掲載されるショップは中古品を取り扱うショップや個人であっても良い。
ステップ２３では、センターサーバー６により、このｉ番目の商品については既に販売店リストデータベース３１に販売店リストが存在するか否かが判断される。そして、販売店リストが存在する場合にはステップ２５に進み、センターサーバー６は、この存在する販売店リストに対し、ステップ２１で見つかった提供元ショップ２の商品とこのｉ番目の商品（提供先ショップ１の商品）とを関連付ける。

一方、ステップ２３で販売店リストが存在しない場合にはステップ２７に進み、センターサーバー６は、ステップ２１で見つけた商品データをもって、新規の販売店リストとして販売店リストデータベース３１に保存する。
ステップ２９ではセンターサーバー６は、関連付けのされた商品を提供元ショップ２の商品データより削除する。個別商品を残すためである。但し、関連付けのされた商品と個別商品とが、提供先ショップ１の検索結果リストや一覧ページに重複して掲載されても良いとする場合には、ステップ２９の処理は省略されても良い。ステップ３１では、センターサーバー６により提供先ショップ１の商品データの残りがあるか否か判断され、残りがある限りセンターサーバー６はステップ１９からの処理を繰り返す。

そして、ステップ３５では、センターサーバー６は販売店リストとして関連付けられなかった商品を個別商品として個別商品データベース４５に保存する。以上の処理により、販売店リストが生成されると共に個別商品も生成される。なお、ここで生成された販売店リストに属する商品と個別商品のデータは前述した図７、図８の処理により常に更新される。

次に、提供元ショップ２の残りの商品からも販売店リストを作成する方法について図１１のフローチャートに基づき説明する。
図１１において、ステップ４１ではセンターサーバー６が提供元ショップ２の残りの商品データを読む。ステップ４３では、センターサーバー６は提供先ショップ１の商品であって、一旦削除後に提供先ショップ１側で復活した商品について、提供元ショップ２側の商品として掲載可能となっている場合にはこの販売店リスト付きの商品データや個別商品を削除する。販売店リストの２重登録を防ぐためである。但し、販売店リスト付きの商品データや個別商品が、提供先ショップ１の検索結果リストや一覧ページに重複して掲載されても良いとする場合には、ステップ４３の処理は省略されても良い。ステップ４５では、センターサーバー６は提供元ショップ商品データベース３９に保存されている提供元ショップ２の商品データよりｉ番目の商品を読む。ステップ４７で、センターサーバー６はこのｉ番目の商品に相当する提供元ショップ２の商品を提供元ショップ２の残りの商品データから見つける。ここでの処理はステップ２１の商品解析方法と同様である。

次に、ステップ４９では、センターサーバー６により、このｉ番目の商品には既に販売店リストが存在するか否かが判断される。そして、販売店リストが存在する場合にはステップ５１に進み、センターサーバー６はこの存在する販売店リストに対し、ステップ４７で見つかった提供元ショップ２の商品を加える。一方、ステップ４９で販売店リストが存在しないと判断された場合にはステップ５３に進み、センターサーバー６はステップ４７で見つけた商品データをもって、新規の販売店リストとして販売店リストデータベース３１に保存する。

ステップ５５ではセンターサーバー６が関連付けのされた商品を提供元ショップ２の商品データより削除する。個別商品を残すためである。但し、関連付けのされた商品と個別商品とが、提供先ショップ１の検索結果リストや一覧ページに重複して掲載されても良いとする場合には、ステップ５５の処理は省略されても良い。ステップ５７ではセンターサーバー６により、提供元ショップ２の商品データの残りがあるか否か判断され、残りがある限りステップ４５からの処理を繰り返す。そして、ステップ５９では、センターサーバー６は販売店リストとして関連付けられなかった商品を個別商品として個別商品データベース４５に保存する。
なお、この場合、後述するステップ１０１と同様に、提供先－提供元対応テーブル３７より提供先ショップ１の提供先ショップｉｄに対応する提供元ショップ２の提供元ショップｉｄを読む。そして、個別商品は各提供先ショップ１毎に、その属する提供元ショップ２に該当する商品データを抽出し保存する。即ち、各提供先ショップ１毎の個別商品データベース４５を作成するようにしても良い。
以上の処理により、図９の処理が行われた後の提供元ショップ２の残りの商品データからも販売店リストが生成されると共に個別商品が生成される。なお、ここで生成された販売店リストに属する商品と個別商品は前述した図７、図８の処理によりデータは常に更新される。
なお、販売店リストを作成するに際しては、提供元商品データ集合体と提供先ショップ１の商品データとをまとめた形で一つの集合体を生成し、この集合体に対して上記のステップ１９以降、若しくはステップ４５以降と同様に商品単位に関連付けを行うことで販売店リストと個別商品とを生成するようにしてもよい。

次に、提供先ショップ１のｗｅｂページで行われる検索の処理と一覧ページの処理方法とについて図１２のフローチャートに基づき説明する。
図１２において、ステップ７１では、提供先ショップ１のｗｅｂサイト９を訪れたユーザが検索を行う。この際には、提供先ショップ１のサーバー７は、ユーザによりｗｅｂページの検索入力欄に投入された検索キーワードについて、ステップ７３で提供先ショップ１の顧客データベース８１を検索する。この際の検索では、検索キーワードにジャンル名や仕様での検索項目が加えられても良い。
ここで、サーバー７は検索結果データと検索件数を一時保存する。この顧客データベース８１は提供先ショップ１が元々保有していた商品のデータベースである。本実施形態を適用する以前には、この顧客データベース８１だけの検索により検索結果リストをユーザに対し提供していたものである。なお、顧客データベース８１はサーバー７には含めずに、提供先ショップ１が元々保有していた形のまま別個のサーバーに存在しても良い。既存の提供先ショップ１保有のサーバーの改造を出来るだけ避けそのまま利用するためである。

一方、ステップ７５では、サーバー７によりこの検索キーワードがセンターサーバー６に対し渡される。この際の検索では、検索キーワードにジャンル名や仕様での検索項目が加えられても良い。ステップ７７では、センターサーバー６で受信されたこの検索キーワードについて、センターサーバー６により販売店リストデータベース３１と個別商品データベース４５に対して検索が行われる。そして、ステップ７９で、センターサーバー６は、この検索キーワードに一致した商品の販売店リストと、販売店リストに関連付けられていない個別商品とを抽出する。
但し、個別商品データベース４５が全提供先ショップ１についてまとめられたものである場合には、前述と同様に、提供先－提供元対応テーブル３７より提供先ショップ１の提供先ショップｉｄに対応する提供元ショップ２の提供元ショップｉｄを読む。そして、個別商品は、この提供先ショップ１に属する提供元ショップ２に該当する商品データを抽出する。
ステップ８１では、センターサーバー６はこれらの商品データと検索件数をＡＰＩで提供する。このとき、商品データは検索結果リストの１ページに掲載される例えば２０品分ずつ等を提供することが望ましい。送信時間の短縮とサーバー負荷の軽減のためである。これらの商品データには中古品を加えても良い。

ステップ８３では、提供先ショップ１のサーバー７がＡＰＩにアクセスして商品データを受信する。ステップ８５では、このサーバー７が、受信した商品データを提供先ショップ商品データベース８７と個別商品データベース８９に保存する。ステップ８７では、サーバー７がｗｅｂページ作成部７９においてこの商品データを基にｗｅｂページを作成する。但し、このとき商品データはステップ７３で検索された結果の商品データと一緒にまとめられることが望ましい。検索件数もステップ７３で検索された結果の件数とＡＰＩ経由の商品データの件数とで合計されることが望ましい。商品データの検索結果の並び順は提供先ショップ１の自由に行える。例えば、提供先ショップ１の商品データを先に出して、その後にＡＰＩ経由で受信した商品データを加えても良いし、あるいは、適宜所定の条件に従い混在する形で商品データを加えても良い。ステップ８９では作成されたｗｅｂページが検索結果リストとしてユーザに対し提供される。このときの検索結果リストの概念図を図１３で説明する。

図１３において、例えば、従来の検索結果が１，０００件であり、このときに掲載された商品１～商品５・・・は顧客データベース８１だけの検索の結果である。これに対し、本実施形態では、例えば検索結果がＡＰＩ経由で受信した商品データを加えて２，０００件となる。このときに加えられた商品データの内訳は、図中の商品１０が、提供先ショップ１では商品取り扱いは無いものの、新しく生成された商品詳細ページで販売店リストを有する商品データである。また、商品１１が提供先ショップ１では取り扱いは無いが、提供元ショップ２から提供された個別商品データを基に作成された商品詳細ページである。このように検索結果の件数を大幅に増加できる。従って、商品を漏れなく探したいと考えているユーザにとっては効率の良い検索が行える。更に、既存の商品１～商品５・・・の内の多くの商品の商品詳細ページには販売店リストが追加されている。
但し、図示しないが、ステップ７３で検索された結果の商品データとＡＰＩ経由で受信した商品データとは一緒にせずに、ＡＰＩ経由で受信した商品データは別枠や、商品詳細ページに掲載された商品の関連商品として表示されても良い。また、販売店リストが追加された商品だけを一緒にして、個別商品については別枠で表示する等されても良い。
なお、センターサーバー６において、提供先ショップ商品データベース４１に保存されているデータ、個別商品データベース４５に保存されているデータ、及び販売店リストデータベース３１をまとめて検索キーワードで検索を行い、この検索結果のデータをＡＰＩ経由で提供先ショップ１に対し送信するようにしても良い。この場合には提供先ショップ１側での検索の負担は無くなる。
図１２のフローチャートは検索結果ページの作成について説明したが、一覧ページの作成についても同様であるので詳しい説明は省略する。但し、一覧ページの作成の場合には、検索キーワードとして例えばジャンル名、若しくはジャンルコードで商品データの検索を行う。また、一覧ページの作成については、提供先ショップ１の商品の露出を優先させるため等の理由から、掲載可能な商品を一定数に制限し手動で選択されるようにしてもよい。

提供先ショップ１の規模が小さい場合は検索結果の全商品データをＡＰＩやＣＳＶファイル等で提供しても良い。しかしながら、規模が大きい場合に、全商品データを受信して提供先ショップ商品データベース８７に保存とすると通信負担も大きく、また、一覧ページの場合には商品データが古くなるおそれがある。そこで、検索結果や一覧ページの商品データを、提供先ショップ１から送信リクエストのあった都度、例えば１ページ単位（１ページ２０品分等を掲載）に送信することが望ましい。この送信リクエストは例えば１ページ単位にされても良い。このように限定した商品数を提供することでリアルタイム性を確保でき通信負担も少なくできる。
以上により、提供先ショップ１では自店の元々保有しているサーバー設備をそのまま使うことが可能である。設備の変更は少なくて済む。仮に、提供先ショップ１側のデータベースの容量が小さくても大きな規模の商品データを扱える。検索の対象とする件数は、従来通り提供先ショップ１の元々保有している商品データのみなので検索の負荷も増えない。従って、既存のサーバー設備であっても検索速度をそのまま維持できる。また、センターサーバー６のデータベースが扱うデータ分についてはデータの更新を考える必要がない。

なお、提供先ショップ１の顧客データベース８１には、個別商品データベース４５に保存されているデータ、及び販売店リストデータベース３１に保存されているデータの内の提供先ショップ１に関連するデータを加えておくようにしてもよい。即ち、センターサーバー６より提供先ショップ１に対しＣＳＶファイルやＡＰＩ等により商品データの提供を行う。この際には、提供先ショップ１の商品データと個別商品データベース４５に保存されているデータ、及び販売店リストデータベース３１に保存されているデータのすべてをセンターサーバー６側でまとめた上で提供してもよい。
但し、提供先ショップ１の商品データの一部又はすべて、例えば価格、在庫数、送料及びポイント等の内の少なくともいずれか一つの項目については提供先ショップ１側での管理を優先させるためにＣＳＶファイルに含まないことも可能である。特に、価格及び在庫数の内の少なくともいずれか一つの項目については含めないことが望ましい。
あるいは、ＣＳＶファイルに含めていたとしてもインポートされる際にそのデータで提供先ショップ１の商品データが更新されないとしてもよい。

また、後述するように、販売店リストはテキストである商品説明文中に、例えばｈｔｍｌソースコードの形式で埋め込みされた形で提供してもよい。
そして、提供先ショップ１のサーバー７が、ユーザによりｗｅｂページの検索入力欄に投入された検索キーワードについて、ステップ７３で提供先ショップ１の顧客データベース８１を検索するようにしてもよい。この場合には、ステップ７５～ステップ８９の処理は省略できる。このため、改造は不要にできる。一覧リストもこのＣＳＶファイルやＡＰＩ等により提供された商品データを基に作成されてもよい。
なお、提供先ショップ１のサーバー設備は改造して使うのではなく、新規に提供先ショップ１のサーバー設備を設けるようにしてもよい。この場合には、センターサーバー６内に提供先ショップ１のｗｅｂサイトを設けるようにしてもよい。そして、このｗｅｂサイトでは提供先ショップ１の設定した独自ドメインを使うこともできる。

次に、商品詳細ページの作成方法について図１４のフローチャートに基づき説明する。
図１４において、ステップ９１では、ユーザが提供先ショップ１のｗｅｂサイト９を訪問する。ステップ９３では、ユーザが提供先ショップ１のｗｅｂサイト９で検索結果や一覧リスト等から商品ａを一つ選びクリックする。このときの商品ａは前述の通り提供先ショップ１の商品である場合と、提供元ショップ２の商品である場合とがある。ステップ９５では、提供先ショップ１の提供先ショップｉｄと、この商品ａに相当する商品ｉｄとが提供先ショップ１のサーバー７によりデータベース８０から抽出され、センターサーバー６に対し送信される。

ステップ９７では、センターサーバー６がこの受信した商品ｉｄに基づき販売店リストデータベース３１の販売店リストテーブルを検索する。そして、ステップ９９では、センターサーバー６がこの商品ａの販売店リストが存在するか否かを判断する。ステップ９９で商品ａの販売店リストが存在すると判断された場合にはステップ１０１に進む。ステップ１０１では、センターサーバー６が、図４に示す提供先－提供元対応テーブル３７より提供先ショップ１の提供先ショップｉｄに対応する提供元ショップ２の提供元ショップｉｄを読む。そして、ステップ１０３では、センターサーバー６は、この商品ａの販売店リストから提供元ショップ２に該当する商品データを抽出する。提供元ショップ２は複数のこともある。なお、提供元ショップ２がフリマのような場合には、提供元ショップ２の一店に対し、提供先ショップ１が複数関連付けされることもある。
但し、提供先－提供元対応テーブル３７を設けずに、提供先ショップ１毎に独立したサーバー（若しくはデータベース）を設置する。そして、それぞれのサーバー毎に予め指定をした提供元ショップ２について、この商品ａの販売店リストから提供元ショップ２に該当する商品データを抽出するようにしても良い。また、この指定をした提供元ショップ２についての商品データの抽出処理は、センターサーバー６では行わずに提供先ショップ１側のサーバー７で行うようにしても良い。若しくは、提供先－提供元対応テーブル３７を設けずに、提供先ショップ１毎に提供元ショップ２のデータベースをまとめる。そして、このデータベースに対してこの商品ａの販売店リストから提供元ショップ２に該当する商品データを抽出するようにしても良い。

その後、ステップ１０５では、センターサーバー６は、予めセンターサーバー６に登録されている提供先ショップ１のデフォルトの並び順に従い商品データを整列する。このデフォルト順は例えば、価格の安い順、提供元ショップ２の商品名順、クリック数順、提供元ショップ２の評価順等であり、提供先ショップ１の任意若しくはセンターサーバー６の所定の判断条件により決められたものである。但し、この並び替えは提供先ショップ１のサーバー７側にて行われても良い。ステップ１０７では、センターサーバー６が、この商品データを販売店リスト存在符号と共にＡＰＩで提供する。一方、ステップ９９で商品ａの販売店リストが存在しないと判断された場合にはステップ１０９に進む。そして、ステップ１０９では、センターサーバー６は販売店リスト不存在符号をＡＰＩで提供する。

ステップ１１１では、提供先ショップ１のサーバー７が通信部７５を介してＡＰＩにアクセスする。ステップ１１３ではサーバー７が販売店リスト存在符号を確認する。ステップ１１５で販売店リスト存在符号が存在した場合にはステップ１１７に進み、サーバー７がセンターサーバー６より商品データをＡＰＩを介して受信する。このとき受信した商品データにはショップｉｄ等が含まれている。ショップｉｄはセンターサーバー６により商品名に加える等されても良い。ショップｉｄ、商品コード、及びショップ名のいずれか少なくとも一つを加えても良い。このショップｉｄ等は提供元ショップ２の商品のみについて加えるようにしてもよい。商品コードには役務コードも含む（以下、同旨）
ステップ１１９では、サーバー７は、この商品ａが提供先ショップ１に属する商品か否かを判断する。

但し、この商品ａが提供先ショップ１に属する商品か否かはセンターサーバー６側で判断を行うことも可能である。そして、提供先ショップ１に属する場合にはステップ１２１に進み、サーバー７は、この商品ａの提供先ショップ１の商品データに整列済の販売店リストを加える。そして、ステップ１２５で、提供先ショップ１のサーバー７のｗｅｂページ作成部７９がこの商品データを取り込み商品詳細ページを作成する。

このときの商品詳細ページの概略図を図１５に示す。即ち、図１５において、商品詳細ページ１００には、この提供先ショップ１が元々所有している商品ａの商品画像、価格、商品説明文と購入ボタン１０１等がページの見易い中心部分に掲載され、この商品を販売する少なくとも一つの提供元ショップ２がこの商品の販売店リスト１０３として付記される。
この販売店リスト１０３には、提供元ショップ２のこの商品ａの販売店名、販売価格、送料が掲載されるが、商品名、商品画像等が付記されても良い。また、販売店リスト１０３はリンク先で別ページとして掲載されても良い。このリンク先は別サイトであっても良い。更に、この販売店リスト１０３に掲載された提供元ショップ２をクリックしたときには、例えば、後述する図１８に示すようなこの提供元ショップ２の商品ａの詳細説明文等を含む、より詳しい商品データが提供先ショップ１の商品詳細ページとして閲覧できるようにしてもよい。
そして、この提供元ショップ２の商品詳細ページには購入ボタン１０１が配設されてもよい。販売店リスト１０３に掲載された提供元ショップ２をクリックしたときにカートにリンクするとしてもよいが、この場合には改造が必要となる。上記のように提供先ショップ１の商品詳細ページにリンクとすることで改造は不要にできる。

なお、この商品詳細ページは提供先ショップ１のサイトに掲載されるが、別サイトに構成することも可能である。但し、図１８に示すような形で商品詳細ページにショップ名を追加することがサーバー７の改造に繋がる場合には、このショップ名や、このショップ名を含むコメント文（例えば、「この商品はＡ店より配送」等）をセンターサーバー６側で商品名中や商品説明文の適所（例えば上部）に自動で追加記載することで、改造を回避するようにしてもよい。文字は目立つように強調・装飾されたり、括弧で囲われたりするのが望ましい。このとき、ショップｉｄ、商品コード、及びショップ名のいずれか少なくとも一つを加えるようにしても良い。このショップｉｄ等は提供元ショップ２の商品のみについて加えるようにしてもよい。

なお、販売店リスト１０３のデータ、及び、提供先ショップ１が元々所有している商品ａの商品画像へのリンクＵＲＬ、価格、商品説明文等のテキストはＡＰＩやＣＳＶファイル等の形式でセンターサーバー６側で用意する。そして、提供先ショップ１のサーバー７側でこのデータを手動若しくは自動で読むようにしても良い。この際、この商品説明文テキストの適所（例えば下部）には、例えばｈｔｍｌソースコードの形式で記載された販売店リスト１０３のデータを含むようにしてもよい。このｈｔｍｌソースコードを商品説明文テキスト中に含む処理はセンターサーバー６側の演算部１１で行われることが望ましい。この場合には、サーバー７でＣＳＶファイル等を読むことで、特別な改造を行うことなく、商品説明文中に販売店リスト１０３を表示することができる。但し、提供先ショップ１側のｗｅｂページ作成プログラムが商品説明文を生成する際に、テキストのみの対応でｈｔｍｌソースコードに対応していない場合には、このｗｅｂページ作成プログラムをｈｔｍｌソースコードに対応可能とする改造を行うだけで済む。

これにより、ユーザが探し求めた商品ａの商品詳細ページに複数のショップが掲載されていることで、ユーザにとっては相場感も得易く購入され易い。販売店数が増加するため、いずれかのショップで購入される可能性が高くなる。在庫が無いために販売の機会を損失するおそれも少なくできる。
更に、ポイントの付与やカード決済等のこの提供先ショップ１が独自に行っているサービスを、この提供元ショップ２での商品購入にも適用することも可能であり、ユーザへのサービスの一層の充実を図ることができる。

一方、ステップ１１９の判断で、この商品ａが提供先ショップ１に属さない商品であると判断された場合には、ステップ１２３に進み、サーバー７は販売店リストに属するショップの内の一つを代表のショップとして抽出し、それに整列済の販売店リストを加える。そして、ステップ１２５で、提供先ショップ１のサーバー７のｗｅｂページ作成部７９がこの商品データを取り込み商品詳細ページを作成する。このときの商品詳細ページの概略図を図１６に示す。

即ち、図１６において、商品詳細ページ１１０にはこの提供先ショップ１が保有していないが、代表のショップとして抽出された提供元ショップ２が保有している商品ａの商品画像、価格、商品説明文と購入ボタン１０１等がページの見易い中心部分に掲載される。そして、この商品を販売している提供元ショップ２のショップ名１１３が付記されている。この代表のショップとしての提供元ショップ２の選択方法は任意であるが、例えば安い順や販売実績の多い順等によりサーバー７若しくはセンターサーバー６により１店舗が選択される。

更に、この商品ａを販売する残りの少なくとも一つの提供元ショップ２がこの商品の販売店リスト１１５として付記される。ここに提供元ショップ２のこの商品ａの販売店名、販売価格、送料が掲載されるが、商品名、商品画像等が付記されても良い。また、販売店リスト１１５はリンク先で別ページとして掲載されても良い。更に、この販売店リスト１１５に掲載された提供元ショップ２をクリックしたときには、例えば、後述する図１８に示すようなこの提供元ショップ２の商品ａの詳細説明文等を含む、より詳しい商品データが提供先ショップ１の商品詳細ページとして閲覧できるようにしてもよい。そして、この提供元ショップ２の商品詳細ページには購入ボタン１０１が配設されてもよい。
この場合、元々この商品ａの販売を提供先ショップ１ではしていなかったが、提供元ショップ２の商品データに基づき作成された商品詳細ページをもって販売することができる。従って、在庫が無くても商品の販売が可能となり、売上機会の増大に繋がる。また、作成された商品詳細ページは検索結果リストや一覧リストにも掲載可能であり、取り扱い可能な商品として充実させることができる。検索対象の商品点数が増えることでユーザによる商品検索の精度も向上する。
提供先ショップ１にとって、新規ジャンルを開拓する足掛かりとなり、本格的に参入する前にその効果を事前に予測することができる。

提供先ショップ１で在庫が無い場合であってもユーザは販売店リスト１１５で購入ができる。従って、提供先ショップ１での在庫切れに伴う購入機会の損失を防ぐことができる。
提供先ショップ１にとっては在庫を常に確保する必要が少なくなり、在庫管理の負担も軽減する。
ステップ１２７では、リクエストのあったユーザの情報端末に対してこの商品ａの商品詳細ページ１００、１１０が表示される。

一方、ステップ１１５で販売店リスト存在符号が見つからなかった場合にはステップ１２９に進み、サーバー７は販売店リスト不存在符号を確認する。そして、ステップ１３１では、サーバー７は、この商品ａは提供先ショップ１に属する商品か否かを判断する。提供先ショップ１に属する商品の場合にはステップ１３３に進み、サーバー７は提供先ショップ１の商品ａの商品詳細ページをユーザに表示する。

このときの商品詳細ページの概略図を図１７に示す。即ち、図１７において、商品詳細ページ１２０にはこの提供先ショップ１が元々所有している商品ａの商品画像、価格、商品説明文と購入ボタン１０１等がページの見易い中心部分に掲載されている。即ち、このページの構成はこの提供先ショップ１が本実施形態の適用前から元々実施しているものである。
ステップ１３１でこの商品ａが提供先ショップ１に属さない商品だった場合には、ステップ１３５に進み、サーバー７がＡＰＩを介してセンターサーバー６より個別商品データを受信する。個別商品データは、個別商品データベース４５に保存されていた商品データである。

ステップ１３７では、この受信をした提供元ショップ２の商品で商品詳細ページを作成する。
このときの商品詳細ページの概略図を図１８に示す。即ち、図１８において、商品詳細ページ１３０にはこの提供先ショップ１が保有していないが、提供元ショップ２が保有している商品ａの商品画像、価格、商品説明文と購入ボタン１０１等がページの見易い中心部分に掲載される。そして、この商品を販売している提供元ショップ２のショップ名１３３が付記されている。

この場合、元々この商品ａの販売を提供先ショップ１ではしていなかったが、提供元ショップ２の個別商品データに基づき作成された商品詳細ページをもって販売することができる。従って、在庫が無くても商品の販売が可能となり、売上機会の増大に繋がる。リピータの確保にも繋がり易くなる。また、検索結果リストや一覧リストにも掲載可能であり、取り扱い可能な商品として充実させることができる。検索対象の商品点数が増えることでユーザによる商品検索の精度も向上する。
提供先ショップ１にとっては在庫を常に確保する必要が少なくなり、商品点数が増えても在庫管理の負担は軽減する。在庫切れの不安は軽減する。
なお、センターサーバー６側で、商品ａが販売店リストがあるか否かを判断し、また、この商品ａが提供先ショップ１に属する商品か否かを判断する。サーバー７では、その判断結果をＡＰＩを介して読んだ上でその判断結果に基づき、図１５～図１８の各商品詳細ページを作成するようにしても良い。更に、センターサーバー６側で各商品詳細ページを作成しＡＰＩで渡すようにしても良い。更に、サーバー７の機能はセンターサーバー６側に配設されてもよい。この場合、提供先ショップ１のｗｅｂサイトはセンターサーバー６に構築される。

次に、商品詳細ページ作成の別方法について図１９のフローチャートに基づき説明する。なお、図１４と同一要素のものについては同一符号を付して説明は省略する。
図１４までに説明をした商品詳細ページ作成の処理では、商品データ解析プログラム２３が提供元ショップ商品データベース３９に保存されている提供元商品データ集合体について解析を行うことで同一の商品を見つけることで販売店リストを生成する。その後、この販売店リストから提供先ショップ１に応じた提供元ショップ２に絞った形で商品詳細ページを作成した。

これに対し、別方法では、提供先ショップ１に応じた提供元ショップ２の商品テーブルに対して解析を行うことで同一の商品を見つけ、その結果を論理加算した販売店リストで商品詳細ページを作成するものである。
図１９において、ステップ９１で、ユーザが提供先ショップ１のｗｅｂサイト９を訪問し、ステップ９３で検索結果や一覧リスト等から商品ａをクリックする。ステップ９５では、提供先ショップｉｄと、この商品ａに相当する商品ｉｄとがセンターサーバー６に対し送信される。

ステップ１０１では、センターサーバー６が、提供先－提供元対応テーブル３７より提供先ショップ１の提供先ショップｉｄに対応する提供元ショップ２の提供元ショップｉｄを読む。そして、ステップ１４１では、センターサーバー６は、各提供元ショップ２のそれぞれの商品テーブルを読む。この商品テーブルに属する商品データは提供元ショップ商品データベース３９に保存されており、巡回プログラム２１等により常に更新されたデータである。但し、全提供元ショップ２の商品テーブルを読むようにしても良い。また、図１４において説明したように、提供先－提供元対応テーブル３７を設けずに提供先ショップ１毎に独立したサーバー（若しくはデータベース）を設置する等しても良い。

ステップ１４３では、商品データ解析プログラム２３は、この商品テーブルの商品データを商品ｉｄに属する型式、ＪＡＮコード、商品名、商品画像の内少なくとも一つにより絞る。このときの解析方法はステップ２１での処理と同様である。ステップ１４５では、センターサーバー６は、抽出した結果をオアして販売店リストを作成する。そして、この作成した販売店リストを販売店リストデータベース３１に保存する。なお、ステップ１４３で絞った結果が０件のこともあるが、このときには販売店リストは作成されない。

ステップ９９では、センターサーバー６がこの商品ａの販売店リストが存在するか否かを判断する。ステップ９９で商品ａの販売店リストが存在すると判断された場合にはステップ１０５に進む。ステップ１０５では、センターサーバー６は、予めセンターサーバー６に登録されている提供先ショップ１のデフォルトの並び順に従い商品データを整列する。ステップ１０７では、センターサーバー６が、この商品データを販売店リスト存在符号と共にＡＰＩで提供する。

一方、ステップ９９で商品ａの販売店リストが存在しないと判断された場合にはステップ１０９に進む。そして、ステップ１０９では、センターサーバー６は販売店リスト不存在符号をＡＰＩで提供する。ステップ１１１では、提供先ショップ１のサーバー７が通信部７５を介してＡＰＩにアクセスする。
ステップ１１３以後、図１４のフローチャートと同様の処理を行い、４つの態様の商品詳細ページを作成する。
なお、提供先ショップ１のｗｅｂページで行われる検索の処理で述べたように、センターサーバー６より提供先ショップ１に対し、提供先ショップ１の商品データと個別商品データベース４５に保存されているデータ、及び販売店リストデータベース３１に保存されているデータのすべてをセンターサーバー６側でまとめた上で、定期的にこれらのデータをＣＳＶファイルに保存して提供したり、ＡＰＩ等で提供を行うようにしてもよい。

この場合、
（１）商品名中にショップｉｄ、商品コード、及びショップ名のいずれか少なくとも一つを記載する。従って、提供元ショップ２の商品であることが判断され易い。
（２）ショップ名を含むコメント文を商品名中や商品説明文中の適所に記載する。例えば、商品詳細ページが提供元ショップ２の商品のページである場合にはコメント文が挿入され、提供元ショップ２の商品で無い場合にはコメント文は挿入されない。
（３）商品説明文中の適所には、例えばｈｔｍｌソースコードの形式で記載された販売店リスト１０３のデータを含む。そして、例えば、販売店リスト１０３のデータが存在する場合にこのｈｔｍｌソースコードを商品説明文中に含み、存在しない場合にはこのｈｔｍｌソースコードを商品説明文中に含まない。
（１）～（３）の処理のいずれか少なくとも一つの処理を行った商品データを、ＣＳＶファイル若しくはＡＰＩ経由でセンターサーバー６側から提供先ショップ１に対し提供することが望ましい。

但し、上記したショップｉｄやコメント文、ｈｔｍｌソースコード等は、商品名や商品詳細ページに記載する以外にも型式欄、価格、送料、ポイント等の提供先ショップの通販サイトの商品詳細ページ中に掲載されるテキストデータに対し追記されるようにされてもよい。また、コメント文や販売店リスト１０３、ショップ名等は、画像欄等に画像化されたテキストデータとして表示されてもよい。
このことにより、提供先ショップ１で販売された商品をセンターサーバー６や提供元ショップ２で確実に特定できる。また、ユーザにとっては提供元ショップ２の商品であり、配送元が提供元ショップ２であることが理解され易い。更に、商品詳細ページで販売店リスト１０３を開示するのに特別なスペースを改めて設ける必要が無くなる。ショッピングカートも提供先ショップ１が元々備えているものをそのまま使える。（１）～（３）の処理により４つの態様の商品詳細ページにも対応できる。このため、提供先ショップ１では改造無く本システムを導入できる。但し、提供先ショップ１の商品データの一部又はすべて、例えば価格や在庫数等のリアルタイム性の高い項目については、提供先ショップ１側での管理を優先させるためにＣＳＶファイルやＡＰＩに含まないことも可能である。若しくは、かかる項目にはデータを記載せずに空欄としてもよい。また、これとは逆に、ＣＳＶファイルやＡＰＩに含めるデータを商品詳細文と商品名等に限定するとして、商品詳細文と商品名等についてのみ更新可能としてもよい。

更に、ＣＳＶファイルやＡＰＩについては、すべての項目とその項目に属するデータを含めた形で提供先ショップ１がエクスポートを行う。この場合、エクスポートされたデータはセンターサーバー６で解析のために利用することができる。
提供先ショップ１によるエクスポート、及び、エクスポートされたデータのセンターサーバー６へのアップロードは手動で行われても良いが、自動で行われるようにしてもよい。このエクスポートされたデータは提供先ショップ１の商品データと提供元ショップ２の商品データとに分離されてもよい。
一方、センターサーバー６が提供したＣＳＶファイルやＡＰＩについては、提供先ショップ１側でインポートされる。この際、インポートは全データについて行い、インポートした項目の内の提供先ショップ１の商品データの価格や在庫数等のリアルタイム性の高い項目についてはデータの更新をしないとすることも可能である。あるいは、提供元ショップ２の商品データだけについて更新を行い、提供先ショップ１の商品データについてはデータの更新をしないとされてもよい。

このときのセンターサーバー６からのデータのダウンロード及び提供先ショップ１側でのインポート処理も手動で行われても良いが、自動で行われるようにしてもよい。
更に、ＣＳＶファイル若しくはＡＰＩのフォーマットは４つの態様の商品詳細ページのそれぞれの作成に対応した４つのパターンのデザインテンプレートを用意してもよいが、一つのデザインテンプレートとする等より少ない共通化したデザインテンプレートで対応することもできる。この場合、４つの態様の如何によっては不要となる項目もできるが、不要となる項目については例えば空欄とすることで対応する。あるいは、態様により必要なｈｔｍｌソースコードをｗｅｂページ作成部７９が、デザインテンプレートの所定部分に対し自動で加えたり、加えなかったりしてもよい。

例えば、ＣＳＶファイル中に販売店リストのデータが存在するか否かにより、ｗｅｂページ作成部７９が、商品詳細ページのデザインテンプレートの所定部分（例えば商品説明文の右外側の適所）に対し販売店リストのｈｔｍｌソースコードを加えたり、加えなかったりする。これにより、販売店リストが存在する場合と存在しない場合とについて共通化したデザインテンプレートを用いることができる。
共通化したデザインテンプレートで対応することで、提供先ショップ１では改造を無くしたり、若しくは最小限にできる。このように４つの態様を共通化したデザインテンプレートで対応した場合や販売店リストを商品詳細ページに含めたり、ショップｉｄ等を商品名に含めた場合等には、ステップ１１３、ステップ１２９の販売店リスト不存在符号やステップ１１５、ステップ１３１の提供先ショップに属する商品か否かの判断は不要にできる。
また、既存の提供先ショップ１により改造をせずに構成する場合には、ステップ１２５で説明したように、販売店リストの各提供元ショップ２から直接ショッピングカートに連携することは困難である。そこで、販売店リストの各提供元ショップ２からリンクされた個別の商品詳細ページを用意し、この商品詳細ページに配設された購入ボタンからショッピングカートに連携されることが望ましい。

なお、販売店リストは必ずしも作成若しくは掲載されなくても良い。また、検索結果リスト、一覧ページ、関連商品欄には、個別商品についてのみ図１７と図１８に示す商品詳細ページを掲載することも可能である。また、販売店リストの作成を行うか否か、若しくは販売店リストを商品詳細ページ等に掲載するか否かや、個別商品についてのみ商品詳細ページを掲載するか否かを、提供先ショップ１の後述する管理画面２０１において選択できるようにしてもよい。更に、提供先ショップ１の商品と同じ提供元ショップ２の商品が存在する場合には、検索結果リスト等には提供先ショップ１の商品を掲載し、この同じ提供元ショップ２の商品を掲載しないようにしてもよい。そして、この掲載の可否も管理画面２０１において選択自在としてもよい。

更に、販売店リストに提供先ショップ１自身の商品データを掲載するか否かも管理画面２０１において選択自在としてもよい。また、販売店リストに提供元ショップ２自身の商品データを掲載するか否かを提供元ショップ２の後述する管理画面２０３において選択自在としてもよい。
更に、提供先ショップ１の管理画面２０１を通じて提供先ショップ１側でジャンル、メーカー名、ブランド名、仕様、商品名等の内の少なくとも一つを指定可能とする。検索キーワードによる検索も可能とすることが望ましい。そして、センターサーバー６では、この指定をされたジャンル等のデータを提供先ショップ１側から受信した後、このジャンル等で販売店リストデータベース３１と個別商品データベース４５について商品データを絞る。但し、提供先ショップ１の希望や選択によっては個別商品データベース４５についてのみ商品データを絞るようにしても良い。

その後、センターサーバー６は、この絞った結果の商品データをＡＰＩやＣＳＶファイルで提供先ショップ１のサーバー７に対して送信する。提供先ショップ１のｗｅｂページ作成部７９では、受信した商品データを取り込み一覧ページ、関連商品としてｗｅｂページを作成しユーザに対し表示する。一覧ページの作成は、元々有していた商品との混在をする。但し、前述した通り別枠で表示をしても良い。
しかしながら、ＡＰＩやＣＳＶファイルで受信した商品の一覧リストを選択自在に一旦提供先ショップ１の管理画面２０１に表示させ、提供先ショップ１側で必要な商品を選択してもらうようにしても良い。この場合、必要なジャンルを指定することで、そのジャンルに属する商品が選択されるようにしてもよい。

また、この際には、提供元ショップ２の商品が提供先ショップ１のどのジャンルに属するのかを選択できるようにしてもよい。
ここで選択された商品に関するデータはセンターサーバー６に送信される。この場合、選択された商品に関する商品データのみがセンターサーバー６で絞られた後、センターサーバー６よりＡＰＩを通じて提供される。若しくは、選択された商品については、提供先ショップ１のサーバー７の演算部７１で商品データを絞るようにしても良い。提供先ショップ１のｗｅｂページ作成部７９では、絞られた商品データを取り込み一覧ページ、関連商品としてｗｅｂページを作成しユーザに対し表示する。
なお、商品データはＡＰＩ経由ではなく、センターサーバー６と提供先ショップ１のサーバー７間でＣＳＶファイルにより行われても良い。
このことにより、提供先ショップ１では、例えば提供先ショップ１で元々掲載しているジャンルと共通した提供元ショップ２側のジャンルの内の必要な商品データのみを掲載できるようになり、提供先ショップ１側のサイトの商品掲載ポリシーを踏襲する形で販売力の強化を図ることができる。

但し、このような提供先ショップ１の管理画面２０１を通じての処理はセンターサーバー６で行うことも可能である。また、提供元ショップ２側でも同様に、提供元ショップ２から提供先ショップ１に対して提供可能な商品やジャンルを選択可能としてもよい。
また、この際には提供元ショップ２の商品が提供先ショップ１のどのジャンルに属するのかを選択できるようにしてもよい。この提供先ショップ１に対して提供可能な商品やジャンルの選択、ジャンルの関連付けはセンターサーバー６側で行えるようにしてもよい。なお、提供元ショップ２の管理画面２０３では、提供先ショップ１に対し商品データを提供するときの商品の販売価格を提供元ショップ２自身の通販サイトの価格とは異なる価格に調整可能としてもよい。

次に購入処理について説明する。図１５～図１８の商品ａの商品詳細ページにおいて購入ボタン１０１がクリックされると図示しないショッピングカートに商品ａが入れられる。また、販売店リスト１０３、１１５欄に掲載の提供元ショップ２の図示しない購入ボタンがクリックされると、同様にショッピングカートにこの提供元ショップ２の商品ａが入れられる。
なお、この提供元ショップ２をクリックした場合、図１８に示すようなこの提供元ショップ２の商品ａの詳細説明文等を含む、より詳しい商品データが提供先ショップ１の商品詳細ページとして閲覧できるようにしてもよい。そして、この商品詳細ページで購入ボタン１０１がクリックされてもよい。
その後、提供先ショップ１の決済処理が行われる。商品ａの購入があった旨は提供元ショップ２に連絡がされるので、提供元ショップ２は商品ａの発送の処理を行う。

なお、提供先ショップ１側で決済処理を行うのではなく、商品購入における決済処理は提供元ショップ２側で行うものとされてもよい。この場合、例えば、商品ａの商品詳細ページにおいてユーザにより購入ボタン１０１若しくは販売店リスト１０３、１１５欄に掲載されたショップがクリックされると、この購入ボタン１０１や販売店リスト１０３、１１５欄に埋め込まれたリンク先の提供元ショップ２側の商品詳細ページに進む。ユーザは、そこで商品の購入が可能である。そして、このクリックの都度に一定の金額が販売手数料として発生するようにしても良い。クリック数のカウントは提供先ショップ１側で行うか、センターサーバー６側で行うことが可能である。
あるいは、いわゆるアフィリエイト処理と同様に、商品購入における決済処理は提供元ショップ２側で行うものとし、ユーザが提供先ショップ１の商品ａの商品詳細ページ経由で提供元ショップ２で購入をしたことをセンターサーバー６側で確認することで販売手数料が発生するようにしても良い。

次に、提供先ショップ１と提供元ショップ２間の管理システムについて説明する。
図２０には、提供先ショップ１のＡ店と、このＡ店と提携をした提供元ショップ２－１、提供元ショップ２－２、提供元ショップ２－３の関係を示す。提供元ショップ２－３については、提供先ショップ１のＢ店と提供先ショップ１のＣ店とも提携を有している場合である。そして、各店のサーバーには本販売支援システムの管理ツールがインストールされている。但し、管理ツールは提供先ショップ側にだけインストールされてもよい。または、各店のサーバーに管理ツールをインストールするのではなく、各ショップの管理ツールはセンターサーバー６に配設されてもよい。

提供先ショップ１のＡ店で提供元ショップ２の商品ａが購入された旨は、購入のあった時点で提供先ショップ１のサーバー７の通信部７５を介して、提供先ショップ１のショップ名、この商品ａの商品情報、購入をしたユーザの氏名、商品ａの配送先等のデータが自動送信若しくはセンターサーバー６を介して解析がされ、提供元ショップ２のサーバー４の通信部５５で受信がされる。そして、この旨のデータは提供先ショップ１のサーバー７の管理部７７に保存されると共に、表示・操作部７３で制御される管理画面２０１で閲覧ができる。この旨のデータはまた、提供元ショップ２のサーバー４の管理部５７にも保存されると共に、表示・操作部５３で制御される管理画面２０３でも閲覧ができる。なお、管理画面２０１や管理画面２０３はセンターサーバー６を介しブラウザにて閲覧ができるようにされてもよい。

しかし、通信ではなく、あるいは、通信と併用して購入のあった際に提供先ショップ１のサーバー７より自動配信されるメールにて提供元ショップ２のサーバー４側に伝達されても良い。このメールはサーバー７よりユーザに向けて配信される販売確認のメールの写しであってもよい。通信ではなくメールだけが配信された場合には、メール文から必要な情報をサーバー４のプログラムが抽出できるように予め定義をしておく。但し、メール文はセンターサーバー６側に配信され、そこで解析され、解析した結果がサーバー４側に伝えられるようにしてもよい。そして、解析した結果をセンターサーバー６の管理画面２０１や管理画面２０３にて閲覧ができるようにされてもよい。
メール文には提供先ショップ１のショップ名、商品ａの商品情報、購入金額、購入日時、購入をしたユーザの氏名、商品ａの配送先等のテキストが記載されている。なお、ステップ１１７で説明したようにセンターサーバー６側でショップｉｄ等が商品名に加えられている場合には、このコード等を解析することでショップ名を判断することができる。

また、提供元ショップ２で受注のあった商品ａをユーザに対して発送した場合には管理画面２０３に表示される図示しない発送完了のボタンをクリックする。このとき、前述とは逆に提供元ショップ２のサーバー４の通信部５５を介して送信がされ、提供先ショップ１のサーバー７で受信がされる。発送完了の旨のデータは提供先ショップ１のサーバー７の管理部７７に保存されると共に、表示・操作部７３で制御される管理画面２０１で閲覧ができる。

この旨のデータはまた、提供元ショップ２のサーバー４の管理部５７にも保存されると共に、表示・操作部５３で制御される管理画面２０３でも閲覧ができる。発送完了の旨は、提供元ショップ２のサーバー４、若しくは提供先ショップ１のサーバー７よりユーザに向けてメール配信される。
なお、管理画面２０３がセンターサーバー６に配設された場合には、発送完了のボタンはセンターサーバー６を介した管理画面２０３に表示される。また、管理画面２０１がセンターサーバー６に配設された場合には、発送完了の旨のデータはセンターサーバー６を介した管理画面２０１で閲覧ができる。そして、この場合、発送完了の旨は、センターサーバー６よりユーザに向けてメール配信される。
また、提供元ショップ２のサーバー４の管理部５７、提供先ショップ１のサーバー７の管理部７７では、商品の販売履歴を基に演算部５１、演算部７１により計算された在庫数や、販売手数料が保存される。この在庫数や、販売手数料についてもセンターサーバー６の演算部１１で計算されてもよい。

次に、販売履歴データの管理について説明する。
図２１では、提供先ショップ１のサーバー７の管理部７７に保存されている販売履歴データが管理画面２０１に表示された様子を概念図で示している。管理画面２０１では、提供先ショップ１（自社）で取り扱いのある商品の販売履歴と各提供元ショップ２の商品の販売履歴とが時系列に記録されている。

例えば、提供先ショップ１のｗｅｂサイト９において、１月６日９時には自社取り扱いの商品が売れた。そして、１月６日１０時には、提供元ショップ２－１の商品１が売れた。このため、提供元ショップ２－１の商品１の販売個数を１つインクリメントする。続いて、１月７日８時には、提供元ショップ２－２の商品２が売れた。このため、提供元ショップ２－２の商品２の販売個数を１つインクリメントする。以下、同様に販売のあった旨が記録されている。

但し、サーバー７の管理部７７では、自社取り扱いの商品の販売履歴と各提供元ショップ２の商品の販売履歴とを別々に管理して表示するようにしても良い。また、商品１をクリックすると商品１だけについての販売履歴も閲覧できる。ショップ名をクリックしたりタブを切り替えることで、各ショップ毎にまとめた販売履歴や販売実績も閲覧できる。
サーバー７の演算部７１では販売手数料が計算可能であり、例えば提供元ショップ２－１の商品１がこの時点までに合計３個売れたとすると、販売手数料の単価が１００円だったとして１００円×３個＝３００円と計算がされる。

また、図２２には提供元ショップ２－３側のサーバー４の管理部５７に保存されている販売履歴データが管理画面２０３に表示された様子を概念図で示している。管理画面２０３では、各提供先ショップ１で購入された商品の販売履歴と提供元ショップ２－３の商品（自社）の販売履歴と在庫数が時系列に記録されている。
但し、サーバー４の管理部５７においても、自社取り扱いの商品の販売履歴と各提供先ショップ１の商品の販売履歴とを別々に管理して表示するようにしても良い。
例えば、当初、提供元ショップ２－３の商品３についての在庫数が５個であったとする。そして、図２２では、１月９日１１時に提供先ショップ１のＡ店のサイトで、この提供元ショップ２－３の商品３が１個売れたことが履歴として表示されている。なお、この販売の旨は図２１に示すように、提供先ショップ１側にも１月９日１１時に商品３の売れたことが履歴として保存される。

この時点で、提供元ショップ２－３側のサーバー４の演算部５１が商品３の在庫を１個デクリメントして４個とする。
１月９日１２時には、提供元ショップ２－３（自社）で商品３が１個売れた。このため、演算部５１が商品３の在庫を１個デクリメントして３個とする。続いて、１月９日１３時には、提供先ショップ１のＢ店のサイトで、この提供元ショップ２－３の商品３が１個売れた。このため、演算部５１が商品３の在庫を１個デクリメントして２個とする。
このようにして、販売履歴と在庫の管理がまとめて閲覧可能である。
なお、管理画面２０１、管理画面２０３がセンターサーバー６に配設された場合には、演算部５１、演算部７１はセンターサーバー６に備えられる。

図２３には、提供元ショップ２－３を例に、提供元ショップ２が同時に提供先ショップ１にもなっている場合を示している。この場合、例えば図２０において、Ａ店と提供元ショップ２－３とは互いに提供先と提供元を兼ねるようにしても良い。
この場合であっても同一の管理画面２０３で管理が可能である。但し、提供元ショップ２としての管理画面と提供先ショップ１としての管理画面を別に閲覧可能としても良い。タブで切り替えられるようにしても良い。
なお、このショップ同士のいわゆる相互販売の関係は、例えばこの提供元ショップ２－３において複数の提携先との間で設定されても良い。また、ショップが提供元ショップ２の立場を選ぶか、提供先ショップ１の立場を選ぶかはこのショップ自身の判断で自由に決められる。

また、商品在庫の有無や在庫の個数はセンターサーバー６が提供元ショップ２のｗｅｂページにて判断しても良いが、提供元ショップ２側からセンターサーバー６側にこれらのデータの送信がされても良い。在庫の無くなった商品についてはＡＰＩを介してセンターサーバー６より提供先ショップ１に対してその旨の送信がされる。しかしながら、この場合にはＡＰＩからこの商品の商品データの提供をしなくするとされても良い。

更に、販売履歴と在庫の管理データは本販売支援システムで提携のショップやモールだけではなく、提携していないショップやモールのデータも含めて履歴管理されるようにしても良い。この場合には、このショップやモールより、メールで販売データを受信し、前述したようにメール内容を自動で解析して掲載する。
この販売データのメールは、このショップやモールより直接受信しても良いが、転送メールを受信するようにしても良い。
以上により、提供先ショップ１は複数の提供元ショップ２が参加した通販モールにできる。このとき、既存の提供先ショップ１の通販システムをそのまま利用し、改造が無く、若しくは少ない改造でモール化を実現できる。センターサーバー６内に提供先ショップ１を新しく配設した場合でも同種の商品のまとめられた、あるいは、複数の提供元ショップ２の商品が取り扱われる購入のされ易いモールを実現できる。また、ショップ同士の間での相互販売や提携したショップとの間の提携相手側の商品を取り扱った販売が、実商品の移動の無い状態でも改造無く、若しくはわずかの改造だけで簡単に実現できる。

なお、相互販売、提携販売をしている提携先に対し、販促のために行う自店のキャンペーンの内容を管理画面２０１、２０３を通じて知らせて賛同をしてくれるショップを募るようにしてもよい。キャンペーンの告知は、提供先ショップ１、提供元ショップ２を問わずに可能である。
この場合、キャンペーンの期間はショップ間で同じにして複数のショップ同士で共通したキャンペーンを行うことが望ましい。賛同のキャンペーンを行うかどうかは互いに自由に決められる。
具体的には、図示は省略するが、管理画面２０１、２０３において、「キャンペーン提案を発信する」タブと「他店からのキャンペーン提案を読む」タブを設ける。「キャンペーン提案を発信する」タブをクリックすると、開かれたページにおいて、まず、キャンペーンの期間が設定可能なようになっている。そして、このキャンペーンの対象とする範囲を自店のすべての商品について行うのか、一部の商品について行うのか、特定のジャンルについて行うのか等が設定可能なようになっている。

また、キャンペーンの内容を選択することができる。このキャンペーンの内容は例えば送料無料とする、おまけを付ける、合計金額が幾ら以上で送料無料とする、金額の何％の現金還元する、値引する、ポイントを付与する等である。この際に原資の必要な場合にはこの原資の負担元を選択できるようになっている。また、キャンペーンの内容はテキストボックスにテキスト入力をして自由に記述ができるようになっている。そして、送信相手先はすべての提携先のショップを対象とするのか、あるいは、ポップアップ画面に表示された提携先ショップの送信相手先候補の内から選択をして送信相手先を決めるのかが選択できるようになっている。これらの選択をしてから送信するボタンを押すと、指定された送信相手先に対してこのキャンペーンの内容が送信されるようになっている。

一方、「他店からのキャンペーン提案を読む」タブをクリックすると、他店からのキャンペーン提案が閲覧できる。このページにはキャンペーン提案をしたショップ名、キャンペーンの期間、キャンペーン内容の要点、詳細ページに進むリンクとがリスト形式にまとめて記載されている。そして、詳細ページに進むリンクをクリックするとこの提案内容が詳細に分かるようになっている。そこで、自店でもこのキャンペーンに賛同する場合には、賛同ボタンを押す。この際、返答の必要な項目が存在する場合については選択形式、若しくはテキストボックスへのテキスト入力で返答を行う。
これにより、提携先ショップ１において、自店の商品だけではなく、賛同した複数の提供元ショップ２の商品についてもまとめて自店の商品と同一内容のキャンペーンを実施できる。あるいは、賛同した複数のショップ間で互いに同一の時期に同一の内容のキャンペーンを実施できる。このため、相互販売、提携販売をしているショップ同士の間で共創関係が築かれ、共通するキャンペーンの下に販売力の強化が図れる。

次に、ショップが、デリバリーや資料請求、クーポン適用、テイクアウト、予約、注文、外国人購入用、ライブコマース、動画による広告等の仕組みを導入する方法について説明する。
まず、既存のショップにおいて、これらの仕組みを導入する方法について説明する。
センターサーバー６では、既存のショップに対してこれらの仕組みを導入する旨の申請が行えるようになっている。ここに、デリバリーはネットを介して食事を自宅や会社まで届ける仕組みであり、資料請求はユーザがネットを介して必要な資料の請求ができる仕組みであり、クーポン適用は、発行されたクーポンをネットを介してユーザが利用できるようにする仕組みであり、テイクアウトは、商品の持ち帰りをネットを介して可能とする仕組みであり、予約は、宿泊の予約、飲食のテーブル席の予約、商品購入の予約等がネットを介して行えるようにする仕組みである。また、現金還元は、ネット上で現金値引で商品が購入できる仕組みであり、価格交渉は、システム上で仮想におかれた店員との間でネット上で価格の交渉ができる仕組みである。外国人購入用は、海外又は国内にいる日本語に習熟していない外国人ユーザからの国内販売商品の注文、購入ができる仕組みである。

次に、ネットを介して資料請求する場合を例に以下説明する。
図２４のフローチャートに示すように、ステップ１５１では、図７のステップ１～ステップ４と同様に、例えば資料請求を行いたいという旨の申請のあったショップＫ店よりセンターサーバー６は、商品データを収集する。このときの収集はショップＫ店の通販サイトに対して巡回プログラム２１により自動で行ってもよいが、ＣＳＶファイルの提供や人手による作業で行ってもよい。毎回の巡回ではなく、更新のあったときだけデータ取得やデータ入力をしてもよい。
そして、ステップ１５３では、収集されたＫ店の商品データについて、センターサーバー６の商品データ解析プログラム２３は、図２５に示すような商品詳細ページ１４０に掲載される商品説明文１４１中の適所（例えば商品説明文１４１中の最上位部分）に対し、資料請求ボタン１４３の画像ＵＲＬ、ショップｉｄや商品コードをパラメータとして含むリンク先のＵＲＬがｈｔｍｌの形式で記載されたソースコードを自動で埋め込む。資料請求ボタン１４３の画像はセンターサーバー６のデータベース３０に準備されている。商品コードはそれぞれの商品詳細ページ１４０に掲載される商品に応じて埋め込まれる。但し、商品説明文１４１中には、資料請求ボタン１４３を表示するためのスクリプトをソースコードとして埋め込んでも良い。スクリプトは例えばジャバスクリプト（登録商標）で構成され、商品詳細ページ１４０中に資料請求ボタン１４３を配設してもよいが、一旦ポップアップ画面を表示し、その画面中に資料請求ボタン１４３を配設する等してもよい。また、商品詳細ページ１４０中にリンクを生成し、このリンクをクリックすることでポップアップ画面を表示するようにしてもよい。
ステップ１５１で収集をした商品データを、前回取得した商品データとの間での一致を判断すれば、商品データが追加、削除、更新されたことが分かる。これに合わせてセンターサーバー６の商品データ解析プログラム２３では、これらの追加、削除、更新のあった商品データについての編集を行う。この際、追加、更新のあった商品データについては資料請求ボタン１４３用のソースコードを自動で埋め込む。

ステップ１５５では、この処理の行われた商品データを、センターサーバー６はＣＳＶファイルに保存し、このＣＳＶファイルをＫ店に対し提供、若しくはＡＰＩ経由でＫ店のサーバーに対し提供する。ステップ１５７では、Ｋ店ではこのＣＳＶファイルをインポートし、若しくはＡＰＩ経由で商品データを取得することで、Ｋ店のサーバーのｗｅｂページ作成部がデザインテンプレートに対してこの商品データを流し込み、商品詳細ページ１４０を自動作成する。ＣＳＶファイルをインポートする場合は、手動若しくは自動で対応可能である。

次に、図２６のステップ１６１では、このＫ店の通販サイトを訪れたユーザが、この商品詳細ページ１４０において資料請求ボタン１４３をクリックする。この場合、ステップ１６３では、ショップｉｄや商品コードをパラメータとして含むリンク先のＵＲＬがセンターサーバー６に送信される。そして、ステップ１６５でセンターサーバー６が、このＵＲＬを受信し、ステップ１６７でショップｉｄや商品コードが解析される。ステップ１６９では、ユーザ対応・管理プログラム２５が動作し、センターサーバー６側でショップｉｄや商品コードに対応する必要項目と内容がユーザ対応・管理データベース４７より読まれる。

なお、この資料請求に必要な項目と内容については、Ｋ店が予めセンターサーバー６の管理画面において登録をしておくことが望ましい。ここで設定された事項の内のユーザ向けの事項については、ユーザ対応・管理プログラム２５の処理の過程でユーザに対して表示が行われる。即ち、ユーザ対応・管理データベース４７より読まれた必要項目と内容に基づき、資料請求の処理の過程で表示されるユーザに対する問い合わせや、必要項目の選択や登録、お知らせ等を含む画面が作成される。その後、ステップ１７１で表示された画面に対し、ユーザによる必要項目の選択や登録等の応答が行われる。その後、資料請求の処理が完了した場合には、ステップ１７３で、センターサーバー６よりユーザ及びＫ店に対し請求の完了した旨が画面及びメールにより通知される。
これにより、Ｋ店では改造無く容易に資料請求ボタン１４３を追加できる。資料請求ボタン１４３に限らず、デリバリー用ボタン、クーポン適用ボタン、テイクアウト用ボタン、予約用ボタン、現金還元用ボタン、価格交渉用ボタン、購入ボタン、外国人購入用ボタン、ライブコマース開始ボタン等も同様に適用が可能である。一つだけボタンを配設するのではなく、これらの複数のボタンを処理の必要な分だけ配設してもよい。

次に、相互販売、提携販売、モール化を行っている提供先ショップ１が購入、デリバリー、資料請求、クーポン適用、テイクアウト、予約、注文、外国人購入等の仕組みを導入する際に、提供先ショップ１と提供元ショップ２間や、各提供元ショップ２毎に異なる内容の購入等の処理画面をユーザに対し表示する方法について説明する。
相互販売、提携販売、モール化を行う際には、提供先ショップ１の既存の購入等の処理システムをそのまま使うことが可能である。この場合、提供先ショップ１と各提供元ショップ２の間で購入等の処理の仕様が同一であったり、一様に統一ができれば、従来通りの提供先ショップ１の同一の仕様に基づく処理をそのまま行うということで問題はない。
しかしながら、例えばデリバリー等を行う同業者同士で相互販売を行う場合には、提供先ショップ１と各提供元ショップ２の間や、各提供元ショップ２同士の間に配達や製造時間等において仕様上のずれ等が生ずることがある。以下は、この仕様上のずれをセンターサーバー６において管理画面の設定で補うことで、相互販売、提携販売への参加を促進する方法である。なお、異業種の事業者間において相互販売が行われる場合には、より仕様上の相違は鮮明となるが、同様の設定方法で各提供元ショップ２毎に独自の仕様を決めることで、参加を促進できるものである。

デリバリーについて一例をあげれば、デリバリーにおける配達までの準備時間や配達料、配達を行う事業者が提供先ショップ１と各提供元ショップ２のそれそれの間で異なっていたと仮定する。このような場合に、センターサーバー６で提供する図２７に示すような提供元ショップ２の管理画面２０５において、各提供元ショップ２はそれぞれ、事前に自店で対応の可能な注文を受けてからの商品の製作完了までの時間の設定や配達時間の設定、配達料、配達を行う事業者の仕様の設定等を行う。但し、この仕様の設定内容は事業者の要望等如何により変更され得るものである。このため、事業内容毎にセンターサーバー６側で仕様を各事業者が選択し易いようにまとめて、各事業内容毎に必要な設定項目や仕様を予め用意しユーザ対応・管理データベース４７に保存しておくことが望ましい。設定項目は例えば、「注文を受けてから製作完了までの標準時間」や「配達までの標準時間」であり、仕様は「５分」、「１０分」、「１５分」等である。この仕様は事業者により選択できることが望ましいが、自由記入ができるようにしてもよい。
なお、事業者に対し管理画面２０５を表示するに際しては、センターサーバー６が予め登録されている各事業者の事業内容をまずデータベース３０から読み、その事業内容に一致する設定項目や仕様をユーザ対応・管理データベース４７から抽出して各事業者に応じた管理画面２０５のｗｅｂページを自動で作成して表示する。
また、各事業内容毎に各事業者間で共通できる部分と共通できない部分とに分離しておき、事業者には共通部分をまず先に設定若しくは記入してもらい、共通できない部分はその後に特殊事項として設定若しくは記入してもらうことが望ましい。ここで事業者により設定や入力された情報はユーザ対応・管理データベース４７に保存される。

次に、フローチャートに従ってデリバリー等の仕組みを導入する方法を説明する。図２８のフローチャートに示すように、ステップ１８１では、図７のステップ１～ステップ４や図８のステップ５～ステップ１０と同様に、デリバリーを行いたいという旨の申請のあった提供先ショップ１と各提供元ショップ２よりセンターサーバー６は、商品データを収集する。このときの収集は巡回プログラム２１により自動で行ってもよいが、ＣＳＶファイルの提供や人手による作業で行ってもよい。毎回の巡回ではなく、更新のあったときだけデータ取得やデータ入力をしてもよい。

ステップ１８３では、提供元ショップ２の商品データの内、予め提供先ショップ１により選択された商品のみをセンターサーバー６にて抽出する。即ち、提供先ショップ１は、データ取得をした商品の全体を以降の処理の対象としてもよいが、自店で掲載を希望する必要な商品のみを選択するようしてもよい。自店で必要な商品の選択はセンターサーバー６の管理画面にて行える。なお、提供元ショップ２の商品データは、提供元ショップ２により選択されたものであってもよい。
その後、センターサーバー６では、ステップ１８３で選択された各提供元ショップ２の商品データと提供先ショップ１の商品データに対して、ステップ１８５で以下の編集を行う。即ち、商品データ解析プログラム２３はこの商品データに対して、デリバリーボタンの画像ＵＲＬ、ショップｉｄや商品コードをパラメータとして含むリンク先のＵＲＬがｈｔｍｌの形式で記載されたソースコードを自動で生成する。
そして、この生成したソースコードを提供先ショップ１と各提供元ショップ２の商品説明文１６１中の適所（例えば上部）に自動で追加記載する。図２９には、提供元ショップ２の商品説明文１６１の上部に対し、生成したデリバリーボタン１６３を配設した画面例を示す。この場合には改造は不要である。なお、ソースコードは上記したようにスクリプトで構成してもよい（以下、同旨）。

なお、もともと提供先ショップ１が商品詳細ページに掲載している図５等に示す購入ボタン１０１は、商品詳細ページから消すように改造がされてもよい。
また、図３０の提供元ショップ２の商品詳細ページ１７０の例に示すように、生成したデリバリーボタン１７３用のソースコードは、もともと配置されていた購入ボタン１０１や注文ボタン等のソースコードに代えて、その同じ箇所に対し埋め込むようにサーバー７側の改造を行ってもよい。あるいは、デリバリーボタン１７３が購入ボタン１０１や注文ボタン等と併存して表示されるようにしてもよい。デリバリーボタン１７３が商品詳細ページ１７０のヘッダ部分等の上部に表示されるようにしてもよい。これらの場合、コメント文と共にボタンが表示されるのが望ましい。バナーとして表示されてもよい。デリバリーボタン１６３、１７３の画像はセンターサーバー６のデータベース３０に準備されている。このようにデリバリーボタン１７３用のソースコードを差し替えたり埋め込む点は、ショップが相互販売、提携販売、モール化を行わない場合であっても適用可能である。
なお、デリバリーボタン１７３用のソースコードはデリバリーボタンの画像ＵＲＬ、ショップｉｄをパラメータとして含むリンク先のＵＲＬがｈｔｍｌの形式で記載されたソースコードであり、商品コードに相当するパラメータ部分を空欄にした状態で提供先ショップ１に対して提供されることが望ましい。そして、提供先ショップ１側のサーバー７のｗｅｂページ作成部７９では、この空欄部分に対して提供先ショップ１側で割り振っている商品コードを埋め込んだ形で商品詳細ページ１７０を生成する。商品コードは、それぞれの商品詳細ページ１７０に掲載される商品に対応して生成される。この商品コードはステップ１８１で収集された商品データからセンターサーバー６側で既に認識されているので、センターサーバー６では商品毎に円滑にデリバリーの処理ができる。但し、商品コードは、提供先ショップ１においてセンターサーバー６側で生成したものを用いても良い。この場合でも共通した商品コードで処理ができるので、センターサーバー６側では商品毎に円滑にデリバリー等の処理ができる。
また、センターサーバー６では、商品詳細ページ１７０のＵＲＬを取得し、そのＵＲＬ中に含まれる商品コードを解析するようにしてもよい。このＵＲＬは、デリバリーボタン１７３等のリンクボタンがクリックされることにより、センターサーバー６に対しリンク用ＵＲＬに付属のパラメータとして送信元ＵＲＬが送信されるので、センターサーバー６側でこの送信元ＵＲＬを取得できる。また、商品詳細ページ１７０のＵＲＬはスクリプトにより取得をし、センターサーバー６に送信するようにしてもよい。ショップ名は、ＵＲＬ中のドメインを抽出することで特定できる。このようにして取得をした商品コードとショップのデータについて、センターサーバー６側ではデータベース３０を参照して商品を特定でき、商品毎に円滑にデリバリー等の処理ができる。リンク用ＵＲＬを含むソースコードは、ショップ側のすべての商品詳細ページに対して共通の一行程度のソースコードとして提供できる。
ショップが相互販売、提携販売、モール化を行っている場合であってもすべての商品詳細ページに対して共通のソースコードを埋め込めば良いので簡単である。デザインテンプレート利用であれば１カ所だけ修正すればよい。
なお、センターサーバー６側で商品を特定するに際しては、商品詳細ページ１７０中の適所にスクリプトを埋め込んでおき、タイトル又は商品名を取得することで行なっても良い。タイトルを抽出した場合には、このタイトルから商品名を抽出する。これにより、商品を判断してもよい。このタイトルからはショップ名も抽出できる場合もあるが、商品詳細ページ１７０のソースコード中よりショップ名が抽出されてもよい。
また、商品詳細ページ１４０、１６０、１７０には資料請求ボタン１４３やデリバリーボタン１６３、１７３を配設するのではなく、アンカーテキストを埋め込むようにしてもよい。この場合、ソースコードには資料請求ボタンやデリバリーボタンの画像ＵＲＬではなく、アンカーテキストを含むようにする。

ステップ１８７では、センターサーバー６において、ショップ名や、このショップ名を含むコメント文（例えば、「この商品はＡ店の商品でＡ店より配送します」等）を商品名中や商品説明文１６１、１７１の適所（例えば上部）に自動で追加記載する。この追加記載は図２９の商品説明文１６１中の上部や図３０の商品説明文１７１中の上部に埋め込んだコメント文１６５に示すように、各提供元ショップ２の商品データに対して行い、提供先ショップ１の商品データに対しては不要である。文字は目立つように強調・装飾されたり、括弧で囲われたりするのが望ましい。コメント文１６５の埋め込みについては、センターサーバー６において商品説明文１６１、１７１中へのテキストやタグの挿入により行われるので、提供先ショップ１側での改造は不要である。但し、挿入に限るものではなく、目立ち易いように商品説明文１６１、１７１の一部のテキストや画像等について削除や変更等の編集がされてもよい。また、ショップ名やコメント文は、ステップ１８５で生成をしたソースコード中に埋め込むようにしても良い。更に、ショップ名やコメント文は、前述したスクリプトにより表示されたポップアップ画面等に表示されてもよい。ショップ名やコメント文には他言語の翻訳文が記載されてもよい。
更に、提供先ショップ１や提供元ショップ２の商品データに対しては、例えば商品説明文１６１、１７１中の下部等に、商品説明文１６１、１７１中に記載された商品説明のテキストの一部又はすべてを、センターサーバー６において他言語に翻訳したテキストを埋め込むようにしてもよい。商品説明文１４１についても同様である。この場合についても同様にショップ側での改造は不要である。そして、この翻訳したテキストの上部や下部に資料請求ボタン１４３やデリバリーボタン１６３、１７３を配設してもよい。
また、ステップ１５１で収集をした商品データについて、この商品データの追加、削除、更新のされたことを判断することで、これに合わせて自動的に翻訳したテキストの埋め込みも可能である。従ってショップ側での手間は不要である。

ステップ１８９では、この処理の行われた商品データを、ＣＳＶファイルとして、若しくはＡＰＩ経由でセンターサーバー６は提供先ショップ１に対して提供する。ステップ１９１では、提供先ショップ１が手動若しくは自動でこのＣＳＶファイルをインポートし、またはＡＰＩ経由で商品データを取得することで、ｗｅｂページ作成部７９がデザインテンプレートに対してこの商品データを流し込み、商品詳細ページ１６０、１７０を自動作成する。
デリバリー用ボタンに限らず、資料請求ボタン、クーポン適用ボタン、テイクアウト用ボタン、予約用ボタン、現金還元用ボタン、価格交渉用ボタン、購入ボタン、外国人購入用ボタン、ライブコマース開始ボタン、動画による広告ボタン等も同様に適用が可能である。商品詳細ページ１６０、１７０にはこれらの内の少なくとも一つのボタンを配設してもよい。また、複数のボタンを並べて配設してもよい。

なお、デリバリー用ボタンを埋め込むのではなく、販売店リスト１０３、１１５をデリバリー対応可能な販売店のリストとしてもよい。そして、この販売店リスト１０３、１１５に掲載のショップをクリックした場合には、センターサーバー６で用意しているこのショップ用のデリバリー処理が上記と同様に動作するようにしてもよい。また、この販売店リスト１０３、１１５に掲載のショップをクリックした場合には、センターサーバー６で提供元ショップ２の商品データに基づく商品詳細ページが生成されてユーザに対し表示され、そのページ中にデリバリー用ボタンが配設されてもよい。
更に、販売店リスト１０３、１１５に掲載のショップをクリックした場合には、提供先ショップ１が、例えば図１７、図１８に示すような個別の商品詳細ページ１２０、１３０を生成する。そして、そのページに上述した方法によりデリバリー用ボタンを埋め込むようにしてもよい。
あるいは、商品詳細ページ１６０、１７０にはデリバリー対応の可能な販売店リストを含むｗｅｂページをリンク先としたＵＲＬを埋め込んだボタン、若しくはアンカーテキストが配設されてもよい。

図３１のステップ２０１では、この提供先ショップ１の通販サイトを訪れたユーザが、商品詳細ページ１６０、１７０においてデリバリーボタン１６３、１７３をクリックする。但し、ボタンではなくアンカーテキストがクリックされるようにしてもよい。
この場合、ステップ２０３では、ショップｉｄや商品コードをパラメータとして含むリンク先のＵＲＬがセンターサーバー６に送信される。そして、ステップ２０５でセンターサーバー６が、このＵＲＬを受信し、ステップ２０７でショップｉｄや商品コードが解析される。ステップ２０９では、センターサーバー６のユーザ対応・管理プログラム２５が動作し、このショップｉｄや商品コードを基に例えば注文画面を生成し、ユーザの使用するパソコン３やスマートフォン５等の情報端末に配信する。
但し、商品詳細ページ１６０、１７０には、デリバリーボタン１６３、１７３の代わりにリンクを埋め込み、このリンクがクリックされたときにはセンターサーバー６側で作成した商品詳細ページを出すようにしてもよい。この商品詳細ページには商品説明文、コメント文、商品名、注文に際しての注意事項等を掲載する。また、これらに対する他言語の翻訳文を掲載してもよい。そして、この商品詳細ページ中に掲載されたデリバリーボタンをクリックした後に注文画面を生成するようにしてもよい。商品詳細ページ１４０についても同様である。ステップ２１１では、この注文画面に対してユーザが注文数を入力してセンターサーバー６へ送信する。そして、ステップ２１３ではセンターサーバー６が注文数データを受信する。

ステップ２１５では、図２７の管理画面２０５において、予め事業者毎に設定されユーザ対応・管理データベース４７に保存されている設定仕様データが読まれる。ステップ２１７では、現在の注文数と注文の日時が読まれる。その後、ステップ２１９では、設定仕様データの内容を基に現在の注文数と注文の日時から、ユーザ対応・管理プログラム２５が製品完成までの時間及び配達までの時間を演算する。但し、この演算は多数の実績データを基にＡＩが推定するようにしてもよい。ステップ２２１では、この演算結果並びに設定仕様データに基づき図３２に示すような、ユーザに対するこの提供元ショップ２の問い合わせ画面２０７がユーザ対応・管理プログラム２５により自動的に生成される。この問い合わせ画面２０７中には、購入される商品が提供元ショップ２の商品である旨が記載され、事前に提供元ショップ２が登録した情報に基づきデリバリーに必要な表示がされる。

このことにより、各提供元ショップ２毎に応じたきめ細かな情報を有する問い合わせ画面２０７を表示できる。また、ユーザにとってはこの商品を提供するショップや配達元を確実に把握できる。ステップ２２３では、この問い合わせ画面２０７に対してユーザが応答し「次へ」ボタンを押すと、決済処理に進み、その後、ステップ２２５で注文が確定する。その後、ステップ２２７ではユーザ及び提供先ショップ１と提供元ショップ２に対し注文の確認メールが配信される。
以上により、相互販売、提携販売、モール化で提供先ショップ１と各提供元ショップ２がそれぞれ異なる内容のデリバリー仕様、テイクアウト仕様や予約仕様等を希望する場合であっても容易に対応ができる。

次に、デリバリー等についてネット上で注文を受けた場合とリアル店舗で注文を受けた場合の融合方法について説明する。
以下、図３３の商品詳細ページ１８０に示すようなラーメン店の場合をショップの例として説明する。
このラーメン店（Ａ店）の例では、商品データの多くがこのｗｅｂページ内に記載されており、注文ボタンの類は存在しないものと仮定する。このｗｅｂページ内の適所にデリバリーボタン１８３を配設する。デリバリーボタン１８３用のソースコードはデリバリーボタンの画像ＵＲＬ若しくはアンカーテキスト、ショップｉｄや事業種類コードをパラメータとして含むリンク先のＵＲＬがｈｔｍｌの形式で記載されたソースコードである。パラメータには複数の商品をまとめたグループ毎のグループｉｄが含まれても良い。このソースコードはセンターで生成されラーメン店（Ａ店）に対して提供される。
事業種類コードは、図３４に示すような、各事業内容毎に予め用意されユーザ対応・管理データベース４７に保存された設定項目や仕様に関連付けられたコードである。但し、ショップが同一の事業種類しか行っていないような場合には事業種類コードは不要である。また、デリバリーボタン用のソースコードは、商品詳細ページ１８０に掲載のすべての商品に対してｗｅｂページに埋め込まれても良い。

商品詳細ページ１８０においてデリバリーボタン１８３がクリックされると、センターサーバー６のユーザ対応・管理プログラム２５は商品詳細ページ１９０を生成し、ユーザの使用する情報端末に提供する。この商品詳細ページ１９０は、ステップ１５１で説明したような方法でデータ取得され、データベース３０に保存されている商品データをユーザ対応・管理プログラム２５が読み生成する。そして、この商品詳細ページ１９０に掲載の各商品には注文ボタン１９１が配設されている。この商品詳細ページ１９０は１商品の掲載でもよいが、図３３に示すように商品詳細ページ１８０の記載内容に合わせて複数商品を掲載することも可能である。

ユーザによりこの注文ボタン１９１がクリックされると、ステップ２０１以降とほぼ同様の処理が行われる。注文ボタン１９１以外に、資料請求ボタン、クーポン適用ボタン、テイクアウト用ボタン、予約用ボタン、現金還元用ボタン、価格交渉用ボタン、外国人購入用ボタン、ライブコマース開始ボタン、動画による広告等を並べて配設してもよい。また、商品詳細ページ１９０には相互販売や提携販売による提供元ショップ２の商品データが掲載されてもよい。この場合には、この商品詳細ページ１９０の適所には、「この商品データは提供元ショップ２の商品で提供元ショップ２より配送します」等のコメント文を記載できる。この商品詳細ページ１９０はセンターサーバー６において作成されるので、コメント文の記載箇所はセンター側で任意にできる。商品詳細ページ１９０はセンターサーバー６において他言語にて作成されてもよい。
また、ステップ１８１のように商品データの収集をし、この商品データの追加、削除、更新のされたことを判断することで、商品詳細ページ１９０に掲載の商品についても自動的に商品データの追加、削除、更新が可能である。従ってショップ側での手間は不要である。

次に、このラーメン店（Ａ店）の注文や売上等の管理方法について説明する。
このラーメン店（Ａ店）の管理画面２０５には、ラーメン店の事業種類コードであるコード１に対応する商品と設定項目がユーザ対応・管理データベース４７（図３４参照）から読まれて表示される。なお、このラーメン店（Ａ店）の管理画面２０５の具体的な画面例については省略する。
ラーメン店（Ａ店）側では事前にこの管理画面２０５に表示された設定項目毎に仕様を選択若しくは入力する。例えば、醤油ラーメンについては、この店での製作時間は５分なので選択ボックスで５分、１０分、１５分、２０分と表示された中から５分を選択する。入力されたデータは、図３５に示すように、ユーザ対応・管理データベース４７に保存される。管理画面２０５ではこの醤油ラーメンについて他に、同時に作成が可能な件数を入力する。この店で、醤油ラーメンについて同時に作成が可能な件数は５個なのでユーザ対応・管理データベース４７では５個が入力されている。また、この店で最大で受けられる注文件数は何件まで可能かがユーザ対応・管理データベース４７に設定されている。この店では１０件と設定されている。但し、同時に何種類の商品が処理できるのかが設定されるようにしてもよい。

なお、通常ラーメン店では実店舗を持っていることが多い。このため、ネットの注文だけではなく、実店舗からの注文にも対応することが望ましい。実店舗からの注文は、センターサーバー６とインターネット１０を介して接続されたタッチパネル型パソコン３又はスマートフォン５等の情報端末で行う。この注文処理は情報端末に対し所定のアプリをダウンロードすることで行われるのが望ましい。図３６に情報端末に表示された画面例を示す。注文画面２１０において、商品画像２１１には商品名や写真が描かれている。インクリメントボタン２１３をクリックすると、件数表示欄２１５の件数が１件ずつ増加するようになっている。一方、デクリメントボタン２１７をクリックすると、件数表示欄２１５の件数が１件ずつ減少するようになっている。この実店舗の客席用のテーブルには番号が付されている。そして、テーブル番号入力欄２１９に、注文をした顧客が座っているテーブル番号を入力することで、誰の注文であるかが分かるようになっている。テーブル番号の入力方法は、数字入力や画像のクリック等任意である。その後、送信ボタン２２１をクリックすると、注文のあった商品の商品ｉｄ、注文件数、テーブル番号、注文日時がセンターサーバー６に送信され、ユーザ対応・管理データベース４７に保存されるようになっている。

次に、センターサーバー６のユーザ対応・管理プログラム２５は、ユーザ対応・管理データベース４７に保存されているデータを読み、以下の処理を行う。
ユーザ対応・管理プログラム２５は、ユーザ対応・管理データベース４７より読み込んだデータを基に図３７の工程図画面２４０を作成し、情報端末に表示する。図３７の工程図画面２４０では、例えば異なる時刻にネットと実店舗とで注文を受けた３つの商品が、時系列に完成に向けて進行する様子が描かれている。工程図画面２４０には現在処理中の案件が受注した日時順に左方より表示されている。

商品ａの工程には例えばネットで注文されたユーザαの商品である旨が表示される。また、商品ｂ、商品ｃの工程にはそれぞれテーブル番号３番、６番のユーザの注文である旨が表示される。商品ａ、ｂ、ｃの工程図は時間の経過と共に左側にシフトする。図３７の例では、現在時刻に商品ａ、ｂ、ｃが仕掛かっている。商品ａ、ｂ、ｃのそれぞれの工程の長さは、各商品毎に予めＡ店により設定された製作時間に対応した長さになっている。但し、製作時間を無視して同じ長さで受注日時順に表示されてもよい。長さは短くても良い。

簡単のためにＡ店での最大注文件数は３件であるとして説明する。この場合、４件目の注文からは待機案件欄２５０に入る。停止／再生ボタン２４１をクリックすると工程図をその位置で固定できる。例えば、製作作業を一時停止するような場合に使用する。もう一度クリックするとその時点から動作する。記録・再生ボタン２４３をクリックすると工程の流れの記録ができる。これにより、後から工程のチェックや設定の見直しができる。また、スクロールバー２４５のノブ２４５ａを左右に移動させると商品ａ、ｂ、ｃの工程が連動して左右に移動する。例えば、製作が遅れそうな場合にはノブ２４５ａを右に移動させて調整する。製作が早く終わりそうなときにはノブ２４５ａを左に移動させて調整する。スクロールバー２４５の矢印ボタン２４５ｂ、２４５ｃは、クリックするとその方向にノブ２４５ａが予め定めた単位時間分移動する。

そして、製作が完了したら、完了した商品を左方向にドラッグ＆ドロップすると完了マークが一瞬出てその後データが画面より消える。この点、工程図画面２４０の左側に完了箱を表示し、そこにドラッグ＆ドロップするようにしてもよい。完了した商品はユーザ対応・管理データベース４７に完成した商品として保存される。このとき、同時に待機案件欄２５０では、ユーザ対応・管理プログラム２５が次に待機している商品ｄが抽出される。このため、図３８に示すように、この待機案件欄２５０からは商品ｄが消える。そして、この商品ｄは工程図画面２４０に商品ａの工程が消えたその商品ａの後ろに続くように表示される。従って、Ａ店では商品作成の工程の管理ができる他、次に作るべき商品や待機している商品が分かる。

商品の製作工程については、強制的な割り込みをかけることができる。例えば図３８に示すように、商品ｆは本来商品ｅよりも後の注文である。しかしながら、事情により商品ｆを早く製作したいときには、商品ｆを待機案件欄２５０より現在処理中を示す工程図画面２４０に向けて左側にドラッグ＆ドロップする。これにより、図３９に示すように、自動的に商品ｄに代えて商品ｆが入る。そして、商品ｄは逆に待機案件欄２５０に戻る。このため、待機案件欄２５０では商品ｄが依然次の待機となる。

次に、商品をまとめて作成する場合について説明する。同じ商品や類似した商品を複数人分まとめて一度に作れるときにはまとめての処理をする。例えば、同じ醤油ラーメンを５人分一度にまとめて作成する。あるいは、トッピングの異なる類似のラーメン同士を一度に作成する等の場合である。図４０において、例えば、商品ｄ１、ｄ２、ｄ３がすべて同じ種類の醤油ラーメンであり一度に作成ができる場合には、ユーザ対応・管理プログラム２５は待機案件欄２５０にある商品ｄ１、ｄ２、ｄ３を待機案件欄２５０から消す。そして、工程図画面２４０に商品ｄ１・ｄ２・ｄ３のまとめた工程として移す。このとき、Ａ店では商品ｄ１、ｄ２、ｄ３の３個分を一気にまとめて作成する。Ａ店の場合、一度に作成ができる件数は、ユーザ対応・管理データベース４７では５個と設定されているので３個までならばまとめて作成が可能である。このとき１個同じ商品を追加で作成するとどの程度時間が増加するかを設定してもよい。例えば、１個追加だと１分時間が増加し、２個追加だと２分時間が増加する・・等である。なお、実店舗では、商品の完成を決済と連動させるようにしてもよい。ユーザ対応・管理プログラム２５は商品の注文状況が分かるので、ネットと実店舗の売上の合計金額が直ぐに出せる。

次に、配達やテイクアウトの処理について説明する。
配達については、図４１に示すように、各商品の完了予定時刻が工程図から分かるので、ユーザ対応・管理プログラム２５が空いている配達員に完了予定時刻を通知する。なお、テイクアウトの場合には、ユーザに対して商品の完了予定時刻を通知する。配達の場合、配達員はその完了予定時間までに商品の受取りに店に行けば良い。ユーザ対応・管理データベース４７には地図データを予め保存し、ユーザ対応・管理プログラム２５がＡ店の地図上の位置と配達先であるユーザの住所とから地図上の距離を読み取り、この距離から配達時間を推定して注文をしたユーザに対し到着予定時刻を知らせることも可能である。商品の完了予定時刻と配達予定時刻とを通知してもよい。上述した商品の完了予定時刻と配達予定時刻の演算は、図３１のステップ２１９に示す演算方法の一態様に相当する。
これにより、ショップは簡単にデリバリー等の仕組みを導入できる。また、ネットでの注文のみならず実店舗での注文についても工程管理ができる。

次に、ショップのｗｅｂページを外国人に向けて公開するときの処理について説明する。
図４２に、ユーザである外国人向けに、ｗｅｂページで掲載のテキストの原文と翻訳文の対訳で、商品詳細ページの内容を示した例を示す。図４２において、商品詳細ページ２６０には、画像１と画像２の間に日本語の原文１と原文２、画像２と画像３の間に原文３、画像３の下に原文４が記載されている。商品詳細ページ２６０はショップが自身のサーバーで公開しているページである。サーバーには提供先ショップ１のサーバー７、提供元ショップ２のサーバー４が含まれる。原文１と原文２とは文章としては連続しており、原文１と原文２の間に線等によるデザイン的な仕切りは設けられてない。商品説明文２６１中には、センターサーバー６が生成する原文と翻訳文との対訳の掲載された商品詳細ページ２７０に進むためのリンクボタン２６３と、外国人向けのｗｅｂページが用意されていることを案内するコメント文２６５が埋め込まれている。このリンクボタン２６３とコメント文２６５は、ステップ１５３やステップ１８５で説明をした通りの方法で、商品データ解析プログラム２３により商品説明文２６１中に埋め込まれたものである。そして、商品詳細ページ２６０は、センターサーバー６よりこの商品データの提供を受けたショップサーバーのｗｅｂページ作成部が作成したものである。なお、コメント文２６５やリンクボタン２６３は、アイコンとしてコメントを記載してもよい。

商品詳細ページ２７０に掲載の画像１、２、３及び原文１、２、３、４は、商品詳細ページ２６０に掲載のものを転載したものである。原文は、基本的には商品詳細ページ２６０のｈｔｍｌのソースコード中に記載されている改行記号の存在箇所で区切る。また、画像の箇所でテキストを分ける。但し、改行記号までの行数が予め設定をした行数を超えているような長文の場合には、予め設定をした数行程度の次に初めて出現する「。」の存在箇所で区切ることが望ましい。
原文１の下段にはセンターサーバー６で機械翻訳された翻訳文１が配設される。
この機械翻訳はリアルタイムに行っても良いし、センターサーバー６に訳文として保存されているものを抽出して掲載しても良い。リアルタイムの場合には、ボタンで要求のあった商品についてだけ翻訳が行われるので、センターサーバー６の翻訳に対する負荷が軽くて済む。
但し、翻訳文１は人が一部若しくは全体を翻訳するようにしてもよい。商品詳細ページ２７０に掲載の画像と原文の出現順序は、商品詳細ページ２６０のｈｔｍｌのソースコード中の画像と原文の出現順序と同じになるように掲載することが望ましい。但し、画像だけ、あるいは原文だけをまとめて掲載してもよい。また、図４２の例では対訳は同一ページ内の縦方向に原文と翻訳文が並ぶようにしているが、原文と翻訳文とを縦の間仕切り線を隔てて左側と右側に並べるようにしても良い。この場合、原文１と翻訳文１の先頭行の位置、原文２と翻訳文２の先頭行の位置・・・等は、対比し易くするため同じ高さにすることが望ましい。そして、「カートに入れる」ボタン２７１がクリックされると、センターサーバー６で用意した購入処理に進む。

また、商品説明文２６１中若しくは商品詳細ページ２７０には、ユーザの使用したい言語が選択可能なように選択ボックス２６７が配置されてもよい。そして、ここで選択された言語について翻訳文が生成される。言語は一度選択されればその言語に維持されるのが望ましい。なお、選択ボックス２６７で言語が選択されたときには直ちにその言語で作成された商品詳細ページが表示されてもよい。
なお、上記では、商品詳細ページ２７０をセンターサーバー６が生成してユーザの情報端末に表示するとして説明したが、原文と翻訳文の対訳についての商品データは、センターサーバー６で生成しショップ側に提供し、この商品データをショップサーバーが商品詳細ページ２６０のデザインテンプレートに流し込んでｗｅｂページを作成しユーザの情報端末に表示するようにしてもよい。この場合、ステップ１５３やステップ１８５で説明したのと同様に商品データ解析プログラム２３がショップの商品データに対して、翻訳文と購入ボタン、コメントを埋め込む。翻訳文は図４２のように原文のブロックに対応させて原文のブロックと翻訳文のブロックを並べて表示してもよいが、ブロックに分離せずに商品説明文２６１中の最下部にまとめて配設してもよい。ここで埋め込まれた購入ボタンがクリックされた場合にはセンターサーバー６での購入処理が動作するが、購入ボタンはセンターサーバー６では埋め込まずに、ショップの購入ボタン１０１で購入されるようにしてもよい。
ブロック毎に原文と翻訳文とが対訳とされることでユーザは見易く、情報に対する判断を的確に行うことができる。
なお、原文と翻訳文のユーザへの見せ方については、センターサーバー６で生成した商品詳細ページには翻訳文のみをまず掲載する。そして、この商品詳細ページ中の適所に対訳ボタンを配置して、これがクリックされたら商品詳細ページ２７０に示すような原文と翻訳文の対比文が表示されるようにしてもよい。この際、例えば原文の方には背景色を付け、一方、翻訳文の方はそのまま白色で掲載すると見易い。
以上の処理を行うに際しては、ショップ側でのシステムの改造は不要である。また、外国人向けの処理として、海外からのアクセスに限らず、国内にいる外国人に対しても利用が可能である。
なお、図３０の例やデリバリーボタン１７３の例で説明したように、コメント文２６５やリンクボタン２６３はホームページの適所に配設されても良い。更に、コメント文２６５やリンクボタン２６３は、相互販売、提携販売、モール化が行なわれている提供先ショップ１と提供元ショップ２の各商品詳細ページに対して配設されても良い。このコメント文２６５については、外国人がこの商品を購入可能である旨のメッセージの他、この商品が提供元ショップ２から発送される旨のメッセージ、この商品が輸出禁制品である旨のメッセージ、ライブコマースを開催する旨のメッセージ等を掲載可能である。また、複数のメッセージを含めて記載されてもよい。
このメッセージは、センターサーバー６の管理画面において、ショップがテキストボックスに文字入力することで内容を編集可能である。あるいは、予め用意されたテキストを選択するようにしてもよい。このメッセージがセンターサーバー６により詳細文中に埋め込まれる場合には、ショップ側での改造は不要である。一方、このメッセージがホームページの適所に配設された場合には、必要なスクリプトがソースコードとして提供され、ショップ側が商品詳細ページ中に埋め込む。このメッセージは、商品毎に編集可能としてもよいし、すべての商品について共通したものとしての編集もできることが望ましい。

次に、ショップの商品データを外国人が検索可能とする処理について説明する。
図４３において、ショップの既存のｗｅｂページ２８０には検索入力欄２８１と検索ボタン２８３が掲載されている。これに隣接してリンクボタン２８５を配設する。また、言語選択ボックス２６７を配設するのが望ましい。リンクボタン２８５がユーザによりクリックされると、センターサーバー６で作成され、センターサーバー６より提供される検索ページ２９０に遷移する。ユーザが検索入力欄２９１に所定の言語で入力し検索ボタン２９３をクリックするとセンターサーバー６のデータベース３０が検索され、検索ページ２９０に検索結果リストが表示される。所定の言語は、言語選択ボックス２６７で選択された言語であることが望ましい。
なお、ステップ１５１やステップ１８１で収集されたすべての商品の商品名や説明文は、対象となる少なくとも一つの言語に翻訳してセンターサーバー６のデータベース３０に保存しておく。但し、商品名のみが翻訳されてもよい。
しかし、検索入力欄２８１、２９１に入力されたキーワードがセンターサーバー６で翻訳語に翻訳されてその翻訳語について検索がされるようにしてもよい。検索入力欄２８１、２９１に日本語でキーワードが入力され、センターサーバー６で外国語に翻訳されてから検索が行われてもよいし、外国語でキーワードが入力され、センターサーバー６で日本語に翻訳されてから検索が行われてもよい。
この場合、全ての商品データについての翻訳をしないで済むのでセンターサーバー６の翻訳に対する負荷が軽くて済む。また、日本語の単語と外国語の単語とが１対１の関係で無く、複数の候補が出現した場合には、ユーザに対しこの候補を示し、選択をさせることが望ましい。そして、このユーザにより選択されたキーワードについて、センターサーバー６のデータベース３０に対し検索が行われる。検索は商品名のみについて行なわれるようにしてもよい。
検索結果リストはｗｅｂページ２８０若しくは検索ページ２９０に配設された言語の選択が可能な選択ボックス２６７で選択された言語で表示されてもよいし、日本語で表示されてもよい。言語は一度選択されればその言語に維持されるのが望ましい。但し、言語の選択が無くても、検索入力欄に入力されたキーワードで言語の種類を判断し、その言語について検索されてもよい。検索結果に表示された商品名２９５をクリックすると商品詳細ページ２７０が表示される。検索入力欄２８１、検索ボタン２８３、リンクボタン２８５、言語の選択ボックス２６７は、ｗｅｂページ２８０に埋め込まれたスクリプトにより生成されたポップアップ画面に配設されてもよい。

次に、ショップの既存のｗｅｂページから直接外国人が検索可能とする処理について説明する。
図４４に示すショップの既存の商品詳細ページ３００の商品説明文３０１中には、直接外国人が自国語で検索が可能な検索入力欄３０３と検索を行うための検索ボタン３０５、コメント文３０７が埋め込まれている。言語の選択ボックス２６７が埋め込まれても良い。このコメント文３０７はテキスト又は画像で構成され、検索入力欄３０３に所定の言語でのキーワードを入力し、検索ボタン３０５で検索ができることが表示されている。検索入力欄３０３に所定の言語でキーワードが入力され、ユーザにより検索ボタン３０５がクリックされると、センターサーバー６のデータベース３０に保存されている商品データがこのキーワードで検索される。そして、検索された結果が検索結果リストのｗｅｂページとしてセンターサーバー６で生成される。

また、商品説明文３０１中にはパンくずリスト３０９を掲載することもできる。そして、このパンくずリスト３０７をユーザがクリックすると、一覧ページ等にリンクできるようになっている。この一覧ページはショップサーバーで作成されたｗｅｂページであってもよいが、センターサーバー６で作成されたｗｅｂページとすることもできる。
この検索入力欄３０３、検索ボタン３０５、コメント文３０７、選択ボックス２６７、パンくずリスト３０９は、ステップ１５３やステップ１８５で説明をした通りの方法で、商品データ解析プログラム２３により商品説明文３０１中に埋め込まれたものである。そして、商品詳細ページ３００は、センターサーバー６よりこの商品データの提供を受けたショップサーバーのｗｅｂページ作成部が作成したものである。
検索入力欄３０３、検索ボタン３０５、コメント文３０７、選択ボックス２６７、パンくずリスト３０９は商品説明文３０１中の下部に埋め込まれても良い。但し、この場合、コメント文３０７だけはメッセージを目立つ箇所に配置するために上部に残しても良い。
なお、商品説明文２６１や商品説明文３０１中にはポップアップ画面を生成するスクリプトを埋め込み、リンクボタン２６３、コメント文２６５、言語の選択ボックス２６７、検索入力欄３０３、検索ボタン３０５、コメント文３０７、パンくずリスト３０９等を含むポップアップ画面が生成されてもよい。
ショップが相互販売、提携販売、モール化を行っている提供先ショップ１の場合、センターサーバー６では、すべての提供元ショップ２の商品データを翻訳してもよいが、希望する提供元ショップ２の商品データのみを翻訳してもよい。また、希望する提供元ショップ２の商品データの商品詳細ページにのみ、翻訳用のコメント文２６５、リンクボタン２６３、リンクボタン２８５や、検索入力欄３０３、検索ボタン３０５、コメント文３０７、パンくずリスト３０９等を埋め込むようにしてもよい。以上の処理を行う場合でもショップ側でのシステムの改造は不要である。

次に、外国人が検索を行う際に的確な訳語での検索を可能とする方法について説明する。
図４５に示すように、詳細文中の原文である日本語の文章は、例えば、句点「。」毎に範囲を区切る。そして、各範囲毎に連番符号３１１を付す。その範囲の文章に対応する外国語の訳文についても同じ符号３１３を付す。商品名についても同様である。詳細文と商品名はデータベース３０より抽出されてもよいが、リアルタイムにショップの商品詳細ページより抽出されてもよい。
符号３１３にはセンターサーバー６へのリンクが貼られており、符号３１３がクリックされたときにはセンターサーバー６側でどの箇所の文章が選択されたのかが分かるようになっている。そして、訳文の符号３１３がクリックされたとき、その符号３１３に該当する箇所の原文である日本語の文章が、図４６に示すように分節や用語毎に分離され、ホームページ上に選択自在に表示される。この際、原文である日本語と訳語との対応する分節や用語同士については、同じ背景色が施されて表示されることが望ましい。但し、同じ背景色に限るものではなく、同じ数字や符号等が施されて表示されてもよい。そして、各日本語の分節や用語の頭には、チェックボックス３１５が設けられている。商品名についても同様である。

チェックボックス３１５が指定されると、この指定された日本語の分節や用語が自動で検索入力欄に入る。但し、指定された日本語の分節や用語がクリップボードに入るとされてもよい。この際の指定は、訳語と同じ背景色の付された日本語の用語を指定すればよいので簡単である。但し、訳語側を選択することで、対応する日本語の分節や用語が自動で検索入力欄に入るようにしてもよい。また、訳語側が選択されたときに、対応する日本語の分節や用語が目立つ色や枠で囲まれて表示されるようにしてもよい。この日本語の分節や用語で良ければこれを選択する。あるいは、日本語側と訳語側の両方を選択可能としてもよい。日本語の分節や用語が複数選択されたときには検索入力欄にオアで入る。
検索ボタンが押されると日本語のデータベースについて検索が行われる。検索結果は検索結果リストとして表示がされるが、このとき外国語での翻訳文をデータベースから抽出して表示してもよいし、リアルタイムに外国語に翻訳をして表示してもよい。
仮に、翻訳について対応関係が明確でない用語や対応関係の欠落した用語、同じ用語としての背景色が施されていない状況が含まれている場合や、色の付されていない歯抜け状態の用語があったとしても、隣接する対応色同士で囲まれた狭い範囲内に存在する用語を指定することで、外国人であっても文脈の中での妥当な日本語の用語を選択可能である。
このことにより、外国人は文章の中から妥当な用語を選択して検索ができるので簡単である。この用語は、文章として把握された形の中で翻訳されている用語なので、用語の翻訳精度は高い。従って、精度の高い日本語での検索が行える。また、日本語のデータベースに対する検索で済み、検索負荷は少ない。

なお、先述したように、センターサーバー６で生成した商品詳細ページには翻訳文のみをまず掲載する。そして、この翻訳文には各範囲毎に連番符号３１３を付しておく。符号３１３がクリックされたときには同様に符号３１１の付された日本語文章の対訳が出る。この日本語文章の分節や用語の頭には、チェックボックス３１５が設けられているとされてもよい。
また、上記した外国人による検索方法は、パソコンやスマートフォン向けのアプリケーションプログラムとして提供されてもよいし、ブラウザに対するプラグインアプリケーションとして提供されてもよい。

次に、販売店リストを介して外国人が商品を購入可能とする処理について説明する。
図４７に示すように、商品詳細ページの適所に配設された、前述の海外発送対応可能である旨や外国人が購入可能である旨のリンクやボタンがクリックされたり、言語選択ボックス２６７で言語が選択されたとき、あるいは、ＩＰアドレスを解析することで、外国人による購入や海外からのアクセスであると判断されたとき、販売店リスト３１７には外国人購入ボタン３１９若しくはリンクやアンカーテキストが、現地ショップ若しくはこのショップの商品を掲載する商品詳細ページに進むリンクとは別に表示される。但し、この判断によらず、販売店リスト３１７には最初から外国人購入ボタン３１９が配設されてもよい。そして、外国人購入ボタン３１９若しくはリンクやアンカーテキストがクリックされたときには、この選択されたショップに対する外国人購入用の商品詳細ページが開かれる。但し、商品詳細ページを開くとはせずに、直接購入処理を動作させてもよい。また、この外国人購入用の商品詳細ページや購入処理はセンターサーバー６で作成し開示するが、外国人購入ボタン３１９若しくはリンクやアンカーテキストを表示するページについても、センターサーバー６で作成し開示してもよい。

ショップが相互販売、提携販売、モール化を行っている場合には、提供先ショップ１と提供元ショップ２の各商品詳細ページに表示される販売店リスト１０３、１１５に対して、外国人購入ボタン３１９若しくはリンクやアンカーテキストが表示される。
但し、販売店リスト１０３、１１５から個別商品の詳細ページに進み、そのページに配設されている外国人購入ボタン若しくはリンク２６３やアンカーテキストが利用されるようにしてもよい。販売店リスト１０３、１１５は、商品データ解析プログラム２３がまとめたものである。
しかし、この処理は、いわゆる価格比較サイトに掲載の図示しない販売店リストに対して適用することも可能である。そして、前述したように、販売店リストを掲載している商品詳細ページの適所に外国人が購入可能である旨のリンクやボタン、あるいは、言語選択ボックス２６７を配設し外国人購入用の処理を行なう。このことにより、外国人が容易に商品を販売するショップを見つけたり、最安の商品を見つけての購入ができる。
この販売店リストについても、パソコンやスマートフォン向けのアプリケーションプログラムに提供されてもよいし、ブラウザに対するプラグインアプリケーションで提供されてもよい。

次に、上記した相互販売、提携販売、モール化や多様化を含むサービスをショップに対して効率良く導入する方法について説明する。
まず、ショップにとっての導入の効果を予測するために、ショップの商品販売や商品購入需要面についての現時点での状況評価を行う。そして、この評価を行うに際しては、事前にそれぞれの商品毎に購入データを解析し、基本属性を算出する。即ち、ＰＯＳデータやクレジットカード、ポイントデータ、キャッシュレス決済等の決済データに基づき商品毎に基本属性を解析しておく。この基本属性は、商品毎に、どのような属性の人が購入したのかを解析したデータである。この基本属性は、一つの同じ商品についての購入データを多くのショップから集めて、この商品を購入した人の属性に紐付けて解析したデータである。属性は、例えば、年齢層、性別、趣味嗜好、業種、用途、国内需要若しくは海外需要、購入者数、売上高、訪問者数、海外訪問者数等である（以下、同旨）。この属性には、後述するアクセス解析ツールを用いて得られたデータを加えても良い。

基本属性を解析するには、図４８に示すように、同じ商品１について、多数のショップにおける購入データを集めて解析を行う。図４８の例は、この商品１を購入した購入者の性別と年齢層についてまとめたデータ例である。この商品１は、全国のショップで１０，０００人の人によって購入されたと仮定する。ＰＯＳデータ等の解析結果から、購入者の性別は９０％が女性で、また、年齢層で見ると２０代の人が１，０００人購入をしているので、２０代の人の購入率は１０％であることが分かる。属性に基づく解析は、他に趣味嗜好、業種、用途、国内需要若しくは海外需要、海外訪問者数等について行っても良い。趣味嗜好としては、例えば、山好きの人、海好きの人、ゲームの好きな人、読書の好きな人、体を動かすことの好きな人、音楽好きな人等である。業種は事務、技術、営業等である。用途は若い女性向け、年配者向け等である。

図４８において、年齢層に基づく購入者数の解析結果は、理解し易さのために正規化をしている。商品１の年齢層毎の正規化データは例えば図４８に示すように、１０代が１０％、２０代が１０％、３０代が２０％、４０代が２０％、５０代が３０％、６０代が１０％である。そして、図４８には、この正規化されたデータに基づき、商品１についての基本属性グラフ３２１が作成されている。このように算出された年齢層毎の正規化された基本属性データは、商品１以外の多くの商品についても同様に解析が行われる。そして、これらの解析結果のデータはセンターサーバー６に保存される。但し、センターサーバーは独立したものとしてもよい。

次に、この基本属性データを用いて、各通販ショップ毎に販売属性を求める方法について説明する。販売属性とは、この通販ショップがどういう属性（例えば年齢層や性別等）の人に向けた商品、あるいは、どういう属性の人に受ける商品を通販サイトに掲載しているのかを分析したものである。但し、販売属性は、通販ショップのジャンルについて分析されてもよい。
販売属性を求めるに際しては、まず、通販ショップ１について取り扱われている商品データをホームページから収集、若しくはＣＳＶファイルで収集する。この通販ショップ１は提供先ショップ１や提供元ショップ２、若しくはこれらの候補ショップに相当する。そして、この通販ショップ１に属する商品毎に上記の商品毎の正規化された基本属性データを読み、集計する。例えば、簡単のためにこの通販ショップ１では、商品１、商品２、商品３の３品を自店の通販サイトに掲載していると仮定する。そして、図４９に示すように、これら３品の商品の基本属性をセンターサーバー６より読み、属性が年齢層の場合には各年齢層毎に小計する。

図４９の例では、１０代については、商品１の基本属性１０％と商品２の基本属性５％と商品３の基本属性５％をセンターサーバー６より読み小計すると２０％となる。同様に、他の年齢層についても集計をする。そして集計後に正規化すると、通販ショップ１の年齢層毎の正規化データは、例えば図４９に示すように、１０代が７％、２０代が８％、３０代が１２％、４０代が３３％、５０代が２７％、６０代が１３％となる。そして、この正規化されたデータに基づき、図４９には通販ショップ１の年齢層についての販売属性グラフ３２３が作成される。販売属性グラフ３２３を見ると、この通販ショップ１では、４０代－５０代のユーザをターゲットにした商品が多く掲載された通販サイトであることが分かる。
なお、販売属性として、この通販ショップ１における売れ筋商品の取り扱い率、利益率の高い商品の取り扱い率を算出し、販売属性グラフ３２３と共にグラフ表示してもよい。ここに、売れ筋商品の取り扱い率とは、この通販ショップ１が取り扱っている商品の内の売れ筋商品として一般的に認識されている商品件数のこの通販ショップ１の全商品件数に対する割合である。利益率の高い商品の取り扱い率とは、この通販ショップ１が取り扱っている商品の内の利益率が高いと想定される商品件数のこの通販ショップ１の全商品件数に対する割合である。

次に、各ショップ毎の購入属性を求める方法について説明する。
購入属性とは、このショップやジャンルでは、実際にどういう属性（例えば、年齢層、性別等）の人が購入する可能性が高いのか、その購入需要を属性について分析した特性である。購入属性は、例えば通販ショップ１が導入しているＰＯＳデータやクレジットカード、ポイントデータ、キャッシュレス決済等の決済データに基づき図５０のように解析を行う。即ち、通販ショップ１での購入データを分析し、求めたい属性が年齢層の場合には、１０代の購入者数が１００人、２０代の購入者数が４００人・・等と年齢層毎の購入者数の分析を行う。そして、その結果は購入属性グラフ３２５に作成される。見易さのために正規化をしているが、正規化しなくてもよい。

この購入者数を基に年齢層毎の訪問者数を推定する。訪問者数を推定するに際しては経験値若しくは実測値からデータ変換を行う。例えば、一般的に訪問者数のα％が実際に購入したとすると、購入者数÷α％で通販ショップ１のサイトの訪問者数を推定することができる。ジャンル毎の購入者数を求めれば、同様にジャンル毎の訪問者数を推定することができる。α％は一定のものではなく、環境因子や取引状況等如何で実情に即して補正されることが望ましい。
また、上記は、ＰＯＳデータやクレジットカード、ポイントデータ、キャッシュレス決済等の決済データを基に訪問者数を推定するとして説明したが、ブラウザのプラグインや管理ツールとして解析されたデータを用いて訪問者数を得るようにしてもよい。これには、例えば、グーグルアナリティクス等のｗｅｂサイトのアクセス解析ツールを用いた解析があげられる。趣味嗜好等の属性についても同様に取得してもよい。このようにアクセス解析ツールを用いて得られた属性データは、ＰＯＳデータ等から得られた属性データと共に用いられても良い。一方の属性データの取得が難しかったり、不確実性の高い場合には、他方の属性データを用いるというようにしてもよい。購入属性は、通販ショップ１で商品購入のされた人数をまとめた購入者属性と、通販ショップ１を訪問した訪問者の数をまとめた訪問者属性とに分けるようにしてもよい。

また、通販ショップ１では実際の購入者の数が少なかったり、ＰＯＳ等の導入をしたばかりのようなときには十分な購入データがない。このような場合には、購入属性についても販売属性を算出したのと同様の方法で算出し推定値とする。即ち、通販ショップ１で実際に購入のあった商品データに対して、商品毎の正規化された基本属性データを読み、集計する。これにより、一般的な購入属性の傾向として利用できる。
また、ジャンル毎の訪問者数を次のように推定してもよい。ジャンル毎の購入者をＰＯＳデータ等より年齢層毎に分析する。この分析データを基にジャンル毎の各年齢層毎の購入者数を求める。このデータを基に上記と同様に購入者数÷α％でジャンル毎の年齢層毎の訪問者数を推定する。但し、この場合のα％は、ジャンル毎の経験値若しくは実測値に基づく数値を採用することが望ましい。

次に、購入属性と販売属性を基にショップの売上増加に繋げる方法について説明する。
購入属性は購入者数を基に作成したグラフであるが、ＰＯＳデータ等から算出した購入者数を基に訪問者数を推定した場合には、購入者数と訪問者数とは補正をしない段階では比例関係にあるので、購入属性のグラフは訪問者数のグラフと同じ特性となる。この場合には、購入属性のグラフを訪問者数のグラフと言い換えることができる。図５１には、訪問者数を現す購入属性に対しＫ人のしきい値を設定した例を示す。Ｋの値は例えば月間５万人であり、実情に即して適宜変更可能な値である。図５１では簡単化のために２０代の年齢層についての購入属性のみを示し、他の年齢層の購入属性は省略している。図５１では、２０代の訪問者数がＫ人のしきい値を超えている例を示している。この場合、２０代のユーザの購入需要が高いと推測できる。購入属性を購入者属性と訪問者属性とに分けた場合には、Ｋ人のしきい値はそれぞれに設定される。

一方、図５１には同じ２０代の年齢層についての対比として販売属性も示している。この販売属性のしきい値としてＳ％を設定する。Ｓの数値の設定方法は、例えば、図４９に示す属性毎の正規化欄の数値の平均値をとり、その平均値のβ倍とする。βの値は例えば１．５である。また、このＳの数値の別設定方法として、図５１に示すように、各年齢層の中で２０代が最大のピーク値を有していると仮定したときに、このピーク値の例えばＳ％を販売属性のしきい値として設定する。Ｓの値は例えば６０である。この販売属性のしきい値や、その設定方法についても適宜実情に則して変更が可能である。そして、図５１の例では、２０代の販売属性がしきい値であるＳ％を超えているので２０代での販売属性が強いと判断できる。即ち、２０代向けの商品を多く取り揃えたショップであると判断できる。

図５１の例のように、２０代の訪問者数がＫ人のしきい値を超え、かつ、２０代の販売属性がしきい値であるＳ％を超えている場合には、この２０代について販売属性と購入属性との特性の傾向が共にしきい値超えで一致している。このため、このまま通販ショップ１の販売を継続しても２０代の売上について収益が見込めるため問題はない。しかしながら、このように２０代の訪問者数が多いことから、この特性を生かして、例えば２０代のユーザの少ない他店の商品を、相互販売、モール化、提携販売を通じて売ってあげることを考慮してもよい。
また、２０代に基本属性の強い商品を、通販ショップ１の通販サイトに追加掲載することを提案することができる。この提案は、商品データのサイトへの追加の提案であってもよいが、実際にその商品の仕入れを提案してもよい。基本属性の属性を判断するに際しては、属性の種類により、同じ属性を有するか否かで判断したり、あるいは、同じ属性で所定のしきい値を超える等の強さを有するか否かで判断することが望ましい。また、同じ属性を有する、あるいは、しきい値を超えている商品の内の過去に売れている商品の類似商品や、一緒に使用される目的の商品等の仕入れを優先的に提案してもよい。

通販ショップ１の属性を解析し評価することで、そのショップ特有の属性にあった商品を仕入れることができる。この際には、売れ筋商品を提案したり、利益率の高い商品を仕入れることを提案してもよい。利益率、販売金額が想定できれば、通販ショップ１についての売上金額の増分や利益金額を算出したり表示することもできる。仕入れの商品候補として複数の商品を表示してもよい。
また、このように２０代の購入需要が高いサイト同士であったとしても提携を提案してもよい。このとき、互いの有する商品が相違する場合には、相互販売等により商品の充実が図れ、販売増にも繋がる。一方、互いの有する商品が重複する場合には販売店リストを作成してもよい。この場合、ニッチな商品群（例えばいわゆるロングテール商品等）、売れ筋商品を選択してバランスよく提案することが望ましい。通販ショップ１の有するジャンルとは異なる新規ジャンルの作成を提案してもよい。

なお、提携候補先は複数を提案してもよい。提携候補先のショップや、サイトに追加する商品データ、仕入れ候補の商品は自動での検出が可能である。属性に基づき検出する場合には、年齢層と性別の組み合わせ、年齢層、性別、趣味嗜好、人数、商品数、売上高等のように複数の属性について絞り込みや検索をしてもよい。この属性は、演算により得られたデータ、アクセス解析ツールから取得したデータ、後述するようなショップにより入力されたデータに基づいてもよい。
更に、通販ショップ１の販売属性が図４９、購入属性が図５０である場合には、図５０から分かるように、通販ショップ１の４０代から５０代の購入属性が弱いので、通販ショップ１に対しては４０代から５０代向けの商品の販売の得意な提供先ショップ１と提携をして商品を売ってもらうことを提案できる。この提供先ショップ１の候補は、４０代から５０代の購入属性がしきい値以上のサイトで見つけることが望ましい。提供先ショップ１の候補は自動での検出が可能である。

一方、図５０から分かるように、通販ショップ１の２０代から３０代向けの商品の購入需要が高いのだから、他のショップでこの年齢層の販売の不得意なショップの商品を提供先ショップ１として販売してあげることができる。このときの提携先となる提供元ショップ２の候補としては２０代から３０代向けの商品の購入属性が弱いサイトである。このサイトが２０代から３０代の販売属性が強いサイトであればより一層望ましい。２０代から３０代向けの商品が集まっている可能性があるためである。候補となる提供元ショップ２は自動での検出が可能である。属性の判断は、より細かく２０代から３０代の女性向け等として判断されてもよい。販売属性と購入属性の各グラフは、男性と女性とについて分けて年齢層毎に作成されてもよい。
しかし、提供元ショップ２の候補は必ずしも購入属性が弱いサイトに限定する必要はない。購入属性が強いサイトを提供元ショップ２としてもよい。

また、このように２０代から３０代向けの商品の購入需要が高い通販ショップ１に対しては、２０代から３０代向けの商品を実際に仕入れることを提案してもよい。２０代から３０代向けの商品であることは、商品の基本属性の属性（年齢層の２０－３０歳の部分）が所定のしきい値を超えていることで判断できる。この際には、利益率の高い商品や購入率の高い商品（売れ筋）を商品候補として複数提案し、選択した商品を仕入れるようにしてもよい。２０代の女性等、他の属性（女性等）も加味して判断されてもよい。
なお、図示はしないが、購入属性（あるいは訪問者数）のピーク値が全年齢層について常にＫ人のしきい値未満の場合には、全年齢層について購入属性の良好な提供先ショップ１で売ってもらうことが売上増加に繋がり望ましい。
一方、購入属性（あるいは訪問者数）の下限値が全年齢層について常にＫ人のしきい値以上の場合には、全年齢層について訪問者数がＫ人以上で購入属性が良好な状態なので、提供先ショップ１として提供元ショップ２の全商品を販売してあげることができる。
また、図５２には、モール化を図ったＥ店に対してＦ店、Ｇ店、Ｈ店を提携ショップとして加える例を示す。図５２に示すように、Ｅ店の販売属性での弱点部分が広範囲であったとしても、Ｆ店、Ｇ店、Ｈ店の提携ショップの販売属性の突出した特徴部分により弱点が補える。
更に、図５３には、ショップやジャンルの特徴を相互販売等の提携により一層強化させた例を示す。図５３において、Ｉ店の販売属性や購入属性はもともと突出した特徴を有しているが、Ｊ店との提携により、点線で示すようにこの特徴を倍増させることができる。

また、提供先ショップ１の候補や提供元ショップ２の候補は、自店が提携を希望する相手先ショップの特徴やテーマ等の属性を、図５４に示すように管理ツールにて指定することで絞り込みや検索が可能である。同様に、サイトに掲載や仕入れを希望する商品について、あるいは、ジャンルについても属性について絞り込みや検索が可能としてもよい。
図５４において、「通販サイトのテーマ」３２７は選択自在な選択ボックスとしてもよいし、テキスト入力が可能としてもよい。提供先ショップ１の候補や提供元ショップ２の候補は、ショップで選択されたテーマにより自動的に絞られた形で表示される。テーマは例えば、産直、地域、ブランド、特産、地酒、サイズに特化したファッション、現金値引等である。テーマはショップ側にて選択してもよいが、運営者側にて選択されてもよい。

更に、図５４の年齢層選択３２９に示すように、自店が提携を希望する相手先ショップの年齢層を選択できるようにしてもよい。そして、選択した年齢層は、希望する年齢層の順に優先順位を付けるようにしてもよい。この場合には、選択された年齢層により提供先ショップ１の候補や提供元ショップ２の候補が絞られる。但し、この年齢層は、購入属性と販売属性とに分けて選択可能とされてもよい。
同様に、性別選択３３１、趣味嗜好選択３３５、業種選択３３７、用途選択３３９、サービス選択３４１等での指定も可能である。また、訪問者数設定３３３では、希望する提携相手先のショップの訪問者の全体人数と年齢層毎の人数が指定可能なようになっている。ジャンル毎の人数を指定可能としてもよい。なお、図示はしないが、希望する提携相手先のショップの商品数や売上高を指定可能としてもよい。但し、選択されたデータは、このように候補を絞るために用いるのではなく、全体のショップデータからの絞り込みのために利用されてもよい。

また、上記では、図５４で提携相手先に求める属性等を指定するとして説明したが、かかる指定は、自店の特徴、テーマ等を示す属性データとして、他のショップによる検索が可能なように自店側についての情報の登録が可能とされてもよい。自動での属性データの算出がうまくできないようなケースについては、ここで手動登録をされたデータが検索に用いられても良い。
相互販売、提携販売、モール化で相手側のショップと提携をしようとする際には、この相手側に対する提携の条件として購入属性のＫ値を指定したり、販売属性のＳ％を指定することができる。例えば、相手側のショップに対し、同じ属性ａについて購入属性が月間２万人未満で、かつ、販売属性は５０％以上であることを希望する。あるいは、購入属性については条件を指定しないが、すべての属性（例えは年齢層）について、販売属性が６０％以上であることを希望する等である。候補ショップが複数件検索結果に表示されたときには、この候補ショップに対して更に別の属性ｂで絞るようにしてもよい。また、ジャンル毎に購入属性と販売属性を算出し、購入属性のＫ値を指定したり、販売属性のＳ％を指定してもよい。売れ筋商品の取り扱い率や利益率の高い商品の取り扱い率を指定してもよい。

このように、通販サイト毎に購入属性と販売属性をまとめ、対比等による評価をすることで、通販サイトの購入需要や販売面での弱点や強い点を図表化したり明確化することができる。商品の購入需要にマッチングした商品構成になっているかを簡単に判断できる。そして、提携を希望する相手側のショップの候補を簡単に希望通りに絞り込むことができる。
これにより、通販サイトの強い面を活用して一層の販売の強化を図ったり、商品の購入需要と商品構成とがミスマッチングしていて、購入需要が弱い面については購入需要の補強をすることができ、売上増に繋げられる。
相互販売、提携販売、モール化は改造無しで行えるので、他店の商品を自店で売ってあげる、あるいは、自店の商品を他店で売ってもらうという処理が簡単に行える。同様に、処理の停止や、やり直しも簡単に行える。この処理は、ショップ単位、ジャンル単位、商品単位に行える。これにより、ショップが希望する、ショップとしての特徴部分を自由にデザインし形成することも可能となる。また、提携による商品毎の販売を試験的に行い、解析してからその後にその商品を実際に仕入れる等することもできる。この解析は属性毎に精度よく行える。従って、ショップのリスクの低減に繋がる。

なお、前述した購入属性、販売属性により解析のされた趣味嗜好等の属性評価は、いわゆるアフィリエイト広告にも利用することができる。この場合に、アフィリエイト広告主は、購入属性、販売属性の解析結果と趣味嗜好等の一致するメディアに対し掲載をすることで効果的な広告を打つことができる。
また、海外からのアクセスである旨、ユーザの国名、アクセス数、趣味嗜好、年齢層等の属性を評価することで、外国人が商品を購入可能とする処理についても利用できる。これにより、上記した外国人購入用プログラムを導入したり、海外ユーザに受ける商品を判断できる。
更に、前述した購入属性、販売属性による解析や評価は、通販モールの参加店に対して行うこともできる。また、商品だけではなく役務サービスについても適用できる。通販ショップに限らず、実店舗についての適用もできる。
なお、本発明は、本発明の精神を逸脱しない限り種々の改変をなすことができ、そして、本発明が当該改変されたものにも及ぶことは当然である。

１提供先ショップ
２提供元ショップ
３パソコン（情報端末）
４提供元ショップサーバー
５スマートフォン（情報端末）
６センターサーバー
７提供先ショップサーバー
９提供先ショップのｗｅｂサイト
１０インターネット
１１、５１、７１演算部
１５、５５、７５通信部
２０商品データ収集・解析部
２１巡回プログラム
２３商品データ解析プログラム
２５ユーザ対応・管理プログラム
３０センターサーバーのデータベース
３１販売店リストデータベース
３３提供元ショップデータベース
３５提供先ショップデータベース
３７提供先－提供元対応データベース
３９提供元ショップ商品データベース
４１提供先ショップ商品データベース
４３販売履歴管理データベース
４５個別商品データベース
４７ユーザ対応・管理データベース
５７、７７管理部
５９提供元ショップサーバーの顧客データベース
６０提供元ショップサーバーのデータベース
６１提供元ショップ販売履歴管理データベース
６３提供先ショップ販売履歴管理データベース
６５提供元ショップ商品データベース
７９ｗｅｂページ作成部
８０提供先ショップのデータベース
８１提供先ショップの顧客データベース
８３提供元ショップ販売履歴管理データベース
８５提供先ショップ販売履歴管理データベース
８７提供先ショップ商品データベース
８９個別商品データベース
１００、１１０、１２０、１３０、１４０、１６０、１７０、１９０、２６０、２７０、３００商品詳細ページ
１０１購入ボタン
１０３、１１５、３１７販売店リスト
１１３、１３３提供元ショップのショップ名
１４１、１６１、１７１、２６１、３０１商品説明文
１４３資料請求ボタン
１６３、１７３デリバリーボタン
１６５、２６５、３０７コメント文
１９１注文ボタン
２０１、２０３、２０５管理画面
２０７問い合わせ画面
２１０注文画面
２１３インクリメントボタン
２１７デクリメントボタン
２１９テーブル番号入力欄
２４０工程図画面
２４５スクロールバー
２５０待機案件欄
２６３、２８５リンクボタン
２７１「カートに入れる」ボタン
２８０ショップの既存のｗｅｂページ
２８１、２９１、３０３検索入力欄
２８３、２９３、３０５検索ボタン
２９０検索ページ
３０９パンくずリスト
３１１原文に付す連番符号
３１３訳文に付す連番符号
３１５チェックボックス
３１９外国人購入ボタン
３２１基本属性グラフ
３２３販売属性グラフ
３２５購入属性グラフ

Claims

ショップの商品データが保存され、該商品データのｗｅｂページが生成されるショップサーバーと、
前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、
該商品データ収集手段により集められた商品データを保存するセンターサーバーと、
該センターサーバーで保存された前記商品データについて、所定の処理を開始するためのソースコードを生成するコード生成手段と、
該コード生成手段で生成されたソースコードを前記センターサーバーに保存されている商品データの所定の箇所に対して埋め込む埋め込み手段と、
該埋め込み手段で前記ソースコードを埋め込んだ商品データを、前記センターサーバーより前記ショップに対して提供する商品データ提供手段と、
該商品データ提供手段で提供された前記商品データを基に、前記ｗｅｂページを前記ショップサーバーが作成するｗｅｂページ作成手段と、
該ｗｅｂページ作成手段で作成された前記ｗｅｂページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする販売支援システム。
ショップの商品データが保存され、該商品データのｗｅｂページが生成されるショップサーバーと、
前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、
該商品データ収集手段により集められた商品データを保存するセンターサーバーと、
前記商品データについて所定の処理を開始するためのソースコードを前記ショップサーバーが前記商品データのｗｅｂページの所定の箇所のソースコードに対して差し替える、若しくは前記商品データのｗｅｂページの所定の箇所に埋め込む差替え等手段と、
該差替え等手段で前記ソースコードの差し替え等のされた前記ｗｅｂページを前記ショップサーバーが作成するｗｅｂページ作成手段と、
該ｗｅｂページ作成手段で作成された前記ｗｅｂページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする販売支援システム。
ショップの商品データが掲載されたｗｅｂページを保存し、該ｗｅｂページをインターネットを介してユーザの閲覧に供するショップサーバーと、
前記ショップの商品データが、提供及び収集の少なくともいずれか一の方法により集められる商品データ収集手段と、
該商品データ収集手段により集められた商品データを保存するセンターサーバーと、
前記ｗｅｂページに埋め込まれ、所定の処理を開始するためのリンクを生成するソースコードと、
前記リンクのリンク先であり、前記商品データの少なくとも一つを掲載したｗｅｂページを前記センターサーバーが作成するｗｅｂページ作成手段と、
該ｗｅｂページ作成手段で作成された前記ｗｅｂページにおいて、ユーザにより前記所定の処理の開始が要求されることで、前記所定の処理が行われることを特徴とする販売支援システム。
前記ショップが、商品データの提供元である少なくとも一つの提供元ショップと、該商品データの提供先である提供先ショップとで構成され、
前記提供元ショップから提供された商品データと前記提供先ショップの商品データを基に前記ｗｅｂページ作成手段で前記ｗｅｂページが作成されることを特徴とする請求項１～３のいずれか一項に記載の販売支援システム。
前記ショップの前記商品データ中の所定の箇所若しくは前記ソースコードを介して生成された画面に、前記センターサーバーが前記ショップのショップ名、コメント文、検索入力欄、検索ボタン、パンくずリスト、リンクボタン、販売店リスト、言語の選択ボックス及び所定の言語の翻訳文のいずれか少なくとも一つを埋め込む処理を行うことを特徴とする請求項１～４のいずれか一項に記載の販売支援システム。
前記センターサーバーに用意された管理画面と、
該管理画面において、前記ショップがユーザに対して問い合わせを行うために必要な仕様データを各ショップ毎に予め設定する仕様データ設定手段と、
該仕様データ設定手段で設定された前記仕様データに基づき、ユーザに対しての問い合わせを含むページを生成する問い合わせ生成手段と、
該問い合わせ生成手段で生成された前記ページが、前記所定の処理を行うプログラムにおいて前記ユーザに対して表示される問い合わせ表示手段と、
該問い合わせ表示手段で表示された前記ページの前記問い合わせに対する前記ユーザの返答結果が前記センターサーバーに保存される返答結果保存手段を備えたことを特徴とする請求項１～５のいずれか一項に記載の販売支援システム。
前記センターサーバーに用意された管理画面と、
該管理画面において、前記ショップが前記商品データの工程管理を行うために必要な仕様データを各ショップ毎に予め設定する仕様データ設定手段と、
該仕様データ設定手段で設定された前記仕様データに基づき、前記ショップに対しての商品の製作順序、商品の製作時間、商品の製作完了及び商品の配達の少なくともいずれか一つを含む工程を管理するページを生成する工程管理生成手段と、
該工程管理生成手段で生成された前記ページが、前記ショップに対して表示される表示手段を備えたことを特徴とする請求項１～６のいずれか一項に記載の販売支援システム。
前記所定の処理を行うプログラムにより、前記ｗｅｂページに掲載されている原文が複数のブロックに分離され、該ブロック毎に前記原文と該原文に対する翻訳文とが並べてユーザに対し表示されることを特徴とする請求項１～７のいずれか一項に記載の販売支援システム。
年齢、性別、趣味嗜好、業種、用途の少なくともいずれか一つの属性を含む複数の購入者の購入情報を基に、商品毎に属性別の購入度合いがまとめられた基本属性と、
ショップでユーザにより購入された複数の商品と、
該複数の商品について前記ショップでの購入の情報又は前記基本属性を基に属性別にまとめられた購入属性と、
該購入属性を基にユーザによる購入需要の大小を判定する判定手段を備えたことを特徴とする販売支援システム。
前記判定手段で前記購入需要が大きいと判断された属性について前記基本属性を基に同じ属性を有する商品データの追加、若しくは仕入れを判断、又は、前記ショップのサイトに他店の商品データを販売のために掲載することを特徴とする請求項９記載の販売支援システム。
前記判定手段で前記購入需要が小さいと判断されたとき、前記ショップの商品データを他店の通販サイトに販売のため掲載することを特徴とする請求項９又は請求項１０記載の販売支援システム。
年齢、性別、趣味嗜好、業種、用途の少なくともいずれか一つの属性を含む複数の購入者の購入情報を基に、商品毎に属性別の購入度合いがまとめられた基本属性と、
ショップで取り扱われている複数の商品データを収集する商品データ収集手段と、
前記複数の商品データについて前記基本属性を基にまとめた販売属性と、
前記ショップでユーザにより購入された複数の商品と、
該複数の商品について前記ショップでの購入の情報又は前記基本属性を基に属性別にまとめられた購入属性と、
前記販売属性と前記購入属性とを前記属性について対比する対比手段とを備えたことを特徴とする販売支援システム。