JP2022007976A - ネットショップ支援システム - Google Patents

Abstract

【課題】ネットショップで在庫切れが生じたり、訪問をしたユーザにとって欲しい商品が取り扱われていなかったがために受注の機会を逸することの無いよう、取り扱いの商品点数を充実させ、売上の増大を図ることの可能なネットショップ支援システムを提供する。【解決手段】商品データをセンターサーバーから提供先ショップのサーバーに対し提供する商品データ提供手段と、商品データ提供手段で提供された商品データを含む商品詳細ページを作成する商品詳細ページ作成部と、一覧ページを作成する一覧ページ作成部と、検索結果リストを作成する検索結果リスト作成部を有するｗｅｂページ作成手段と、ｗｅｂページ作成手段で作成されたｗｅｂページを介して提供元ショップの商品の販売があったとき、販売があった旨をセンターサーバー若しくは提供元ショップが確認処理する確認処理手段とを備えたことを特徴とする。【選択図】図３

Description

本発明はネットショップ支援システムに係わり、特にネットショップで在庫切れが生じたり、訪問をしたユーザにとって欲しい商品が取り扱われていなかったがために受注の機会を逸することの無いよう、取り扱いの商品点数を充実させ、売上の増大を図ることの可能なネットショップ支援システムに関する。

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

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

しかしながら、在庫を常に確保するには費用もかかり、在庫管理も煩雑であった。
また、ショップがユーザの商品探しに対し便宜を十分に図ったり、売上を延ばすためには、一つの方策として取り扱う商品点数を増大させ販売可能な商品を充実させることが望まれる。
こうすることで商品購入の頻度も増えるし、リピータの確保にも繋がり易くなると考えられる。
しかし、各ショップには取り扱う商品点数に限界があるし、商品点数を充実させるには費用もかかり、在庫管理の負担も急激に増えるおそれがある。
また、現在稼働中のショップをそのままの形で他のショップ参加型の通販モールに変えることができれば、在庫管理の負担無く取り扱う商品点数を充実できるが、稼働中のショップの通販システムを通販モール化の実現のために大幅に改造する必要が生ずる。更に、同種類の商品等でまとめたり、ジャンル構成や一覧リストの統一化を図ったり等技術的にも解決しなければならない課題は多い。

本発明はこのような従来の課題に鑑みてなされたもので、ネットショップで在庫切れが生じたり、訪問をしたユーザにとって欲しい商品が取り扱われていなかったがために受注の機会を逸することの無いよう、取り扱いの商品点数を充実させ、売上の増大を図ることの可能なネットショップ支援システムを提供することを目的とする。

このため本発明（請求項１）は、商品データの提供元である提供元ショップが保有する提供元ショップサーバーと、前記商品データの提供先である提供先ショップが保有する提供先ショップサーバーと、前記提供元ショップの商品データと前記提供先ショップの商品データとが、提供及び収集の少なくともいずれか一の方法により集められた商品データ収集手段と、該商品データ収集手段により集められた商品データを保存するセンターサーバー若しくは前記提供先ショップサーバーのデータベースと、前記商品データを前記センターサーバーから前記提供先ショップのサーバーに対し提供する商品データ提供手段と、該商品データ提供手段で提供された商品データを含む商品詳細ページを作成する商品詳細ページ作成部と、一覧ページを作成する一覧ページ作成部と、検索結果リストを作成する検索結果リスト作成部を有するｗｅｂページ作成手段と、該ｗｅｂページ作成手段で作成されたｗｅｂページを介して前記提供元ショップの商品の販売があったとき、該販売があった旨を前記センターサーバー若しくは前記提供元ショップが確認処理する確認処理手段とを備えて構成した。

提供元ショップの商品の販売を提供先ショップで行うことで、提供先ショップで取り扱い可能な商品を短時間の内に格段に増やして充実させることができる。従って、提供先ショップで取り扱いが無かったり、商品の在庫が無くても商品の販売が可能となり、売上機会の増大に繋がる。リピータの確保にも繋がり易くなる。検索対象の商品点数が増えることでユーザによる商品検索の精度も向上する。
提供先ショップにとっては在庫を常に確保する必要が少なくなり、商品点数が増えても在庫管理の負担は軽減する。在庫切れの不安は軽減する。
提供先ショップが行っているサービスを、提供元ショップでの商品購入にも適用することも可能であり、ユーザへのサービスの一層の充実を図ることができる。
提供先ショップにとって、新規ジャンルを開拓する足掛かりとなり、本格的に参入する前にその効果を事前に予測することができる。
提供先ショップが簡単にモール化や、提供元ショップとの間での相互の販売やいずれか一方のショップにおける提携しての販売を実現できる。
また、提供元ショップでは、自店で取り扱う商品の販売の機会や販売の場が増えることで、収益の増大や知名度の向上を図ることができる。

また、本発明（請求項２）は、商品データの提供元である提供元ショップが保有する提供元ショップサーバーと、前記商品データの提供先である提供先ショップが保有する提供先ショップサーバーと、前記提供元ショップの商品データ中に記載されていて、かつ、前記提供先ショップの通販サイトの商品詳細ページ中に掲載されるテキストと、該テキストの特定の箇所に前記提供元ショップのショップｉｄ、商品コード、ショップ名、及び該ショップ名を含むコメント文のいずれか少なくとも一つを埋め込む処理を行う埋め込み手段と、前記商品データを含む商品詳細ページを作成する商品詳細ページ作成部と、一覧ページを作成する一覧ページ作成部と、検索結果リストを作成する検索結果リスト作成部を有するｗｅｂページ作成手段と、前記商品詳細ページ作成部では、前記テキストが前記提供先ショップの通販サイトのデザインテンプレート中に埋め込まれた形で商品詳細ページが作成されたことを特徴とする。

提供元ショップの商品データ中に記載されていたテキストが、提供先ショップの通販サイトの商品詳細ページ中に掲載される。このテキスト中に、提供元ショップのショップｉｄ、商品コード、ショップ名、及び該ショップ名を含むコメント文のいずれか少なくとも一つを埋め込む。
ショップが既存の通販システムを持ち、既にこの通販システムを利用している場合には、商品詳細ページのデザインテンプレート中に各商品に応じたテキストを埋め込むことで商品詳細ページを作成している場合がある。この場合には、提供先ショップの通販サイトの改造をすることなく、この商品詳細ページに掲載している商品が提供元ショップの商品であることを明示できる。このため、この商品詳細ページを見たユーザは、提供先ショップの通販サイトで提供元ショップの商品の販売が行われていることを確認できる。また、配送元が提供元ショップであることが理解され易い。また、提供元ショップでは、提供先ショップにおいて提供元ショップの商品の販売があったことを、このショップｉｄ、商品コード等に基づき判断できる。ショップが新規に通販サイトを構築する場合も同様に適用が可能である。
このことにより、ショップ間での提携した販売が簡単に行える。

更に、本発明（請求項３）は、提供元ショップの商品データと提供先ショップの商品データとが、提供及び収集の少なくともいずれか一の方法により集められた商品データ収集手段と、該商品データ収集手段により集められた商品データを保存するセンターサーバー又は前記提供先ショップのデータベースと、前記提供元ショップの商品データと前記提供先ショップの商品データを、該提供先ショップの商品に対し関連付けられた販売店リスト及び個別商品の少なくともいずれか一の形に整理する商品まとめ手段と、該商品まとめ手段で整理された商品データに基づき販売のために前記センターサーバー又は前記提供先ショップにおいて商品詳細ページとして作成する商品詳細ページ作成部と、一覧ページを作成する一覧ページ作成部と、検索結果リストを作成する検索結果リスト作成部を有するｗｅｂページ作成手段と、該ｗｅｂページ作成手段で作成された商品詳細ページの一部若しくはすべてには、該商品詳細ページ毎の商品に関連付けられた前記販売店リストが挿入されたことを特徴とする。

提供元ショップの商品データと提供先ショップの商品データとが集められ、商品まとめ手段で販売店リスト及び個別商品の少なくともいずれか一の形に整理される。このため、商品詳細ページ作成部で作成される商品詳細ページの件数、一覧ページ作成部で作成される一覧ページに掲載される商品の件数、検索結果リスト作成部で作成される検索結果リストに掲載される商品の件数が共に急増できる。商品詳細ページの一部若しくはすべてには、商品詳細ページ毎の商品に関連付けられた販売店リストが挿入されているので、いずれかの提供元ショップでユーザにより購入がされ易い。

更に、本発明（請求項４）は、商品データの提供元である提供元ショップが保有する提供元ショップサーバーと、前記商品データの提供先である提供先ショップが保有する提供先ショップサーバーと、前記商品データを含む商品詳細ページを作成する商品詳細ページ作成部と、該商品詳細ページ作成部で作成された前記商品詳細ページに記載された前記提供元ショップの商品が前記提供先ショップの通販サイトで売上のあったことを通知するための前記提供先ショップの通販サイトからのメールを受信する受信手段と、該受信手段で受信されたメールを解析処理する解析手段と、該解析手段で解析されたメール中から抽出をしたデータに基づき前記販売のあった提供元ショップと商品を特定する処理を行う販売商品特定手段と、該販売商品特定手段で特定された前記提供元ショップの商品が売れた旨が前記提供元ショップで確認処理されることを特徴とする。

提供先ショップの通販サイトからの販売のメールを受信し、解析することで販売のあった提供元ショップとその商品を特定する。
このことにより、提供先ショップの通販サイトの改造をすることなく、提供先ショップの通販サイトで提供元ショップの商品の販売があったときに、この事実を提供元ショップで確実かつ容易に判断することができる。また、ユーザにとっては提供元ショップの商品であり、配送元が提供元ショップであることが理解され易い。

更に、本発明（請求項５）は、前記商品データを保存するセンターサーバーを備え、前記提供元ショップの商品データと前記提供先ショップの商品データを販売店リスト及び個別商品の少なくともいずれか一の形に整理する商品まとめ手段と、前記商品データ提供手段が、前記商品まとめ手段で整理された商品データを販売店リスト用及び商品詳細ページ作成用の少なくともいずれか一のデータとして前記センターサーバーから前記提供先ショップのサーバーに対し提供することを特徴とする。

これにより、ユーザが探し求めた商品の商品詳細ページに複数のショップが掲載されていることで、ユーザにとっては相場感も得易く購入し易い。販売店数が増加するため、いずれかのショップで購入される可能性が高くなる。更に、この提供先ショップが行っているサービスを、この提供元ショップでの商品購入にも適用することも可能であり、ユーザへのサービスの一層の充実を図ることができる。

更に、本発明（請求項６）は、前記商品データを更新する更新手段を備え、前記提供先ショップのサーバーが前記更新手段で更新された商品データをインポートするインポート手段を有し、該インポート手段でインポートした前記提供先ショップの商品データの少なくとも一部、または該商品データの価格、在庫数、送料及びポイントの少なくともいずれか一の項目については前記提供先ショップの商品データが更新されないことを特徴とする。

このことにより、提供先ショップ側での管理を優先させることができる。また、インポートした項目の内のリアルタイム性の高い項目についてはデータの更新をしないとすることも可能である。

更に、本発明（請求項７）は、前記商品データを保存するセンターサーバーを備え、前記一覧ページ作成部又は前記検索結果リスト作成部では、前記センターサーバーで絞られた商品データと前記提供先ショップにおいて絞られた商品データとの論理和、又は、前記センターサーバーで絞られた商品データに基づきリストが作成されることを特徴とする。

このことにより、提供先ショップでは自店の元々保有しているサーバー設備をそのまま使うことも可能である。設備の変更は少なくて済む。仮に、提供先ショップ側のデータベースの容量が小さくても大きな規模の商品データを扱える。検索の対象とする件数は、従来通り提供先ショップの元々保有している商品データのみなので検索の負荷も増えない。従って、既存のサーバー設備であっても検索速度をそのまま維持できる。また、センターサーバーのデータベースが扱うデータ分についてはデータの更新を考える必要がない。

更に、本発明（請求項８）は、前記商品データを含む商品詳細ページを作成する商品詳細ページ作成部を有するｗｅｂページ作成手段を備え、前記販売店リストがテキストである商品説明文中に挿入されて提供され、前記ｗｅｂページ作成手段では、前記商品説明文がデザインテンプレート中に埋め込まれることで商品詳細ページが作成されることを特徴とする。

商品詳細ページで販売店リストを開示するのに特別なスペースを改めて設ける必要が無くなる。このため、提供先ショップでは改造無く本システムを導入できる。

更に、本発明（請求項９）は、前記商品データが前記提供先ショップの商品であるか否か、及び、前記商品データに関連付けられた前記販売店リストが存在するか否かのいずれか少なくとも一つを判断する判断手段と、前記ｗｅｂページ作成手段では、前記判断手段の結果に基づき商品詳細ページが生成されることを特徴とする。

このように条件を判断して商品詳細ページを生成することにより、ユーザにとって購入のされ易い商品詳細ページを作成できる。
即ち、提供先ショップで取り扱われている商品であっても、在庫数の少ない場合には提供先ショップにおいて在庫切れのおそれが生ずる。しかしながら、商品詳細ページには販売店リストが掲載されることで、いずれかのショップで販売されている可能性が高くなるため、この心配が軽減する。
また、提供先ショップでは取り扱われていない非取扱商品についても商品詳細ページが生成され販売店リストが掲載されることで、サイト内の商品の充実を図ることができると共に、販売の機会を増やすことができる。更に、ユーザにとってはお目当ての商品を販売するショップの選択の幅が広がり、リピータの数を増やすことができる。作成された商品詳細ページは、検索結果リストや一覧リストにも掲載可能であり、非取扱商品でありながら提供先ショップで取り扱いの可能な商品として充実させることができる。検索対象の商品点数が増えることでユーザによる商品検索の精度も向上する。
更に、提供先ショップでは取り扱われていない商品で、かつ、販売店リストが生成されなかった商品についても商品詳細ページが作成される。このことにより、提供先ショップでは在庫が無くても商品の販売が可能となり、売上機会の増大に繋がる。リピータの確保にも繋がり易くなる。また、検索結果リストや一覧リストにも掲載可能であり、取り扱い可能な商品として充実させることができる。検索対象の商品点数が増えることでユーザによる商品検索の精度も向上する。
提供先ショップにとっては在庫を常に確保する必要が少なくなり、商品点数が増えても在庫管理の負担は軽減する。在庫切れの不安は軽減する。

更に、本発明（請求項１０）は、前記提供元ショップの商品データを管理する提供元用管理ツールと、前記提供先ショップの商品データを管理する提供先用管理ツールと、該提供先用管理ツール及び前記提供元用管理ツールの少なくともいずれか一の管理ツールでは前記提供元ショップの商品データが選択自在である商品データ選択手段とを備え、該商品データ選択手段で選択をされた商品データに基づき前記一覧ページ作成部での一覧ページの作成、及び、前記検索結果リスト作成部での検索結果リストの作成のいずれか少なくとも一つが行われることを特徴とする。

このことにより、提供先ショップでは、例えば提供先ショップで元々掲載しているジャンルと共通した提供元ショップ側のジャンルの内の必要な商品データのみを掲載できるようになり、提供先ショップ側のサイトの商品掲載ポリシーを踏襲する形で販売力の強化を図ることができる。

更に、本発明（請求項１１）は、前記商品詳細ページを作成するための複数のパターンの内で項目が少なくとも一つ共通化されたデザインテンプレートと、前記商品詳細ページのデザインテンプレートに属する項目に対応するデータ、若しくは、ｈｔｍｌソースコードの存在するときには前記項目及び前記データ、若しくは、前記データ、若しくは、前記ｈｔｍｌソースコードを含んでホームページが表示され、前記データ、若しくは、前記ｈｔｍｌソースコードの存在しないときには前記項目及び前記データ、若しくは、前記ｈｔｍｌソースコードについてホームページの表示がされないことを特徴とする。

共通化したデザインテンプレートで対応することで、提供先ショップでは改造を無くしたり、若しくは最小限にできる。複数のパターンについて容易に商品詳細ページを生成することができる。

更に、本発明（請求項１２）は、前記データベースでは、前記販売店リストとして関連付けされた商品データは前記個別商品データからは除かれたことを特徴とする。

販売店リストの掲載された商品の商品詳細ページと販売店リストの掲載されない個別商品の商品詳細ページとで同じショップの商品が検索結果リストや一覧ページに重複して掲載されるのを避けることができる。

更に、本発明（請求項１３）は、前記提供先ショップのｗｅｂページの一覧リスト若しくはユーザによる検索において、該一覧リスト若しくは検索の結果リストには前記販売店リストの掲載された商品詳細ページ、及び前記提供先ショップでは取り扱われていない商品の掲載された商品詳細ページのいずれか少なくとも一つが、前記提供先ショップで取り扱われている商品の掲載された商品詳細ページと共に掲載されたことを特徴とする。

このように商品詳細ページを掲載することで、一覧リストの件数や検索結果の件数を大幅に増加できる。従って、商品を漏れなく探したいと考えているユーザにとっては効率の良い検索等が行える。

更に、本発明（請求項１４）は、前記提供先ショップが有する提供先ショップサーバーと、前記提供元ショップが有する提供元ショップサーバーとを備え、該提供元ショップサーバーと前記提供先ショップサーバー、又は前記センターサーバーには、前記提供先ショップにおける前記提供元ショップの商品の販売の履歴、前記提供先ショップにおいて前記提供元ショップの商品が購入された旨の通知、前記提供元ショップが配送を完了した旨の通知、及び前記提供元ショップの商品在庫の有無の通知の内のいずれか少なくとも一つの機能を有する管理ツールを備えて構成した。

提供先ショップサーバーと提供元ショップサーバーとに、又はセンターサーバーに管理ツールを導入する。このことにより、提供先ショップにおける提供元ショップの商品の販売の履歴、提供先ショップにおいて提供元ショップの商品が購入された旨の通知、提供元ショップが配送を完了した旨の通知、提供元ショップの商品在庫の有無の通知のいずれか少なくとも一つが容易に行え、提供先ショップ側と提供元ショップ側とで簡単に管理できる。

更に、本発明（請求項１５）は、ショップで販促のために行われるキャンペーンの期間、キャンペーンの対象とする範囲、キャンペーンの内容、送信相手先ショップのいずれか少なくとも一つを選択することで、前記提供先ショップに掲載をした前記提供元ショップの商品について前記提供先ショップの商品で行うキャンペーンと同一の期間に同一内容のキャンペーンを行え、若しくは、前記提供先ショップと前記提供元ショップ間で互いに同一の期間に同一内容のキャンペーンを行えることを可能とした管理ツールを備えて構成した。

これにより、提携先ショップにおいて、自店の商品だけではなく、賛同した複数の提供元ショップの商品についてもまとめて自店の商品と同一内容のキャンペーンを実施できる。あるいは、賛同した複数のショップ間で互いに同一の時期に同一の内容のキャンペーンを実施できる。このため、相互販売、提携販売をしているショップ同士の間で共創関係が築かれ、共通するキャンペーンの下に販売力の強化が図れる。

以上説明したように本発明によれば、商品データをセンターサーバーから提供先ショップのサーバーに対し提供する商品データ提供手段と、商品データ提供手段で提供された商品データを含む商品詳細ページを作成する商品詳細ページ作成部と、一覧ページを作成する一覧ページ作成部と、検索結果リストを作成する検索結果リスト作成部を有するｗｅｂページ作成手段を備えて構成した。このため、提供元ショップの商品の販売を提供先ショップで行うことで、提供先ショップで取り扱い可能な商品を短時間の内に格段に増やして充実させることができる。従って、提供先ショップで取り扱いが無かったり、商品の在庫が無くても商品の販売が可能となり、売上機会の増大に繋がる。リピータの確保にも繋がり易くなる。検索対象の商品点数が増えることでユーザによる商品検索の精度も向上する。

本ネットショップ支援システムのシステム構成図 販売店リストの例 センターサーバーの構成図 提供先－提供元対応テーブルにおけるデータの関係性を示す図 提供元ショップのサーバーの構成図 提供先ショップのサーバーの構成図 各提供元ショップの商品データの収集、更新、データ集合体の生成方法を示すフローチャート 提供先ショップの商品データの収集、更新方法を示すフローチャート 販売店リストを用意する処理方法を示すフローチャート 特徴を表す要素の例 提供元ショップの残りの商品から販売店リストを作成する方法を示すフローチャート 提供先ショップのｗｅｂページで行われる検索の処理と一覧ページの処理方法を示すフローチャート 検索結果リストの概念図 商品詳細ページの作成方法を示すフローチャート（その１） 商品詳細ページの作成方法を示すフローチャート（その２） 商品詳細ページの作成方法を示すフローチャート（その３） 商品詳細ページの概略図（その１） 商品詳細ページの概略図（その２） 商品詳細ページの概略図（その３） 商品詳細ページの概略図（その４） 商品詳細ページ作成の別方法を示すフローチャート（その１） 商品詳細ページ作成の別方法を示すフローチャート（その２） 商品詳細ページ作成の別方法を示すフローチャート（その３） 提供先ショップと提供元ショップ間の関係を示す図 提供先ショップの販売履歴データを示す概念図 提供元ショップの販売履歴データを示す概念図 提供元ショップが同時に提供先ショップにもなっている場合の販売履歴データを示す概念図

以下、本発明の第１の実施形態について説明する。図１に本ネットショップ支援システムのシステム構成図を示す。
図１において、インターネット１０にはユーザの使用するパソコン３やスマートフォン５等の情報端末が接続されている。また、このインターネット１０には、商品データの提供元となるショッピングモール、ショップ、メーカー等の通販サイトを運営する提供元ショップ２のサーバー４が接続されている。図中、提供元ショップ２－１、２－２、２－３と示しているのは提供元ショップ２が複数であることを示している。これらの提供元ショップ２は独自のｗｅｂサイトを運営しているが、必ずしもサイトを持たなくても良い。

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

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

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

商品データ解析プログラム２３では巡回プログラム２１で収集した多数の商品データから、後述する所定のロジックにより同じ商品を取り扱うショップを一つの集合の販売店リストとしてまとめたり、販売店リストの生成されていない商品（以下、個別商品と言う）を抽出したりするものである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１ 提供先ショップ
２ 提供元ショップ
３ パソコン（情報端末）
４ 提供元ショップサーバー
５ スマートフォン（情報端末）
６ センターサーバー
７ 提供先ショップサーバー
９ 提供先ショップのｗｅｂサイト
１０ インターネット
１１ 、５１、７１演算部
１５ 、５５、７５通信部
２０ 商品データ収集・解析部
２１ 巡回プログラム
２３ 商品データ解析プログラム
３０ センターサーバーのデータベース
３１ 販売店リストデータベース
３３ 提供元ショップデータベース
３５ 提供先ショップデータベース
３７ 提供先－提供元対応データベース
３９ 提供元ショップ商品データベース
４１ 提供先ショップ商品データベース
４３ 販売履歴管理データベース
４５ 個別商品データベース
５７、７７ 管理部
５９ 提供元ショップサーバーの顧客データベース
６０ 提供元ショップサーバーのデータベース
６１ 提供元ショップ販売履歴管理データベース
６３ 提供先ショップ販売履歴管理データベース
６５ 提供元ショップ商品データベース
７９ ｗｅｂページ作成部
８０ 提供先ショップのデータベース
８１ 提供先ショップの顧客データベース
８３ 提供元ショップ販売履歴管理データベース
８５ 提供先ショップ販売履歴管理データベース
８７ 提供先ショップ商品データベース
８９ 個別商品データベース
１００、１１０、１２０、１３０ 商品詳細ページ
１０１ 購入ボタン
１０３、１１５ 販売店リスト
１１３、１３３ 提供元ショップのショップ名
２０１、２０３ 管理画面

Claims (15)

1. 商品データの提供元である提供元ショップが保有する提供元ショップサーバーと、
   前記商品データの提供先である提供先ショップが保有する提供先ショップサーバーと、
   前記提供元ショップの商品データと前記提供先ショップの商品データとが、提供及び収集の少なくともいずれか一の方法により集められた商品データ収集手段と、
   該商品データ収集手段により集められた商品データを保存するセンターサーバー若しくは前記提供先ショップサーバーのデータベースと、
   前記商品データを前記センターサーバーから前記提供先ショップのサーバーに対し提供する商品データ提供手段と、
   該商品データ提供手段で提供された商品データを含む商品詳細ページを作成する商品詳細ページ作成部と、一覧ページを作成する一覧ページ作成部と、検索結果リストを作成する検索結果リスト作成部を有するｗｅｂページ作成手段と、
   該ｗｅｂページ作成手段で作成されたｗｅｂページを介して前記提供元ショップの商品の販売があったとき、該販売があった旨を前記センターサーバー若しくは前記提供元ショップが確認処理する確認処理手段とを備えたことを特徴とするネットショップ支援システム。
2. 商品データの提供元である提供元ショップが保有する提供元ショップサーバーと、
   前記商品データの提供先である提供先ショップが保有する提供先ショップサーバーと、
   前記提供元ショップの商品データ中に記載されていて、かつ、前記提供先ショップの通販サイトの商品詳細ページ中に掲載されるテキストと、
   該テキストの特定の箇所に前記提供元ショップのショップｉｄ、商品コード、ショップ名、及び該ショップ名を含むコメント文のいずれか少なくとも一つを埋め込む処理を行う埋め込み手段と、
   前記商品データを含む商品詳細ページを作成する商品詳細ページ作成部と、一覧ページを作成する一覧ページ作成部と、検索結果リストを作成する検索結果リスト作成部を有するｗｅｂページ作成手段と、
   前記商品詳細ページ作成部では、前記テキストが前記提供先ショップの通販サイトのデザインテンプレート中に埋め込まれた形で商品詳細ページが作成されたことを特徴とするネットショップ支援システム。
3. 提供元ショップの商品データと提供先ショップの商品データとが、提供及び収集の少なくともいずれか一の方法により集められた商品データ収集手段と、
   該商品データ収集手段により集められた商品データを保存するセンターサーバー又は前記提供先ショップのデータベースと、
   前記提供元ショップの商品データと前記提供先ショップの商品データを、該提供先ショップの商品に対し関連付けられた販売店リスト及び個別商品の少なくともいずれか一の形に整理する商品まとめ手段と、
   該商品まとめ手段で整理された商品データに基づき販売のために前記センターサーバー又は前記提供先ショップにおいて商品詳細ページとして作成する商品詳細ページ作成部と、一覧ページを作成する一覧ページ作成部と、検索結果リストを作成する検索結果リスト作成部を有するｗｅｂページ作成手段と、
   該ｗｅｂページ作成手段で作成された商品詳細ページの一部若しくはすべてには、該商品詳細ページ毎の商品に関連付けられた前記販売店リストが挿入されたことを特徴とするネットショップ支援システム。
4. 商品データの提供元である提供元ショップが保有する提供元ショップサーバーと、
   前記商品データの提供先である提供先ショップが保有する提供先ショップサーバーと、
   前記商品データを含む商品詳細ページを作成する商品詳細ページ作成部と、該商品詳細ページ作成部で作成された前記商品詳細ページに記載された前記提供元ショップの商品が前記提供先ショップの通販サイトで売上のあったことを通知するための前記提供先ショップの通販サイトからのメールを受信する受信手段と、
   該受信手段で受信されたメールを解析処理する解析手段と、
   該解析手段で解析されたメール中から抽出をしたデータに基づき前記販売のあった提供元ショップと商品を特定する処理を行う販売商品特定手段と、
   該販売商品特定手段で特定された前記提供元ショップの商品が売れた旨が前記提供元ショップで確認処理されることを特徴とするネットショップ支援システム。
5. 前記商品データを保存するセンターサーバーを備え、
   前記提供元ショップの商品データと前記提供先ショップの商品データを販売店リスト及び個別商品の少なくともいずれか一の形に整理する商品まとめ手段と、
   前記商品データ提供手段が、前記商品まとめ手段で整理された商品データを販売店リスト用及び商品詳細ページ作成用の少なくともいずれか一のデータとして前記センターサーバーから前記提供先ショップのサーバーに対し提供することを特徴とする請求項１、２又は４記載のネットショップ支援システム。
6. 前記商品データを更新する更新手段を備え、
   前記提供先ショップのサーバーが前記更新手段で更新された商品データをインポートするインポート手段を有し、
   該インポート手段でインポートした前記提供先ショップの商品データの少なくとも一部、または該商品データの価格、在庫数、送料及びポイントの少なくともいずれか一の項目については前記提供先ショップの商品データが更新されないことを特徴とする請求項１～５のいずれか一項に記載のネットショップ支援システム。
7. 前記商品データを保存するセンターサーバーを備え、
   前記一覧ページ作成部又は前記検索結果リスト作成部では、前記センターサーバーで絞られた商品データと前記提供先ショップにおいて絞られた商品データとの論理和、又は、前記センターサーバーで絞られた商品データに基づきリストが作成されることを特徴とする請求項１～３のいずれか一項に記載のネットショップ支援システム。
8. 前記商品データを含む商品詳細ページを作成する商品詳細ページ作成部を有するｗｅｂページ作成手段を備え、
   前記販売店リストがテキストである商品説明文中に挿入されて提供され、
   前記ｗｅｂページ作成手段では、前記商品説明文がデザインテンプレート中に埋め込まれることで商品詳細ページが作成されることを特徴とする請求項１～７のいずれか一項に記載のネットショップ支援システム。
9. 前記商品データが前記提供先ショップの商品であるか否か、及び、前記商品データに関連付けられた前記販売店リストが存在するか否かのいずれか少なくとも一つを判断する判断手段と、
   前記ｗｅｂページ作成手段では、前記判断手段の結果に基づき商品詳細ページが生成されることを特徴とする請求項３に記載のネットショップ支援システム。
10. 前記提供元ショップの商品データを管理する提供元用管理ツールと、
    前記提供先ショップの商品データを管理する提供先用管理ツールと、
    該提供先用管理ツール及び前記提供元用管理ツールの少なくともいずれか一の管理ツールでは前記提供元ショップの商品データが選択自在である商品データ選択手段とを備え、
    該商品データ選択手段で選択をされた商品データに基づき前記一覧ページ作成部での一覧ページの作成、及び、前記検索結果リスト作成部での検索結果リストの作成のいずれか少なくとも一つが行われることを特徴とする請求項１、２、３、７のいずれか一項に記載のネットショップ支援システム。
11. 前記商品詳細ページを作成するための複数のパターンの内で項目が少なくとも一つ共通化されたデザインテンプレートと、
    前記商品詳細ページのデザインテンプレートに属する項目に対応するデータ、若しくは、ｈｔｍｌソースコードの存在するときには前記項目及び前記データ、若しくは、前記データ、若しくは、前記ｈｔｍｌソースコードを含んでホームページが表示され、
    前記データ、若しくは、前記ｈｔｍｌソースコードの存在しないときには前記項目及び前記データ、若しくは、前記ｈｔｍｌソースコードについてホームページの表示がされないことを特徴とする請求項１～５、８、９のいずれか一項に記載のネットショップ支援システム。
12. 前記データベースでは、前記販売店リストとして関連付けされた商品データは前記個別商品データからは除かれたことを特徴とする請求項３又は請求項５に記載のネットショップ支援システム。
13. 前記提供先ショップのｗｅｂページの一覧リスト若しくはユーザによる検索において、該一覧リスト若しくは検索の結果リストには前記販売店リストの掲載された商品詳細ページ、及び前記提供先ショップでは取り扱われていない商品の掲載された商品詳細ページのいずれか少なくとも一つが、前記提供先ショップで取り扱われている商品の掲載された商品詳細ページと共に掲載されたことを特徴とする請求項３、５、８、９、１２、１３のいずれか一項に記載のネットショップ支援システム。
14. 前記提供先ショップが有する提供先ショップサーバーと、
    前記提供元ショップが有する提供元ショップサーバーとを備え、
    該提供元ショップサーバーと前記提供先ショップサーバー、又は前記センターサーバーには、
    前記提供先ショップにおける前記提供元ショップの商品の販売の履歴、前記提供先ショップにおいて前記提供元ショップの商品が購入された旨の通知、前記提供元ショップが配送を完了した旨の通知、及び前記提供元ショップの商品在庫の有無の通知の内のいずれか少なくとも一つの機能を有する管理ツールを備えたことを特徴とする請求項１～１３のいずれか一項に記載のネットショップ支援システム。
15. ショップで販促のために行われるキャンペーンの期間、キャンペーンの対象とする範囲、キャンペーンの内容、送信相手先ショップのいずれか少なくとも一つを選択することで、前記提供先ショップに掲載をした前記提供元ショップの商品について前記提供先ショップの商品で行うキャンペーンと同一の期間に同一内容のキャンペーンを行え、若しくは、前記提供先ショップと前記提供元ショップ間で互いに同一の期間に同一内容のキャンペーンを行えることを可能とした管理ツールを備えたことを特徴とする請求項１～１４のいずれか一項に記載のネットショップ支援システム。

Images