(57)【特許請求の範囲】
【請求項１】
複数の仮想店舗へのアクセスを提供するオンラインショッピングの第１のポータルサイトと、前記複数の仮想店舗のうち特定の属性を有する一部の仮想店舗へのアクセスを提供し、かつ、該特定の属性を有する第２のポータルサイトとを管理する管理サーバであって、
前記複数の仮想店舗が有する属性の情報を含む店舗情報と、前記第２のポータルサイトが有する前記特定の属性の情報を含むサイト情報とを管理する管理手段と、
前記複数の仮想店舗のうちのいずれかの仮想店舗から、前記第２のポータルサイトにおける該仮想店舗へのアクセス提供を求めるアクセス提供申請を受け付ける第１の受付手段と、
前記第１の受付手段が前記アクセス提供申請を受け付けた場合に、前記管理手段が管理する前記店舗情報と前記サイト情報とに基づき、前記アクセス提供申請を行った仮想店舗が前記特定の属性を有するか否かを判定する判定手段と
を備え、
前記判定手段が前記アクセス提供申請を行った仮想店舗が前記特定の属性を有すると判定した場合、前記管理手段は前記アクセス提供申請を行った仮想店舗の店舗情報を、前記第２のポータルサイトが該仮想店舗へのアクセスを提供することを示すように更新することを特徴とする管理サーバ。
【請求項２】
前記店舗情報には、前記仮想店舗が扱う商品の属性の情報が含まれ、
前記判定手段は、前記アクセス提供申請を行った仮想店舗が扱う前記商品の属性が前記特定の属性を有するか否かに基づき、前記アクセス提供申請を行った仮想店舗が前記特定の属性を有するか否かを判定することを特徴とする請求項１に記載の管理サーバ。
【請求項３】
前記店舗情報には、前記仮想店舗が扱う商品の属性の情報が含まれ、
前記第１の受付手段は、前記アクセス提供申請を、該申請を行う仮想店舗が扱う商品ごとに受け付け、
前記判定手段は、前記アクセス提供申請を受け付けた前記商品の属性が前記特定の属性を有するか否かに基づき、前記アクセス提供申請を行った仮想店舗が前記特定の属性を有するか否かを判定し、
前記判定手段が前記アクセス提供申請を行った仮想店舗が前記特定の属性を有すると判定した場合、前記管理手段は前記アクセス提供申請を行った仮想店舗の店舗情報を、前記第２のポータルサイトが該仮想店舗における前記アクセス提供申請を受け付けた前記商品へのアクセスを提供することを示すように更新することを特徴とする請求項１に記載の管理サーバ。
【請求項４】
前記管理手段は、前記第１のポータルサイト及び前記第２のポータルサイトを介して仮想店舗にアクセス可能な顧客ユーザの、該顧客ユーザが有する属性の情報を含むユーザ情報を更に管理し、
前記第１のポータルサイトを介して仮想店舗にアクセス可能な顧客ユーザのうち、前記特定の属性を有する顧客ユーザのみが前記第２のポータルサイトを介して仮想店舗にアクセス可能である事を特徴とする請求項１乃至３のいずれか１項に記載の管理サーバ。
【請求項５】
前記第１のポータルサイトを介して仮想店舗にアクセス可能な前記顧客ユーザから、前記第２のポータルサイトを介した仮想店舗へのアクセスの許可を求めるアクセス許可申請を受け付ける第２の受付手段を更に備え、
前記第２の受付手段が前記アクセス許可申請を受け付けた場合に、前記判定手段は前記管理手段が管理する前記ユーザ情報に基づき前記アクセス許可申請を行った顧客ユーザが前記特定の属性を有するか否かを判定し、
前記判定手段が前記アクセス許可申請を行った顧客ユーザが前記特定の属性を有すると判定した場合、前記管理手段は前記アクセス許可申請を行った顧客ユーザのユーザ情報を、該顧客ユーザが前記第２のポータルサイトを介して仮想店舗へのアクセス可能であることを示すように更新することを特徴とする請求項４に記載の管理サーバ。
【請求項６】
前記管理手段は、前記仮想店舗の取引履歴の情報を更に管理し、
前記判定手段は、前記アクセス提供申請を行った仮想店舗が、前記第２のポータルサイトを介して仮想店舗にアクセスが可能な顧客ユーザとの取引実績を有するか否かを前記取引履歴の情報に基づき更に判定し、
前記判定手段は前記アクセス提供申請を行った仮想店舗が前記特定の属性を有し、かつ、前記取引実績を有すると判定した場合、前記管理手段は前記アクセス提供申請を行った仮想店舗の店舗情報を、前記第２のポータルサイトが該仮想店舗へのアクセスを提供することを示すように更新することを特徴とする請求項４または５に記載の管理サーバ。
【請求項７】
前記判定手段は前記取引実績を有するか否かの判定において、前記第２のポータルサイトを介して仮想店舗にアクセスが可能な顧客ユーザの数に応じた所定数以上の取引実績を有するか否かを判定することを特徴とする請求項６に記載の管理サーバ。
【請求項８】
第２のポータルサイトがアクセスを提供する前記仮想店舗から、前記第２のポータルサイト内で該第２のポータルサイトを介して仮想店舗にアクセス可能な顧客ユーザ向けのイベントの申請を更に受け付ける第３の受付手段を更に備えることを特徴とする請求項４乃至７のいずれか１項に記載の管理サーバ。
【請求項９】
前記イベントは、該イベントの申請を行った仮想店舗と取引実績のある顧客ユーザであって、前記第２のポータルサイトを介して仮想店舗にアクセス可能な顧客ユーザのみを対象とすることを特徴とする請求項８に記載の管理サーバ。
【請求項１０】
前記イベントには、該イベントを前記第２のポータルサイト内で実施する期間が設定され、
前記イベントは、前記期間のうちの一部の期間は、該イベントの申請を行った仮想店舗と取引実績のある顧客ユーザであって、前記第２のポータルサイトを介して仮想店舗にアクセス可能な顧客ユーザのみを対象とし、前記期間のうちの残りの期間は前記第２のポータルサイトを介して仮想店舗にアクセス可能な顧客ユーザ全てを対象とすることを特徴とする請求項８に記載の管理サーバ。
【請求項１１】
複数の仮想店舗のうちのいずれかの仮想店舗から新たな第２のポータルサイトの設定要求を更に受け付ける第４の受付手段と、
前記設定要求を受け付けた場合に、前記新たな第２のポータルサイトが有すべき属性と関連する属性を有し、かつ、前記第１のポータルサイトを介して仮想店舗にアクセス可能な顧客ユーザの情報を前記仮想店舗に提供する提供手段とを
更に備えることを特徴とする請求項４乃至１０のいずれか１項に記載の管理サーバ。
【請求項１２】
前記提供手段は、前記顧客ユーザの情報を、顧客ユーザの属性毎のユーザ数の情報として提供する請求項１１に記載の管理サーバ。
【請求項１３】
前記顧客ユーザの属性には、年齢、年代、性別、出身地、所在地、自宅住所、勤務住所、職業及び興味対象のうちの少なくともいずれかが含まれることを特徴とする請求項１２に記載の管理サーバ。
【請求項１４】
前記第４の受付手段は、前記設定要求を行う仮想店舗が有する属性と関連する属性を有する第２のポータルサイトの設定要求のみを受け付けることを更に特徴とする請求項１１乃至１３のいずれか１項に記載の管理サーバ。
【請求項１５】
前記特定の属性が共通する複数の前記第２のポータルサイトが存在する場合に、該複数の第２のポータルサイトを統合するか否かを判定する統合判定手段を更に備えることを特徴とする請求項１乃至１４のいずれか１項に記載の管理サーバ。
【請求項１６】
複数の仮想店舗へのアクセスを提供するオンラインショッピングの第１のポータルサイトと、前記複数の仮想店舗のうち特定の属性を有する一部の仮想店舗へのアクセスを提供し、かつ、該特定の属性を有する第２のポータルサイトとを管理する管理サーバの制御方法であって、
前記管理サーバの受付手段が、前記複数の仮想店舗のうちのいずれかの仮想店舗から、前記第２のポータルサイトにおける該仮想店舗へのアクセス提供を求めるアクセス提供申請を受け付ける受付工程と、
前記受付工程において前記アクセス提供申請を受け付けた場合に、前記管理サーバの判定手段が、前記仮想店舗が有する属性の情報を含む店舗情報と、前記第２のポータルサイトが有する前記特定の属性の情報を含むサイト情報とに基づき、前記アクセス提供申請を行った仮想店舗が前記特定の属性を有するか否かを判定する判定工程と
前記判定工程において前記アクセス提供申請を行った仮想店舗が前記特定の属性を有すると判定された場合、前記管理サーバの管理手段が、前記アクセス提供申請を行った仮想店舗の店舗情報を、前記第２のポータルサイトが該仮想店舗へのアクセスを提供することを示すように更新する更新工程と
を有することを特徴とする管理サーバの制御方法。
【請求項１７】
コンピュータを、請求項１乃至１５のいずれか１項に記載の管理サーバの各手段として機能させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明は、オンラインショッピングのポータルサイトを管理する管理サーバおよびその制御方法、並びにコンピュータプログラムに関する。
【背景技術】
【０００２】
近年、インターネット等を利用したオンラインショッピングが普及しており、利用者はオンライン上に出店している店舗が販売している商品の購入等のサービスを利用することができる。オンラインショッピングの提供形態は様々であり、出店している複数の店舗へのポータルサイトを提供する、所謂モール型のインフラシステムも存在する。モール型のインフラシステムでは店舗側に対して出店に係るインフラが提供されるため、店舗側は独自のシステムを構築せずとも容易にオンライン上に出店することができる。【０００３】
このようなインフラシステムでは、モール全体における販売促進や潜在顧客の確保のために、様々な付加価値を利用者に対して提供している。例えば、オンライン上の所定の店舗にて利用可能なクーポンやポイントの発行などが行われている。特許文献１では、利用者の行動履歴に基づいて、キャンペーンを提示する方法が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−２７７３６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
このようなインフラシステムにおけるオンラインショッピングにおいて、利用者は、モール内に多数の店舗や商品が存在するため、自身が必要とする商品や、そのような商品を扱う店舗を見つけにくいという問題がある。【０００６】
当該問題を解決するため、ユーザが必要とする商品や当該商品を扱う店舗が見つけやすいポータルサイトを提供し、管理する必要があるが、当該ポータルサイトを構築するための具体的な手段及び方法は未だ提案されていない。
【課題を解決するための手段】
【０００７】
上記課題を解決するために本願発明は以下の構成を有する。すなわち、複数の仮想店舗へのアクセスを提供するオンラインショッピングの第１のポータルサイトと、前記複数の仮想店舗のうち特定の属性を有する一部の仮想店舗へのアクセスを提供し、かつ、該特定の属性を有する第２のポータルサイトとを管理する管理サーバであって、
前記仮想店舗が有する属性の情報を含む店舗情報と、前記第２のポータルサイトが有する前記特定の属性の情報を含むサイト情報とを管理する管理手段と、
前記複数の仮想店舗のうちのいずれかの仮想店舗から、前記第２のポータルサイトにおける該仮想店舗へのアクセス提供を求めるアクセス提供申請を受け付ける第１の受付手段と、
前記第１の受付手段が前記アクセス提供申請を受け付けた場合に、前記管理手段が管理する前記店舗情報と前記サイト情報とに基づき、前記アクセス提供申請を行った仮想店舗が前記特定の属性を有するか否かを判定する判定手段とを備え、
前記判定手段が前記アクセス提供申請を行った仮想店舗が前記特定の属性を有すると判定した場合、前記管理手段は前記アクセス提供申請を行った仮想店舗の店舗情報を、前記第２のポータルサイトが該仮想店舗へのアクセスを提供することを示すように更新することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、ユーザが必要とする商品や当該商品を扱う店舗が見つけやすいポータルサイトを提供し管理する管理サーバにより、ポータルサイトを構築するための具体的な手段及び方法を提供することができる。【０００９】
本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。
【図面の簡単な説明】
【００１０】
添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。
【図１】本願発明に係るシステム全体の構成例を示す図。
【図２】本願発明に係る情報処理装置のハードウェア構成の例を示す図。
【図３】本願発明に係る管理サーバのソフトウェア構成の例を示す図。
【図４Ａ】本願発明に係る顧客ユーザ情報の管理テーブルの構成例を示す図。
【図４Ｂ】本願発明に係る店舗情報の管理テーブルの構成例を示す図。
【図４Ｃ】本願発明に係るセグメント情報の管理テーブルの構成例を示す図。
【図４Ｄ】本願発明に係る商品情報の管理テーブルの構成例を示す図。
【図４Ｅ】本願発明に係るイベント情報の管理テーブルの構成例を示す図。
【図４Ｆ】本願発明に係る売買取引情報の管理テーブルの構成例を示す図。
【図５】本願発明に係る店舗登録処理のフローチャート。
【図６】本願発明に係る顧客ユーザ登録処理のフローチャート。
【図７】本実施形態に係る固有ポータル参加処理のフローチャート
【図８】本願発明に係るセグメント登録処理のフローチャート。
【図９】本願発明に係るイベント登録処理のフローチャート。
【図１０】第一の実施形態に係るイベント通知処理のフローチャート。
【図１１Ａ】本願発明に係る初期のＵＩ画面の構成例を示す図。
【図１１Ｂ】本願発明に係る店舗登録用のＵＩ画面の構成例を示す図。
【図１１Ｃ】本願発明に係る顧客ユーザ登録用のＵＩ画面の構成例を示す図。
【図１１Ｄ】本願発明に係る固有ポータルへの参加申請用のＵＩ画面の構成例を示す図。
【図１１Ｅ】本願発明に係るセグメント登録用のＵＩ画面の構成例を示す図。
【図１１Ｆ】本願発明に係るイベント登録用のＵＩ画面の構成例を示す図。
【図１１Ｇ】本願発明に係るイベント表示用のＵＩ画面の構成例を示す図。
【図１２】本願発明に係るセグメントを説明するための図。
【図１３】第二の実施形態に係るセグメントのマージ処理のフローチャート。
【図１４】第三の実施形態に係るイベント通知処理のフローチャート。
【発明を実施するための形態】
【００１１】
以下、図面を用いて、本願発明に係る実施形態について説明する。なお、以下に示す実施形態は一例であり、これに限定するものではない。そのため、本願発明の特徴的構成を適用できれば他の構成であってもよい。
【００１２】
＜第一の実施形態＞
［セグメントの説明］
まず、本願発明にて扱う「セグメント」について説明する。本明細書では、オンラインショッピングのサービスを利用するユーザを「顧客ユーザ」と記載する。また、本願発明に係る管理サーバが提供するインフラサービスにオンライン上の仮想店舗を登録し、顧客ユーザ向けにオンラインショッピングのサービスを提供するユーザ（オーナー）を「店舗ユーザ」と記載する。また、管理サーバにて提供されるモール型のインフラサービス上に設けられるオンライン上に出店された仮想店舗を単に「店舗」と記載する。
【００１３】
モール型のインフラサービスでは、各店舗は、原則としてポータルサイトにおいて全ての顧客ユーザに対してアクセス可能に表示され、顧客ユーザは自由に店舗のサイトにアクセスすることが可能である。このような全顧客ユーザに対して開放されているポータルサイトを本明細書では「一般ポータル」と呼ぶ。しかし、オンラインショッピングのサービスを提供する店舗は、自身が扱う商品やサービス（以下、「商品等」という）の性質を考慮し、所定の客層（ターゲット）を絞って販売促進のキャンペーンや広告等の通知を行いたい場合がある。例えば、おむつや粉ミルクなどの幼児用消耗品（ベビー用品）は育児を行っていない顧客ユーザに対してはほとんどアピールを必要としない商品であり、店舗ユーザとしては現在育児中の顧客ユーザに対して選択的に（ターゲットを絞って）通知を行いたい。その一方で、顧客ユーザ側でも、一般ポータル内の多数の店舗に自由にアクセス可能な自由度がある反面、膨大な数の店舗の中から自身が興味のある商品等を扱う店舗を選択しなければならないという店舗選択の負担が存在する。このような状況において、顧客ユーザは、これまでに利用のない店舗からの通知も取得したいという欲求を有している場合も多い。
【００１４】
さらに、店舗ユーザ側には、これまで取引実績のない顧客ユーザ等、潜在的なニーズがある客層を新たに発掘したいという要望もある。また、顧客ユーザは、これまでは特に興味のない商品等であっても、店舗からのキャンペーン等に起因して新たに興味を持つことがある。ここでの店舗が提供するキャンペーンとは、商品購入時に利用可能なクーポンの発行や、送料無料などが挙げられる。
【００１５】
発明の実施形態では、顧客ユーザ、店舗、および店舗にて扱う商品等にそれぞれ属性が与えられる。属性とは、顧客ユーザや店舗に関する情報であって、顧客ユーザや店舗を分類可能な情報であればどのようなものであってもよい。例えば、顧客ユーザであれば年齢（年代）、性別、出身地、所在地（自宅住所、勤務住所）、職業、興味対象の他、管理サーバが提供するインフラサービス上における料金プランや制約、会員種別などを含むことができる。また、店舗であれば、店舗の所在地、店舗が扱う商品の分類（書籍、衣類、食品）や、店舗の分類（書店、衣料品店、食料品店等）等の情報を含むことができる。本実施形態において、店舗や顧客ユーザに付与される属性の一例は図１２に示す通りである。属性については、インフラサービスを提供する側で予め用意しておくものに加え、店舗ユーザや顧客ユーザが新たに定義するものであってもよい。例えば、新たな商品やサービスが生まれた場合などに伴って、その名称などを新たな属性として定義することも考えられる。
【００１６】
本明細書では、上記のような１または複数の属性が関連付けられた集合を「セグメント」と呼ぶ。そして、セグメントに関連付けられた属性を有する顧客ユーザや店舗はそのセグメントに属するものとして扱う。また、本明細書において、各セグメントにはそれぞれ、本実施形態で「固有ポータル」と呼ぶポータルサイトが関連付けられているものとする。固有ポータルの例としては、例えば年齢が１９から２４歳までの学生を対象とした学生向けのポータルサイトや、子育て中の家族を対象としたポータルサイト等がある。
【００１７】
詳細については後述するが、上記の一般ポータルは、店舗や顧客ユーザの属性を限定しておらず、顧客ユーザからのアクセスの制限を設けていない。これに対し、固有ポータルでは、対応するセグメントに関連付けられた属性を有する顧客ユーザ以外はアクセスできないようにアクセス制御されるものとする。また、固有ポータルに参加できる店舗も、セグメントに関連付けられた属性を有している、もしくはセグメントに関連付けられた属性を有する商品等を扱っている店舗に限定される。ここでの「参加」とは、店舗がある固有ポータルを介して顧客ユーザからアクセス可能となったり、任意の広告やキャンペーンなどを表示したりすることを意味する。このとき、ある固有ポータルに参加している店舗は、セグメントに対してイベントを設定登録することで、そのセグメントが関連付けられた固有ポータル上にイベントの詳細を表示等することができるものとする。
【００１８】
以下、本実施形態に対応する固有ポータルを提供するシステム、及び、当該システムが提供するサービスの詳細を説明する。
【００１９】
［システム構成］
図１は、本実施形態に係るシステムの全体構成の例を示す図である。システムにおいて、管理サーバ１０１、店舗ＰＣ１０２、および顧客ＰＣ１０３が、インターネット１０４を介して接続されている。管理サーバ１０１は、オンラインショッピングサービスの基盤となるインフラを、店舗ＰＣ１０２および顧客ＰＣ１０３を介して店舗ユーザおよび顧客ユーザにそれぞれ提供する情報処理装置である。このインフラに対し、商品等を提供する店舗ユーザがオンライン上の店舗として登録することでオンラインショッピングサービスの提供が可能となる。なお、原則として、各店舗はまずは一般ポータルに登録されることとなり、全ての顧客ユーザがアクセス可能となっている。
【００２０】
店舗ＰＣ１０２は、店舗ユーザが利用する情報処理装置である。また、顧客ＰＣ１０３は、オンラインショッピングサービスを利用する顧客ユーザが扱う情報処理装置である。なお、店舗ＰＣ１０２、および顧客ＰＣ１０３は、デスクトップＰＣでも良いし、スマートフォンやタブレットなどのモバイル端末でもよい。各ユーザは、店舗ＰＣ１０２や顧客ＰＣ１０３が備えるＷｅｂブラウザ（不図示）を介して、管理サーバ１０１が提供する一般ポータルへとアクセスする。なお、各ＰＣからインターネット１０４への接続は、有線でも無線でも構わない。また、図１では、各機器が１台ずつ示されているが、それぞれ複数接続されていても構わない。
【００２１】
［ハードウェア構成］
図２は、本実施形態に係るシステムに含まれる各情報処理装置のハードウェア構成例を示す。なお、以下では一般的な情報処理装置を例に挙げて説明するが、これ以外の構成を備えていても構わない。
【００２２】
情報処理装置２００は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ＨＤＤ２０４、表示ＩＦ２０５、表示部２０６、入力ＩＦ２０７、入力部２０８、およびＮＷ  ＩＦ２０９を備える。各構成要素は、バス２１０を介して通信可能に接続されている。ＣＰＵ２０１は、情報処理装置２００の全体の処理制御を行い、また、ＲＯＭ２０３等に保持された各種プログラムをＲＡＭ２０２に読み出して実行することで各種処理を実現する。ＲＡＭ２０２は、揮発性の記憶領域であり、各種プログラムの実行時におけるワークメモリなどの用途で用いられる。ＲＯＭ２０３は、不揮発性の記憶領域であり、処理に用いられる各種プログラム等が格納される。ＨＤＤ２０４は、不揮発性の記憶領域であり、処理結果などを記憶して保持する。ＨＤＤ２０４は、不揮発性の大容量の記憶領域であればよく、ハードディスク以外にも、例えばフラッシュメモリのような半導体メモリにより構成されても良い。
【００２３】
表示ＩＦ２０５は、表示部２０６に接続され、表示部２０６の表示制御を行う。表示部２０６は、液晶などのディスプレイであり、処理結果を表示したり、後述する各種ユーザインタフェース画面（ＵＩ画面）などを表示したりする。なお、表示部２０６は情報処理装置２００に対し外付けされるように構成されてもよく、その場合は表示ＩＦ２０５を介して情報処理装置２００に接続される。入力ＩＦ２０７は、入力部２０８に接続され、ユーザ操作に基づく入力部２０８からの指示を受け付ける。入力部２０８は、例えば、キーボードやマウス（不図示）であり、ユーザが入力操作を行う際に用いられる。なお、表示部２０６と入力部２０８とが一体型となったタッチパネルが用いられても構わない。ＮＷ  ＩＦ２０９は、インターネット１０４などの外部ネットワークとの接続を行う。ここでの接続形態は有線／無線のいずれであっても構わない。
【００２４】
［ソフトウェア構成］
図３は、本実施形態に係る管理サーバ１０１のソフトウェア構成例を示す図である。ここで示すソフトウェアは、管理サーバ１０１が備える記憶部（ＲＯＭ２０３やＨＤＤ２０４等）にプログラムとして保持され、管理サーバ１０１のＣＰＵ２０１に読み出して実行されることにより各種の制御及び処理が実現される。
【００２５】
顧客ユーザ管理部３０１は、オンラインショッピングのサービスを利用する顧客ユーザのユーザ情報を管理する。顧客ユーザの情報は、例えば、図４Ａに示す構成を備え、詳細については後述する。
【００２６】
店舗管理部３０２は、店舗ユーザから登録されたオンライン上の店舗の各設定に関する店舗情報を管理する。店舗情報は、例えば、図４Ｂに示す構成を備え、詳細については後述する。
【００２７】
セグメント管理部３０３は、店舗ユーザからの要求に応じて、各種セグメントを生成し、登録する。また、セグメント生成部３０３は、登録したセグメントの編集およびマージ、管理等の処理を行う。セグメント情報は、例えば、図４Ｃに示す構成を備え、詳細については説明する。また、セグメントに関する詳細な説明や処理フローについては後述する。
【００２８】
ＵＩ制御部３０４は、各種設定内容に応じて、各ＰＣからの要求に対応したＵＩ画面を提供する。ＵＩ画面の一例は図１１Ａから図１１Ｇに示す通りである。
【００２９】
顧客ユーザ認証部３０５は、オンラインショッピングサイトへアクセスを行った顧客ユーザのログイン制御を行う。具体的には、顧客ユーザが入力した認証情報（ユーザ名、パスワード）を受け付け、顧客ユーザ管理部３０１にて管理されているユーザ名とパスワードの情報に基づいて、認証処理を行う。また、顧客ユーザ認証部３０５は、各顧客ユーザによる固有ポータルへのアクセス時の制御も行う。
【００３０】
店舗認証部３０６は、店舗ユーザからのアクセスに対し、認証処理を行う。ここでの認証は、顧客ユーザの認証と同様に行っても良いし、別途認証方式を用いてもよい。また、店舗認証部３０６は、店舗側から固有ポータルへの参加を要求された場合の参加処理も行う。本処理の詳細については後述する。
【００３１】
検索部３０７は、店舗ユーザがセグメントを生成する際や編集する際に、そのセグメントに属する顧客ユーザの情報を検索する。ここで検索される情報としては、例えば、セグメントに属する顧客ユーザ数などが該当する。
【００３２】
商品管理部３０８は、各店舗が扱う商品の情報を店舗と関連づけて管理する。商品の情報については、店舗が扱う商品等の登録を受け付ける。このとき、一般的に販売されている商品等であれば、予め管理サーバ１０１が登録しておき、その中から店舗ユーザが選択できるようにしてもよい。商品情報は、例えば、図４Ｄに示す構成を備え、詳細については後述する。
【００３３】
イベント管理部３０９は、店舗からの登録要求に応じて、各種イベント（キャンペーンや広告等）の登録を受け付け、管理する。イベント情報は、例えば、図４Ｅに示す構成を備え、詳細については後述する。また、ここで登録されるイベントは、一般ポータルにて通知されるものや、固有ポータル内に限定して通知されるものなどが挙げられる。イベント登録処理の詳細については後述する。
【００３４】
取引管理部３１０は、顧客ユーザと店舗との間で商品等の売買取引の情報を管理する。売買取引の情報は、例えば、図４Ｆに示す構成を備え、詳細については後述する。
【００３５】
［データ構成］
図４Ａから図４Ｆは、本実施形態に係る管理サーバ１０１が管理する各種データの構成例を示す図である。ここで示される各データは、管理サーバ１０１が管理する内部もしくは外部の記憶領域に保持されているものとする。また、以下に示す各情報は、１のテーブルで管理されても良いし、複数のテーブルに分割されて管理されてもよい。
【００３６】
図４Ａは、顧客ユーザに関する顧客情報のデータ構成例を示す。顧客情報は、例えば、顧客ＩＤ、ユーザ名、パスワード、顧客属性、参加セグメントを含んで構成される。顧客ＩＤは、顧客ユーザを一意に識別するためのＩＤ（識別情報）である。ユーザ名は顧客ユーザがサイト上で使用する自身の名称であって、顧客ユーザ向けの各種ＵＩ画面に顧客ユーザがログインする際のログイン名としても使用される。パスワードは、管理サーバ１０１が提供する、顧客ユーザ向けの各種ＵＩ画面に顧客ユーザがログインする際の認証に用いられる。顧客属性は、上述の顧客ユーザに関する情報（年齢（年代）、性別、出身地、所在地（自宅住所、勤務住所）、職業、興味対象、料金プランや制約、会員種別（シルバー会員、ゴールド会員、ダイヤモンド会員等）等）である。参加セグメントは、当該顧客ユーザがアクセス可能な固有ポータルに対応するセグメントの情報を示す。
【００３７】
図４Ｂは、店舗に関する店舗情報のデータ構成例を示す。店舗情報は、例えば、店舗ＩＤ、店舗名、パスワード、店舗属性、商品ＩＤ、参加セグメント及び参加形態の情報を含んで構成される。店舗ＩＤは、店舗を一意に識別するためのＩＤ（識別情報）である。店舗名は、一般ポータル及び固有ポータルで使用する店舗の名称である。店舗ユーザが店舗ユーザ向けの各種ＵＩ画面にログインする際のログイン名としても利用される。パスワードは、管理サーバ１０１が提供する、店舗ユーザ向けの各種ＵＩ画面に店舗ユーザがログインする際の認証に用いられる。店舗属性は、上述の店舗が扱う商品の分類や、店舗の分類等の情報を含む。商品ＩＤは、店舗が扱う商品情報を一意に識別するための識別情報（ＩＤ）を示す。参加セグメントは、当該店舗が属するセグメントの情報を示す。参加形態は、店舗がセグメントに参加する形態の情報を含む。参加形態は後述するように店舗全体として参加する「店舗型」と、商品毎の参加する「商品型」とがある。参加形態が「店舗型」の場合、商品ＩＤには店舗が扱う商品情報の全てが登録されるか、当該商品情報の全てを管理する別テーブルへのリンク情報が登録される。一方、参加形態が「商品型」の場合、商品ＩＤには参加の対象となった商品の情報が登録される。
【００３８】
図４Ｃは、セグメント情報のデータ構成例を示す。セグメント情報は、例えば、セグメントＩＤ、作成店舗、マージ可否、セグメント名、セグメント属性、および参加店舗を含んで構成される。セグメントＩＤは、セグメントを一意に識別するためのＩＤ（識別情報）である。作成店舗は、セグメントを作成した店舗の店舗ＩＤが設定される。管理サーバ１０１が生成したセグメントであれば、その旨が示される。マージ可否は、類似するセグメントのマージの可否の設定を示す。マージ可否の情報の詳細及びその利用方法については、第二の実施形態にて説明する。セグメント名は、セグメントの名称を示す。
【００３９】
セグメント属性は、セグメントに属する顧客ユーザ（ターゲット）を特定するための属性を示す。セグメント属性は、顧客ユーザがセグメントに属するユーザであるか、即ち、セグメントに対応する固有ポータルにアクセス可能な顧客ユーザであるかを判定するために利用可能である。また、当該固有ポータルにアクセス可能な潜在的な顧客ユーザを抽出するために用いることもできる。その際、セグメント属性に登録された属性は、図４Ａに示す顧客情報のテーブルに登録された属性と比較される。例えば、図４ＡのＵＳＥＲ Ａは、顧客属性が男、３０代、ゴールド会員であり、セグメントＡのセグメント属性と一致し参加資格を有している。そして、ＵＳＥＲ ＡはセグメントＡを参加セグメントとして実際に登録されている。
【００４０】
また、セグメント属性は、店舗が参加可能なセグメント（固有ポータル）を特定する際にも用いることができる。例えば、店舗が固有ポータルへの参加を申請した場合、参加を許可するか否かは店舗に与えられた店舗属性の内容と、固有ポータルのセグメント属性とを比較することにより判定される。また、あるセグメントに関連付けられた固有ポータルに対して、ある店舗が新たにキャンペーン等のイベントを行いたい場合に、そのイベント登録の申請時において、属性の関係性により登録可能か否かを判断することができる。参加店舗は、そのセグメントに対応する固有ポータルに参加している店舗を示す。ここでは、店舗の店舗ＩＤが示される。参加店舗に示される店舗は、例えば、セグメントに対応する固有ポータルにイベントを登録可能である。
【００４１】
図４Ｄは、各店舗が扱う商品の商品情報のデータ構成例を示す。ここでの商品とは、書籍、文具、食品等の物であっても良いし、宿泊予約、ゴルフ場予約、マルチメディアのダウンロードなどのサービスであってもよい。以下の説明では、簡単のために物やサービスの区別を問わず「商品」と総称して説明する。商品情報は、例えば、商品ＩＤ、商品名、店舗ＩＤ、および商品属性を含んで構成される。商品ＩＤは、商品を一意に識別するためのＩＤ（識別情報）であり、図４Ｂの店舗情報のテーブルに登録されている商品ＩＤに対応する。商品名は対応する商品の一般的な流通名称である。店舗ＩＤは、その商品を扱っている店舗の店舗ＩＤであるが、商品と店舗との関係は図４Ｂで特定可能であるので、ここでの店舗ＩＤは省略しても良い。商品属性は、商品の分類や対象（ターゲット）などを示す情報である。例えば、商品が衣服であれば、衣服の種類や名称（Ｔシャツ、セーター等）、購入対象者の性別、サイズ、価格、クーポン利用の可否、商品説明、商品写真等の情報が含まれる。
【００４２】
図４Ｅは、店舗が設定する顧客ユーザに対するキャンペーンや固有の商品の告知など（以下、「イベント」と総称する）を管理するためのイベント情報のデータ構成例を示す。イベント情報は、例えば、イベントＩＤ、イベント名、店舗ＩＤ、セグメントＩＤ、通知期間、イベント内容を含んで構成される。イベントＩＤは、イベントを一意に識別するためのＩＤ（識別情報）である。店舗ＩＤは、イベントに参加する店舗の店舗ＩＤを示す。本実施形態においてイベントは、店舗単位に実施されても良いし、固有ポータルに参加する店舗に共通に実施されても良い。後者の場合、複数の店舗ＩＤに対して同一のイベントＩＤが割り当てられる。例えば、ある店舗のみで行うイベントであれば、その店舗がイベントを登録するような構成となる。一方、複数店舗に共通して行われるイベントであれば、そのイベントを登録する際に複数の店舗を指定しても良いし、セグメント（固有ポータル）単位で指定してもよい。更には、店舗側から参加希望を受け付けるようにしてもよい。イベント名は、イベントに与えられた名称である。セグメントＩＤは、イベントの通知先（ターゲット）となるセグメントのセグメントＩＤを示す。ここで指定されたセグメントに属する顧客ユーザがイベントの通知先（ターゲット）として扱われることとなる。通知期間は、イベントの実施を顧客ユーザに対して通知する期間、即ちイベントが実施されている期間を示す。ここで指定された期間において、例えば固有ポータルの所定のＵＩ画面にてイベントの通知が行われる。イベント内容は、登録したイベントの詳細な内容を示す。イベントの種類には、例えば当該店舗にて買い物を購入する際に金券として使用可能なクーポン券の発行、当該店舗にて買い物をした場合に送料を無料とする送料無料クーポンの発行等がある。ここでの内容は店舗ユーザが細かく設定できるようにしても良いし、管理サーバ１０１側で予め設定可能な選択肢を用意しておいてもよい。また、個別の商品に対する広告や通知でも良いし（商品単位）、店舗全体に関する広告や通知であってもよい（店舗単位）。
【００４３】
図４Ｆは、店舗と顧客ユーザとの間で行われた売買取引（利用履歴）の情報を管理するための取引情報のデータ構成例を示す。取引情報は、例えば、取引ＩＤ、売主、買主、日時、および取引内容を含んで構成される。取引ＩＤは、取引を一意に識別するためのＩＤ（識別情報）である。売主は、取引において商品等の売主情報を示す。ここでは、販売者である店舗の店舗ＩＤが示される。買主は、取引において商品等の買主情報を示す。ここでは、購入者である顧客ユーザの顧客ＩＤが示される。日時は、取引を行った日時情報を示す。購入した商品や購入店舗、アクセス履歴などの情報が含まれる。取引内容は、取引に用いられる商品の種類や個数、その他オプション情報などが示される。
【００４４】
上記の各種データの構成例は、本願発明にて用いられる情報の一例であり、他の情報が含まれてもよい。
【００４５】
［処理フロー］
図５〜図１０は、本実施形態に係る処理のフローチャートを示す。
【００４６】
（店舗登録処理）
図５は、店舗ユーザが店舗ＰＣ１０２から管理サーバ１０１にアクセスし、管理サーバ１０１への店舗の登録申請を行う際の処理フローを示す。本処理により店舗が登録されることにより、一般ポータルへの出店、開示が行われるようになる。これにより顧客ユーザは、一般ポータル上で登録された店舗へアクセスが可能となる。
【００４７】
本処理フローは、管理サーバ１０１と店舗ＰＣ１０２それぞれのＣＰＵがＨＤＤ等の記憶部に格納されたプログラムを読み出して実行することにより実現される。管理サーバ１０１側では、図３に示す店舗管理部３０２、ＵＩ制御部３０４、店舗認証部３０６が機能することにより、本処理が行われる。また、店舗ＰＣ１０２は、Ｗｅｂブラウザ（不図示）を有する。店舗ＰＣ１０２は、Ｗｅｂブラウザを介して、ＨＴＴＰ（Hyper Text Transfer Protocol）などを用いて管理サーバ１０１にアクセスし、管理サーバ１０１が提供する各種ＵＩ画面を表示する。
【００４８】
Ｓ５０１にて、店舗ＰＣ１０２は、店舗ユーザからの指示に基づき、管理サーバ１０１にアクセスし、店舗登録の要求を行う。例えば、店舗ユーザは、管理サーバ１０１が提供する初期画面（図１１Ａ）にアクセスし、そこから店舗登録要求を行うことができる。図１１Ａは、各ＰＣからアクセスされた際の初期画面（一般ポータル）の構成例を示す。ログイン用画面や店舗登録を行う際のリンクなどが表示される。店舗登録を行う場合は、当該リンクを選択し店舗登録用の画面を取得することができる。また、店舗の検索や各店舗にて扱われている商品の一覧などを表示している。例えば、店舗登録を行う際には、そのリンクを店舗ユーザが選択することで、登録画面へと遷移することとなる。なお、ポータル画面の構成はこれに限定するものではなく、機能に応じて複数の画面にて提供するようにしてもよい。
【００４９】
Ｓ５０２にて、管理サーバ１０１は、店舗ＰＣ１０２からの店舗登録要求の応答として、店舗登録画面（図１１Ｂ）を提供する。図１１Ｂは、店舗ＰＣ１０２から受信した要求に応じて、店舗を登録する際の店舗登録画面の構成例を示す。店舗登録を行う際には、例えば店舗名、商品、オーナー情報、属性の情報を入力することができる。入力された店舗名、属性、商品の情報は、図４Ｂに示すテーブルに登録される店舗名、店舗属性の情報や、図４Ｄに示す商品属性の情報として管理される。なお、扱う商品が膨大な場合には、店舗登録の後に専用のＵＩ画面（不図示）にて各商品を登録するようにしてもよい。
【００５０】
Ｓ５０３にて、店舗ＰＣ１０２は、管理サーバ１０１から提供された店舗登録画面をＷｅｂブラウザに表示し、店舗ユーザから各種店舗情報の入力を受け付ける。その後、入力が完了したら、店舗ＰＣ１０２は、入力された店舗情報を管理サーバ１０１へ送信する。このとき、店舗にて扱う商品等の商品情報を併せて登録できるようにしてもよい。商品を登録する場合には、入力された商品は、図４Ｄに示すテーブルに登録される。この場合には、管理サーバ１０１は、商品管理部３０８を介して、商品の登録を行うこととなる。また、店舗自身に関連付ける１または複数の店舗属性の情報を登録できるようにしてもよい。ここでの登録において、管理サーバ１０１が提供するインフラサービスの料金プランや規約などに応じて、一定条件の下、登録可能な情報が変動してもよい。
【００５１】
Ｓ５０４にて、管理サーバ１０１は、店舗ＰＣ１０２から店舗情報を受け付けると、店舗ＩＤやパスワード等の情報を発行し、店舗情報と共に図４Ｂに示すテーブルに登録する。
【００５２】
Ｓ５０５にて、管理サーバ１０１は、登録完了の通知と共に、発行した情報を店舗ＰＣ１０２へ通知する。
【００５３】
Ｓ５０６にて、店舗ＰＣ１０２は、管理サーバ１０１から送信された情報を受信し、その情報を表示する。その後、本処理フローを終了する。
【００５４】
（顧客ユーザ登録処理）
図６は、顧客ユーザが顧客ＰＣ１０３から管理サーバ１０１にアクセスし、ユーザ登録を行う際の処理フローを示す。管理サーバ１０１側では、図３に示す顧客ユーザ管理部３０１、ＵＩ制御部３０４、顧客ユーザ認証部３０５が機能することにより、本処理が行われる。本処理フローは、管理サーバ１０１と顧客ＰＣ１０３それぞれのＣＰＵがＨＤＤ等に格納されたプログラムを読み出して実行することにより実現される。また、顧客ＰＣ１０３は、Ｗｅｂブラウザ（不図示）を有しており、Ｗｅｂブラウザを介して、管理サーバ１０１にアクセスし、管理サーバ１０１が提供する各種ＵＩ画面を表示する。
【００５５】
Ｓ６０１にて、顧客ＰＣ１０３は、顧客ユーザからの指示に基づき、管理サーバ１０１にアクセスし、ユーザ登録の要求を行う。
【００５６】
Ｓ６０２にて、管理サーバ１０１は、顧客ＰＣ１０３からのユーザ登録要求の応答として、顧客ユーザ登録画面（図１１Ｃ）を提供する。図１１Ｃは、顧客ＰＣ１０３から受信した要求に応じて、顧客ユーザを登録する際の顧客ユーザ登録画面の構成例を示す。顧客ユーザを登録する際には、ユーザ名、生年月日、連絡先、属性、パスワード、セグメント指定等の情報を入力することができる。その他、性別、出身地、所在地（自宅住所、勤務住所）、職業、興味対象等の個人情報を入力することができる。入力されたユーザ名、パスワード、個人情報は、例えば、図４Ａに示すテーブルに登録されるユーザ名、パスワード、顧客属性として管理される。
【００５７】
Ｓ６０３にて、顧客ＰＣ１０３は、管理サーバ１０１から提供された顧客ユーザ登録画面をＷｅｂブラウザに表示し、顧客ユーザから各種ユーザ情報の入力を受け付ける。その後、入力が完了したら、顧客ＰＣ１０３は、入力されたユーザ情報を管理サーバ１０１へ送信する。このとき、顧客ユーザ自身に関連付ける１または複数の属性情報を登録できる。さらには、顧客ユーザは、自身の属性と関連するセグメントの中から任意のセグメントを選択し、参加申請するか否かを指定できる。もしくは、例えば、料金プランや顧客ユーザ自身が有する属性に応じて、管理サーバ１０１側で自動的にセグメントを割り当てるようにしてもよい。上述したように、セグメントを割り当てられた顧客ユーザは、そのセグメントに対応する固有ポータルへのアクセスが可能となる。
【００５８】
Ｓ６０４にて、管理サーバ１０１は、顧客ＰＣ１０３からユーザ情報を受け付けると、顧客ＩＤ等の情報を発行し、図４Ａに示すテーブルにユーザ情報を登録する。ここで、受け付けたユーザ情報の中にセグメントへの参加申請が含まれる場合、顧客ユーザが選択したセグメントへの参加が可能か否かについて、承認判定、認証を行う。参加を許可する場合はそのセグメントの情報が図４Ａの参加セグメントに登録される。ここでの参加承認判定及び認証の処理の詳細に関しては、例えば顧客ユーザが有する属性や過去に購入した商品の属性と、セグメントが有する属性との対応関係などに準じて行うようにしてよい。例えば、セグメントの属性に対応する属性を有する商品を購入した実績のある顧客ユーザのみが当該セグメントに参加可能としても良い。この処理により、顧客ユーザと無関係なセグメントへの参加を防止することができる。
【００５９】
Ｓ６０５にて、管理サーバ１０１は、登録完了の通知と共に、発行した情報を顧客ＰＣ１０３へ通知する。
【００６０】
Ｓ６０６にて、顧客ＰＣ１０３は、管理サーバ１０１から送信された情報を受信し、その情報を表示する。その後、本処理フローを終了する。
【００６１】
（固有ポータル参加処理）
図７は、店舗ユーザが店舗ＰＣ１０２から管理サーバ１０１にアクセスし、既に設定済みのセグメントに対応する固有ポータルへの参加を申請する際の処理フローを示す。本処理により、店舗が任意の固有ポータルに参加した場合、例えば、その固有ポータル上での店舗や商品の表示や、その固有ポータル内に限ったイベントの広告などが可能となる。
【００６２】
本処理フローは、管理サーバ１０１と店舗ＰＣ１０２それぞれのＣＰＵがＨＤＤ等に格納されたプログラムを読み出して実行することにより実現される。管理サーバ１０１側では、図３に示す店舗管理部３０２、セグメント管理部３０３、ＵＩ制御部３０４、店舗認証部３０６が機能することにより本処理が行われる。また、店舗ＰＣ１０２は、Ｗｅｂブラウザ（不図示）を有しており、Ｗｅｂブラウザを介して、管理サーバ１０１にアクセスし、管理サーバ１０１が提供する各種ＵＩ画面を表示する。
【００６３】
Ｓ７０１にて、店舗ＰＣ１０２は、店舗ユーザからの指示に基づき、管理サーバ１０１にアクセスし、固有ポータル参加の要求を行う。このとき、店舗はすでに管理サーバ１０１に登録され、パスワード等を用いた店舗認証部３０６による認証が完了しているものとする。
【００６４】
Ｓ７０２にて、管理サーバ１０１は、店舗ＰＣ１０２からの固有ポータルへの参加要求の応答として、固有ポータル参加画面（図１１Ｄ）を提供する。図１１Ｄは、店舗ＰＣから受信した要求に応じて、固有ポータル（セグメント）への参加を行う際の固有ポータル参加画面の構成例を示す。ここでは、店舗が参加したい固有ポータルに対応付けられたセグメント或いは固有ポータル自体を指定することで参加の要求（申請）を行うことができる。また、参加可能なセグメントのリスト（一覧）を選択可能に表示してもよい。また、セグメントに関連付けられた属性の情報を併せて表示するようにしてもよい。また、店舗ユーザが属性を入力し、入力された属性を有するセグメントに関連づけられた固有ポータルを表示し、店舗ユーザからの選択入力を受け付けるようにしても良い。
【００６５】
さらに店舗ユーザは図１１Ｄの画面で参加形態を選択することができる。ここで固有ポータル参加の形態としては、店舗全体として参加する店舗型の形態と、店舗が扱っている商品毎に参加する商品型の形態とがある。参加形態として「店舗型」を選択した場合は商品を設定する必要はない。一方、参加形態として「商品型」を選択した場合、固有ポータルに掲載する商品を選択する。商品の選択は個々の商品を指定する方法であっても良いし、商品の種別やジャンルを指定する方法であっても良い。例えば、店舗がドラッグストアである場合に、商品として紙おむつや粉ミルクを個別に指定することもできるが、ベビー用品してこれらの個別商品を包含する種別を指定することもできる。ここで設定された情報は図４Ｂの商品ＩＤ、参加セグメント及び参加形態の情報として店舗情報に登録される。
【００６６】
このような参加形態の選択を可能とする場合、店舗全体として参加する形態では、固有ポータルから店舗のサイトへアクセスすることが可能であり、かつ、店舗が扱っている商品が全て固有ポータルに帰属することになる。よって、固有ポータル全体に適用されるイベント（クーポンや送料無料）は店舗全体が適用対象となる。一方、商品毎の参加形態では、店舗で扱っている商品のうちの一部が選択され、固有ポータルからアクセス可能となる。この場合、固有ポータル全体に適用されるイベントがあっても、固有ポータルに登録している一部の商品等のみが対象となる。このような商品毎の参加形態により、複数種類の商品を扱っている大型店舗のように店舗全体としては固有ポータルに参加できない店舗も商品単位の参加が可能となる。
【００６７】
Ｓ７０３にて、店舗ＰＣ１０２は、管理サーバ１０１から提供された固有ポータル参加画面をＷｅｂブラウザに表示し、店舗ユーザから参加対象となる固有ポータル（セグメント）の情報の入力を受け付ける。その後、店舗ＰＣ１０２は、選択された固有ポータルの情報を、管理サーバ１０１へ送信する。なお、セグメントの選択時において、参加できない固有ポータル（セグメント）については、初めから表示されないようにＵＩ画面の表示制御を行うようにしてもよい。参加できない固有ポータルとは、該固有ポータルに関連づけられたセグメントが有する属性を店舗或いは該店舗が扱う商品が有していない固有ポータルのことである。この場合、当該店舗はその固有ポータルに参加する資格を有していないので予め選択肢から除外しておくことが望ましい。あるいは、将来的な参加の動機づけを与えるべく、一覧表示には含めてもよいが、グレーアウトするなどして選択対象から除外してもよい。
【００６８】
次にＳ７０４にて、管理サーバ１０１は、店舗ＰＣ１０２から固有ポータルの選択を受け付けると、当該店舗が選択された固有ポータルに参加可能か否かについて、承認判定、認証を行う。Ｓ７０４で参加が許可されると、参加が許可された固有ポータルのセグメントの情報が図４Ｂの参加セグメントに登録されると共に、図４Ｃに示す参加店舗に当該店舗の情報が登録される。る。
【００６９】
Ｓ７０４における判定及び認証の処理の詳細に関しては、店舗ＰＣ１０２側から固有ポータルへの参加要求があった後、管理サーバ１０１側で入力内容の確認を行った上で参加させる。この場合の承認判定では、例えば、店舗側の権限（店舗によるインフラサービスの利用プラン）や規約、固有ポータルに関連付けられたセグメントと店舗が有する属性、もしくは店舗が扱う商品が有する属性の対応関係などに準じて行うようにしてよい。
【００７０】
さらに、承認判定では、固有ポータルに参加する条件として、固有ポータルに登録している顧客ユーザと取引実績があることを要求しても良いし、店舗の評価として一定以上の評価を獲得していることを要求しても良い。取引実績の有無は図４Ｆの取引情報を参照することにより判定が可能である。実績の有無についても、単なる有る無しに限らず、固有ポータルに登録している顧客ユーザ数に応じた閾値を設けて、参加ユーザ数が多い固有ポータルについては、店舗の参加条件としてより多くの取引実績を要求するようにしても良い。その逆に、顧客ユーザ数が多い固有ポータルについては取引実績の条件を緩和して閾値を低く設定する一方、新規に設立された固有ポータルについて、セグメントの属性に対応する商品やサービスの販売実績、或いは当該属性を有する顧客ユーザとの取引実績の多いことを条件としても良い。
【００７１】
Ｓ７０５にて、管理サーバ１０１は、固有ポータルへの参加処理の完了の通知を店舗ＰＣ１０２へ送信する。
【００７２】
Ｓ７０６にて、店舗ＰＣ１０２は、固有ポータルへの参加処理の完了の通知を管理サーバ１０１から受信し、その旨を表示する。その後、本処理フローを終了する。
【００７３】
（セグメント登録処理）
図７では、設定済みの固有ポータルへ店舗が参加を申請する場合の処理について説明したが、以下では店舗が新たにセグメントを設定し固有ポータルを開設する場合の処理について説明する。図８は、店舗ユーザが店舗ＰＣ１０２から管理サーバ１０１にアクセスし、セグメントを登録する際の処理フローを示す。管理サーバ１０１側では、図３に示す店舗管理部３０２、セグメント管理部３０３、ＵＩ制御部３０４、店舗認証部３０６、検索部３０７が機能することにより、本処理が行われる。
【００７４】
本処理フローは、管理サーバ１０１と店舗ＰＣ１０２それぞれのＣＰＵがＨＤＤ等に格納されたプログラムを読み出して実行することにより実現される。また、店舗ＰＣ１０２は、Ｗｅｂブラウザ（不図示）を有しており、Ｗｅｂブラウザを介して、管理サーバ１０１にアクセスし、管理サーバ１０１が提供する各種ＵＩ画面を表示する。
【００７５】
Ｓ８０１にて、店舗ＰＣ１０２は、店舗ユーザからの指示に基づき、管理サーバ１０１にアクセスし、セグメント登録の要求を行う。このとき、店舗はすでに管理サーバ１０１に登録され、パスワード等を用いた認証が完了しているものとする。
【００７６】
Ｓ８０２にて、管理サーバ１０１は、店舗ＰＣ１０２からのセグメント登録要求の応答として、セグメント登録画面（図１１Ｅ）を提供する。図１１Ｅは、店舗ＰＣ１０２から受信した要求に応じて、セグメントを登録する際のセグメント登録画面の構成例を示す。顧客ユーザは、セグメント名、属性、マージの可否について入力することができる。入力されたセグメント名、属性、マージの可否は、セグメントが設定された後に、図４Ｃに示すテーブルに登録されるセグメント名、マージ可否、セグメント属性として管理される。なお、図１１Ｅでは、属性をまとめて設定するような構成にしているが、店舗、顧客ユーザ、商品といった分類ごとに属性を設定できるようにしてもよい。
【００７７】
Ｓ８０３にて、店舗ＰＣ１０２は、管理サーバ１０１から提供されたセグメント登録画面をＷｅｂブラウザに表示する。
【００７８】
Ｓ８０４にて、店舗ＰＣ１０２は、店舗ユーザから各種セグメント情報の入力を受け付ける。この時、店舗ＰＣ１０２は、セグメントに対応付ける属性の入力を受け付ける。その後、店舗ＰＣ１０２は、受け付けた１または複数の属性の情報を、管理サーバ１０１へ送信する。
【００７９】
Ｓ８０５にて、管理サーバ１０１は、受信した属性の組み合わせに基づいて、その属性の組み合わせに該当する顧客ユーザの情報をテーブルから検索し、抽出する。ここで抽出される顧客ユーザの情報とは、例えば顧客ユーザの総数などが該当するが、他の情報であってもよい。例えば、抽出された顧客ユーザを年代、性別、職業、出身地、所在地、興味対象等に分類し、分類毎の顧客ユーザ数を提供しても良い。或いは、属性に関連する商品を購入した実績のある顧客ユーザ数であってもよい。これらの条件はＳ８０４にて顧客ユーザが属性と共に入力しても良い。なお、顧客情報は個人情報に該当し、一般的に管理上の厳密な制限が想定されるため、顧客ユーザの個人名や住所等の詳細な情報は出力されないようにしてよい。また、店舗ユーザによって複数の属性が入力された場合、属性のＡＮＤ条件で検索しても良いし、ＯＲ条件で検索してもよい。また、店舗ユーザが入力可能な属性の数について、検索結果に応じて上限数／下限数を設定してもよい。検索が完了した後、管理サーバ１０１は、検索結果を店舗ＰＣ１０２に通知する。
【００８０】
また、Ｓ８０５にて店舗ユーザが入力可能な属性は、店舗ユーザの店舗が有する属性と一致または、当該属性と関連するもの（属性の範囲に含まれるもの）に限定してもよい。この属性の関連性或いは範囲について、本実施形態では属性を上位概念、中位概念、下位概念のように階層的に設定することができる。下位概念は上位概念、中位概念の範囲に含まれ、中位概念は上位概念の範囲に含まれる。例えば、衣服という上位概念の範囲には洋服、和服などの中位概念が含まれ、洋服の下位概念にはスーツ、ジャケット、パンツ等が含まれる。よって、「衣服」という属性が選択されれば、スーツやジャケットは当該属性に関連すると共にその範囲に含まれることとなる。このように入力可能な属性を制限することにより、店舗に無関係なセグメントの設定を防止することができる。
【００８１】
Ｓ８０６にて、店舗ＰＣ１０２は、管理サーバ１０１から送信された情報を受信し、その情報を表示する。その検索結果に基づき、店舗ＰＣ１０２は、店舗ユーザからそのセグメント情報の内容で登録するか否かの指示を受け付ける。
【００８２】
Ｓ８０７にて、店舗ＰＣ１０２は、店舗ユーザから登録の指示を受け付けたか否かを判定する。登録の指示を受け付けた場合（Ｓ８０７にてＹＥＳ）Ｓ８０８へ進み、入力した属性を変更する指示を受け付けた場合（Ｓ８０７にてＮＯ）Ｓ８０４へ進み、処理を繰り返す。店舗ユーザは、検索結果を参照することで、設定した属性が、店舗が潜在的な顧客とすべき顧客ユーザを適切に囲い込んでいるかどうかを判定することができる。店舗ユーザは期待した検索結果が得られなかった場合には属性の設定をやり直して再度上記の処理を繰り返すことができる。これにより、店舗ユーザは潜在的な顧客ユーザを効率的に囲い込むことが可能な固有ポータルを設立することができる。
【００８３】
Ｓ８０８にて、店舗ＰＣ１０２は、店舗ユーザから受け付けた登録の指示および入力されたセグメント情報を管理サーバ１０１へ送信する。
【００８４】
Ｓ８０９にて、管理サーバ１０１は、店舗ＰＣ１０２からセグメント情報を受け付けると、セグメントＩＤ等の情報を発行し、図４Ｃに示すテーブルにセグメント情報を登録する。このとき、セグメントを作成した店舗をはじめから参加させるような構成でも良いし、作成した店舗が選択できるような構成であってもよい。ここで、管理サーバ１０１はセグメント情報に該当する店舗数や顧客ユーザ数に基づき、所定の閾値を超えない店舗数や顧客ユーザ数のセグメントの作成を拒否する構成にしても良い。また、セグメントの作成の可否は、セグメント情報に含まれる属性に該当する顧客ユーザとの取引実績（販売実績）の有無を考慮しても良い。例えば、当該顧客ユーザとの販売実績のない店舗や、一定数以上の販売実績がない店舗にはセグメントの作成権利を認めないこととして、申請を拒否することができる。
【００８５】
Ｓ８１０にて、管理サーバ１０１は、登録完了の通知を店舗ＰＣ１０２へ送信する。
【００８６】
Ｓ８１１にて、店舗ＰＣ１０２は、登録完了の通知を管理サーバ１０１から受信し、その旨を表示する。その後、本処理フローを終了する。
【００８７】
なお、図８では、新たにセグメントを生成し、登録する際の処理の流れを示したが、すでに登録されているセグメントの内容を編集する際も同様の流れで行われる。主な編集内容としては、セグメントに対応づける属性の追加・修正・削除等がある。編集の場合は、Ｓ８０１〜Ｓ８０３の工程で変更要求を送信し、その応答として得られる編集画面にて、編集対象となるセグメントを選択することとなる。
【００８８】
（イベント登録処理）
図９は、本実施形態に係るイベント登録処理のフローチャートを示す。管理サーバ１０１側では、図３に示す店舗管理部３０２、セグメント管理部３０３、ＵＩ制御部３０４、店舗認証部３０６、イベント管理部３０９が機能することにより、本処理が行われる。
【００８９】
本処理フローは、管理サーバ１０１と店舗ＰＣ１０２それぞれのＣＰＵがＨＤＤ等に格納されたプログラムを読み出して実行することにより実現される。また、店舗ＰＣ１０２は、Ｗｅｂブラウザ（不図示）を有しており、Ｗｅｂブラウザを介して、管理サーバ１０１にアクセスし、管理サーバ１０１が提供する各種ＵＩ画面を表示する。なお、ここで登録されるイベントの表示や通知に関する処理は図１０を用いて後述する。
【００９０】
Ｓ９０１にて、店舗ＰＣ１０２は、店舗ユーザからの指示に基づき、管理サーバ１０１にアクセスし、イベント登録の要求を行う。このとき、店舗はすでに管理サーバ１０１に登録され、店舗認証部３０６によりパスワード等を用いた認証が完了しているものとする。また、イベントの登録において、店舗ごとに登録数の上限を設定しても良いし、イベントの内容に応じて登録可否を判定してもよい。この場合、一旦、店舗ＰＣ１０２から登録の要求があった後、管理サーバ１０１側でイベント登録の承認処理（不図示）を行うように制御するものとする。
【００９１】
Ｓ９０２にて、管理サーバ１０１は、店舗ＰＣ１０２からのイベント登録要求の応答として、イベント登録画面（図１１Ｆ）を提供する。図１１Ｆは、店舗ＰＣ１０２から受信した要求に応じて、イベントを登録する際のイベント登録画面の構成例を示す。店舗ユーザは、イベント名、セグメントＩＤ、通知期間、イベント内容の情報を入力することができる。入力された情報は、図４Ｅに示すテーブルに登録されるイベント名、セグメントＩＤ、通知期間、イベント内容の情報として管理される。なお、すでに登録されているセグメントから選択する際には、選択可能なセグメントのリストを表示させるようにしてもよい。
【００９２】
Ｓ９０３にて、店舗ＰＣ１０２は、管理サーバ１０１から提供されたイベント登録画面をＷｅｂブラウザに表示する。
【００９３】
Ｓ９０４にて、店舗ＰＣ１０２は、店舗ユーザから各種イベント情報の入力を受け付ける。この時、イベントに対応付けるセグメントの選択を受け付ける。ここで店舗ユーザが選択可能なセグメントは、店舗が参加している固有ポータルに対応するセグメントが相当する。セグメントの選択時において、登録ができないセグメントは予め表示されないように、或いは選択ができないようにＵＩ画面の表示制御を行うようにしてもよい。また、固有ポータルに限定したイベントではなく、一般ポータルにて行うイベントであれば、セグメントの選択は行わず、対象を一般ポータルとして設定することとなる。なお、この工程で新たにセグメントを生成できるようにしても良い。その後、店舗ＰＣ１０２は、受け付けたイベント情報を、管理サーバ１０１へ送信する。各種イベント情報の設定として店舗側がターゲットとするセグメント（顧客ユーザ）を選択することで、登録するイベントの対象としたい相手（セグメントおよびそれに関連付けられた固有ポータル）を明確に指定することができる。また、店舗が固有ポータルに参加していない場合であっても、店舗側から固有の商品に関するイベントを登録しようとする際には、その商品が有する属性と、登録しようとするセグメントに関連付けられた属性とが一致することで、登録を許可するようにしてもよい。また、セグメントを選択した際に、イベントの通知対象となる顧客ユーザ数が表示されるような構成にしてもよい。
【００９４】
Ｓ９０５にて、管理サーバ１０１は、店舗ＰＣ１０２からイベント情報を受け付けると、イベント管理部３０９によりイベントＩＤ等の情報を発行し、図４Ｅに示すテーブルにイベント情報を登録する。なお、登録においては別途申請／承認や、認証などの構成を設けてもよい。例えば、Ｓ９０４の工程において、店舗ＰＣ１０２側からイベントの情報入力があった後、管理サーバ１０１側で入力内容の確認（自動判定、もしくは管理者による判定）を行った上で登録処理を行うようにしてもよい。この場合の確認では、例えば、店舗側の権限（店舗によるインフラサービスの利用プラン）や規約などに準じて行うようにしてよい。
【００９５】
Ｓ９０６にて、管理サーバ１０１は、登録完了の通知を店舗ＰＣ１０２へ送信する。
【００９６】
Ｓ９０７にて、店舗ＰＣ１０２は、登録完了の通知を管理サーバ１０１から受信し、その旨を表示する。その後、本処理フローを終了する。
【００９７】
上記図５から図９の説明では、顧客ユーザ、店舗、商品、イベント、セグメントなどに対する登録の処理について説明したが、例えば、すでに登録している情報を編集する際においても同様の流れで行うことが可能である。この場合には、各ＰＣからの要求に応じて、編集用のＵＩ画面（不図示）が管理サーバ１０１から各ＰＣに提供され、そのＵＩ画面を介して編集が行われるものとする。
【００９８】
（イベント通知処理）
以下、本実施形態に係るイベントの通知方法について説明する。本実施形態では、顧客ユーザがユーザ登録を行った後に、管理サーバ１０１が提供するサービスサイトへログインすることでアクセス可能な固有ポータルへ遷移できるものとする。固有ポータルサイトでは、対応するセグメントに応じて表示される内容（イベント）が異なるものとする。具体的には、上述したように、セグメントそれぞれには固有ポータルが対応付けられ、その固有ポータルに対して登録されたイベントが表示される。同様に、一般ポータルにアクセスした際には、その一般ポータル向けに登録されたイベントが通知されることとなる。顧客ユーザが有する属性情報に応じて、その顧客ユーザがアクセス可能なポータルサイト（固有ポータル）が変化することとなる。
【００９９】
図１０は、本実施形態に係るイベントの通知の処理フローを示す。本処理フローは、管理サーバ１０１のＣＰＵがＨＤＤ等の記憶部に格納されたプログラムを読み出して実行することにより実現される。管理サーバ１０１側では、図３に示す顧客ユーザ管理部３０１、ＵＩ制御部３０４、顧客ユーザ認証部３０５、イベント管理部３０９が機能することにより、本処理が行われる。
【０１００】
Ｓ１００１にて、管理サーバ１０１は、顧客ＰＣ１０３を介して、顧客ユーザからのログイン要求を受け付ける。この時、管理サーバ１０１は、ユーザＩＤおよびパスワードを併せて受け付け、認証処理を行う。ここでは、認証が成功しているものとして処理を進める。
【０１０１】
Ｓ１００２にて、管理サーバ１０１は、認証が成功した顧客ユーザの顧客情報を参照し、参加可能に登録されているセグメントがあるか否かを判定する。参加可能なセグメントがある場合（Ｓ１００２にてＹＥＳ）にてＳ１００３へ進み、参加可能なセグメントが無い場合（Ｓ１００２にてＮＯ）本処理フローを終了する。
【０１０２】
Ｓ１００３にて、管理サーバ１０１は、ログインした顧客ユーザに対し、参加可能なセグメントに対応付けられた固有ポータルへのアクセスを許可する。
【０１０３】
Ｓ１００４にて、管理サーバ１０１は、Ｓ１００３にてアクセスを許可された固有ポータルに顧客ユーザからアクセスされた際に、図４Ｅのテーブルに基づいて、セグメントに対応するイベントを表示（図１１Ｇ）するように制御する。図１１Ｇは、顧客ユーザが固有ポータルのページにアクセスした際に表示される、イベントの通知画面の構成例を示す。ここでは、顧客ユーザがアクセス可能な固有ポータルにアクセスした際に、その固有ポータルに係るイベントが表示される。図１１Ｇの例では、イベントが一覧形式で表示されているがこれに限定するものではなく、例えば、ページ内のイベント表示用の領域に時間ごとに切り替わるように表示されても良い。その後、本処理フローを終了する。
【０１０４】
なお、本実施形態では、アクセス可能な固有ポータル上にて表示して通知を行う例を示したが、これに限定するものではなく、他の通知方法で行うようにしてもよい。
【０１０５】
［本実施形態の効果］
以上で説明した本実施形態によれば、管理サーバが提供するポータルサイト（一般ポータル）に登録している顧客ユーザのうち、特定の属性と関連する顧客ユーザのみを対象とした固有ポータルを提供することができる。当該固有ポータルは一般ポータルに登録している店舗のうち、上記特定の属性に関する条件を満たす特定の店舗のみが参加可能である。即ち、固有ポータルは特定の属性に関連する店舗と顧客ユーザとが取引を行う場として提供されるポータルサイトであって、顧客ユーザの立場からは、固有ポータルに参加することにより自身が必要とする商品やサービスを効率的に探し出して購入することができるので、多数の店舗や商品の中から自分が必要とする商品や店舗を探し出す手間や負担を効果的に削減することが可能となる。また、店舗の立場からは、店舗が扱う商品、サービスに対する需要（ニーズ）を有する顧客ユーザを囲い込んで、その顧客ユーザに対して効率的に商品、サービスを提供できるので、効率的な店舗運営が可能となる。特に、一般ポータルにおいて不特定多数の顧客ユーザに対してプロモーションを行うよりも、より確実に販売に結びつけることが可能となり、販売実績を効率的に向上させることが可能となる。
【０１０６】
また、本実施形態の固有ポータルは、管理サーバが参加可能な店舗や顧客ユーザに条件を設定することで構築されており、固有ポータルで扱う商品、サービスに無関係な店舗や顧客ユーザ、販売実績や評価の低い店舗などを排除することができる。これにより、顧客ユーザの立場からは、固有ポータルに参加するだけで、自分が必要とする商品を扱っている店舗を絞り込む手間を確実に省くことが可能となり、これまで取引が無い店舗でも簡単に探し出すことができる。また固有ポータルに訪問すれば、固有ポータルの店舗が行っているイベントの情報を確実に入手できるのでイベント情報の見落としも防止することができる。一方の店舗の立場からは、自身商品やサービスを必要としている顧客ユーザに対してイベント通知などの働きかけが可能となるので、すでに取引を行っている顧客ユーザのみならず、これまでは購入履歴等が無い潜在的な顧客ユーザに対しても、店舗へ効果的に誘導することが可能となる。
【０１０７】
＜第二の実施形態＞
本実施形態は、店舗ユーザにて設定されたセグメントを、その類似度に応じてマージ（統合）する実施形態である。店舗ユーザが複数のセグメントを生成した場合に、類似するセグメントが生成されることが考えられる。このような場合には、セグメントをマージすることで、セグメントの管理を容易にする。また類似のセグメントの場合、ターゲットも類似することが想定され、マージしても問題が生じないことが多い。その一方で、マージを行いたくないセグメントも存在する。これらを考慮し、本実施形態では、セグメントのマージ処理を行う。
【０１０８】
まず、本実施形態において、店舗ユーザは、セグメントの登録／編集画面において、マージを許可するか否かの設定を受け付けているものとする。
【０１０９】
（セグメントのマージ処理）
図１３は、本実施形態に係る管理サーバ１０１における、セグメントを統合する処理フローを示す。本処理フローは、管理サーバ１０１のＣＰＵがＨＤＤ等に格納されたプログラムを読み出して実行することにより実現される。本処理フローの実行のタイミングは、予め指定された日時に実行されるようにしても良いし、同一または類似の属性を有するセグメントの数が所定数を超えた場合や、ある店舗が作成したセグメント数が所定の数を超えた場合に実行するようにしても良い。
【０１１０】
Ｓ１３０１にて、管理サーバ１０１は、図４Ｃのテーブルを参照して、生成されたセグメント情報を取得する。この時、店舗ＩＤをキーにしてセグメントを検索する。
【０１１１】
Ｓ１３０２にて、管理サーバ１０１は、取得したセグメント情報の中から、マージが禁止されているセグメントの情報を除去する。ここでのマージが禁止されているセグメントは、店舗ユーザによって設定されているものとし、具体的には、図４Ｃの「マージ可否」の設定に応じて判断される。
【０１１２】
Ｓ１３０３にて、管理サーバ１０１は、セグメント情報それぞれの属性に基づいて、セグメントと間の類似度を導出する。ここでの類似度の導出方法は特に限定するものではないが、例えば、２つのセグメント間において、一致する属性の数の２つのセグメントが有する属性の種類数に対する割合や、一致する属性の数と一致しない属性の数とを重み付け加算した値として、算出してもよい。全てのセグメントの組み合わせに対する類似度を算出した後、管理サーバ１０１は、類似度が高い組み合わせの順にソートを行う。
【０１１３】
Ｓ１３０４にて、管理サーバ１０１は、ソートしたセグメントの組み合わせのうち、最も類似度が高い組み合わせの類似度が所定の閾値以上であるか否かを判定する。ここでの所定の閾値は、予め設定され、ＨＤＤ等の記憶領域に保持されているものとする。最も類似度の高いセグメントの組み合わせの類似度が所定の閾値以上である場合（Ｓ１３０４にてＹＥＳ）はＳ１３０５へ進み、閾値より小さい場合（Ｓ１３０４にてＮＯ）は本処理フローを終了する。
【０１１４】
Ｓ１３０５にて、管理サーバ１０１は、最も類似度が高いセグメント同士をマージする。ここでのマージとは、１のセグメントを新たに生成し、類似しているとされたセグメントに関連付けられた属性をその新たなセグメントに関連付けることにより行う。これにより、マージされたセグメントそれぞれに対応付けられた固有ポータルも１つに統合されることとなる。そして、類似しているとされたセグメントは削除する。なお、図４Ｃのテーブルにおいて、マージによって生成されたセグメントについては、その旨が分かるようなフラグを設けてもよい。また、マージ前のセグメント自体は削除せずに、マージ前のセグメントとしてその情報を管理してもよい。Ｓ１３０５のマージ処理が完了した後、Ｓ１３０３へ戻り、再度新たなセグメントを加えた組み合わせに対して類似度を算出する。
【０１１５】
以上、本実施形態により、類似するセグメントが増加した際に、管理サーバ側で類似のセグメントを自動的にマージすることができる。また、マージを行いたくない特定のセグメントについてもその状態を維持することができる。
【０１１６】
上記では、同じ店舗にて生成されたセグメントをマージする例を示したが、異なる店舗間で類似のセグメントをマージするようにしても構わない。
【０１１７】
＜第三の実施形態＞
本実施形態は、顧客ユーザへのイベントの通知方法について、第一の実施形態とは異なる例を示す。上記第一及び第二の実施形態で説明した固有ポータルには、特定の属性を有する顧客ユーザのみがアクセス可能であり、当該顧客ユーザは店舗が取り扱っている商品等に対して潜在的な需要を有している。しかし、店舗毎に見れば、全ての店舗が全ての顧客ユーザと取引実績があるわけではなく、店舗によっては未だ取引実績のない顧客ユーザが存在することも多分に想定される。そして、上記第一及び第二の実施形態ではそのような顧客ユーザと新たに取引実績を作ることを可能にする発明を説明した。その一方で、店舗によっては既に取引実績のある顧客ユーザ限定でイベント通知を行いたい場合も考えられる。そこで、本実施形態では、取引実績のある顧客ユーザを優先してイベント通知を行う方法を説明する。
【０１１８】
図１４は、本実施形態に係るイベントの通知の処理フローを示す。本処理フローは、管理サーバ１０１のＣＰＵがＨＤＤ等の記憶部に格納されたプログラムを読み出して実行することにより実現される。管理サーバ１０１側では、図３に示す顧客ユーザ管理部３０１、ＵＩ制御部３０４、顧客ユーザ認証部３０５、イベント管理部３０９、取引管理部３１０が機能することにより、本処理が行われる。図１４のＳ１４０１〜Ｓ１４０３は、第一の実施形態にて述べた図１０のＳ１００１〜Ｓ１００３と同様であるため、説明を省略する。
【０１１９】
Ｓ１４０３の後、Ｓ１４０４にて、管理サーバ１０１は、各種テーブルを参照し、ログインしている顧客ユーザが過去に購入手続きを行った店舗により登録されたイベントがあるか否かを判定する。具体的には、取引管理部３１０によって管理されている図４Ｅ、図４Ｆに示すテーブルが用いられる。購入履歴のある店舗により登録されたイベントがない場合（Ｓ１４０４にてＮＯ）Ｓ１４０６に進み、ある場合は（Ｓ１４０４にてＹＥＳ）Ｓ１４０５へ進む。
【０１２０】
Ｓ１４０５にて、管理サーバ１０１は、Ｓ１４０３にてアクセス許可された固有ポータルに顧客ユーザからアクセスされた際に、図４Ｅ、図４Ｆのテーブルに基づいて、該当するセグメントおよび店舗に対応するイベントを表示するように制御する。その後、本処理フローを終了する。
【０１２１】
以上、本実施形態により、顧客ユーザの過去の購入履歴に応じてイベントを通知するか否かを制御することができる。
【０１２２】
上記では、顧客ユーザごとに購入実績のある店舗のイベント通知のみが表示される場合を説明したが、発明の実施形態はこの通知方法に限定されない。例えば、図１１Ｆの店舗側がイベント登録をする際に、イベント通知をする対象を固有ポータルに参加する顧客ユーザ全員とするか、或いは、取引実績のある顧客ユーザのみに限定するかを設定可能とすることができる。これにより、固有ポータルにおいて通知されるイベントには、固有ポータルの参加者全員を通知対象者とするイベント（通常イベント）と、通知対象者を店舗と取引実績のある顧客ユーザに限定するイベント（限定イベント）との２種類が含まれることとなる。この場合、ある店舗Ａの通知する限定イベントについて、店舗Ａと取引実績のある顧客ユーザＡが固有ポータルにアクセスした際には表示されるが、店舗Ａと取引実績のない顧客ユーザＢが固有ポータルにアクセスしても表示されないこととなる。その一方、店舗Ａが通知する一般イベントは、顧客ユーザＡと顧客ユーザＢとのいずれが固有ポータルを訪問しても、そのたびに表示される。そして、顧客ユーザＡが固有ポータルを訪問した場合には、限定イベントと一般イベントとの両方が表示されることになり、その場合には限定イベントを一般イベントと識別可能に表示するようにしてもよい。例えば、限定イベントの通知を一群として限定イベントであることを示す表示（枠で囲む、或いは、限定イベントの旨を示す見出しを付与する等）を付与しても良い。あるいは、限定イベントの通知を一般イベントの通知よりも表示順序で優先するようにしてもよい。
【０１２３】
また、限定イベントは、図１１Ｆで設定される通知期間のうち、一部の期間のみとし、残りの期間は一般イベントに切り替えてもよい。例えば、通知期間を１週間とした場合、最初の２日間は限定イベントとして取引実績のある顧客ユーザのみを対象にイベント通知を行い、残りの５日間は一般イベントに切り替えて固有ポータルにアクセス可能な全顧客ユーザを通知対象とすることができる。
【０１２４】
以上のように、本実施形態によれば、店舗の固有ポータル内でのイベント通知を、当該店舗との取引実績の有無に応じて制御することが可能となり、顧客ユーザに対してイベント通知をより効果的に実施することができる。
【０１２５】
＜その他の実施形態＞
なお、上述した固有ポータルにおいて、セグメントに特化した機能を備えてもよい。例えば、固有ポータル上において、その固有ポータルに対応するセグメントに対して登録されたイベントや店舗のみを検索できる機能を備えてもよい。また、固有ポータル上でのみ利用可能なイベントが登録されてもよい。また、顧客ユーザが、セグメントに関連付けられた属性を有する商品から店舗を検索できるような構成であってもよい。
【０１２６】
また、顧客ユーザ側から所定の属性を有する店舗側に対し、固有ポータルを介してイベントの登録を要求するような構成であってもよい。更には、顧客ユーザ側から所定の属性を有するセグメントの登録が可能な構成であってもよい。
【０１２７】
本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。また本発明に係る情報処理装置は、１以上のコンピュータを該情報処理装置として機能させるプログラムによっても実現可能である。該プログラムは、コンピュータが読み取り可能な記録媒体に記録されることにより、あるいは電気通信回線を通じて、提供／配布することができる。
【要約】
複数の仮想店舗へのアクセスを提供するオンラインショッピングの第１のポータルサイトと、前記複数の仮想店舗のうち特定の属性を有する一部の仮想店舗へのアクセスを提供し、かつ、該特定の属性を有する第２のポータルサイトとを管理する管理サーバであって、前記複数の仮想店舗のうちのいずれかの仮想店舗から、前記第２のポータルサイトにおける該仮想店舗へのアクセス提供を求めるアクセス提供申請を受け付けると、前記アクセス提供申請を行った仮想店舗が前記特定の属性を有するか否かを判定し、前記特定の属性を有すると判定した場合、前記アクセス提供申請を行った仮想店舗の店舗情報を、前記第２のポータルサイトが該仮想店舗へのアクセスを提供することを示すように更新する。【図１】
0005848496.tif 000002
【図２】
0005848496.tif 000003
【図３】
0005848496.tif 000004
【図４Ａ】
0005848496.tif 000005
【図４Ｂ】
0005848496.tif 000006
【図４Ｃ】
0005848496.tif 000007
【図４Ｄ】
0005848496.tif 000008
【図４Ｅ】
0005848496.tif 000009
【図４Ｆ】
0005848496.tif 000010
【図５】
0005848496.tif 000011
【図６】
0005848496.tif 000012
【図７】
0005848496.tif 000013
【図８】
0005848496.tif 000014
【図９】
0005848496.tif 000015
【図１０】
0005848496.tif 000016
【図１１Ａ】
0005848496.tif 000017
【図１１Ｂ】
0005848496.tif 000018
【図１１Ｃ】
0005848496.tif 000019
【図１１Ｄ】
0005848496.tif 000020
【図１１Ｅ】
0005848496.tif 000021
【図１１Ｆ】
0005848496.tif 000022
【図１１Ｇ】
0005848496.tif 000023
【図１２】
0005848496.tif 000024
【図１３】
0005848496.tif 000025
【図１４】
0005848496.tif 000026