JP2007026156A

JP2007026156A - Ｗｅｂしおりを利用するマーケティングシステム

Info

Publication number: JP2007026156A
Application number: JP2005208276A
Authority: JP
Inventors: Hiroyuki Tamuki; 弘幸田向
Original assignee: Individual
Current assignee: Individual
Priority date: 2005-07-19
Filing date: 2005-07-19
Publication date: 2007-02-01
Anticipated expiration: 2025-07-19
Also published as: JP4831728B2

Abstract

【課題】インターネット上に開設したサイトにアクセスしてきた閲覧者に対し、個人情報の登録を要求することなく、閲覧者の趣味や興味に適合した広告情報を発信するマーケティングシステムを提供する。
【解決手段】画像データと、この画像にリンクする処理スクリプトからなるＷｅｂしおりを、サイトを構成する各Ｗｅｂページ毎に組み込み、このＷｅｂしおりに対して所定の操作をすることによって、該ＷｅｂページのＵＲＬとページＩＤあるいは該ページの属するカテゴリとがサイト閲覧者の端末に保存され、以後、このＷｅｂしおりをマウスクリックなどするだけで、直ちに該Ｗｅｂページを表示できるとともに、閲覧者の端末に保存されたページＩＤなどがサイト運営者のサーバに送信され、サーバは、受信したページＩＤなどにもとづき、閲覧者の現在の趣味や興味にマッチする広告情報を、閲覧者の端末に送信することを特徴とする。
【選択図】図１

Description

インターネット上に開設したサイトにアクセスしてきた閲覧者に対し、個人情報の登録を要求することなく、閲覧者の趣味や興味に適合した広告情報を発信するマーケティングシステムの提供に関する。

インターネット上に広告宣伝用のＷｅｂサイトを設け、マーケティングの手段として利用することが盛んに行われるようになってきている。インターネットを広告宣伝の手段と捉えた場合、広告のターゲットであるＷｅｂサイトの訪問者のサイト上での行動パターンや、サイトの閲覧回数などを集計する手法が公知となっていることから、広告宣伝の効果や影響の程度を把握することも容易になってきた。また、訪問者の個人情報の取得も比較的容易であることから、個々の訪問者に適した広告をタイムリーに発信することも可能である。このようなダイレクトマーケティングが可能であるということは、従来のテレビや新聞などを利用した不特定多数向けの広告に比べ、インターネットによる広告の利点といえる。
インターネットの広告媒体としての価値に着目して、インターネットや電子メールを活用したマーケティングの方法が、例えば、下記の特許文献１や特許文献２に記載の発明のように多数提案されている。

特開２００２−９２２８４号公報特開２００３−２８１１７７号公報

確かに、特許文献１や特許文献２に記載の発明は、個人の趣味などに適した広告を送信できる点で、効率のよいダイレクトマーケティングの手段ではある。しかし、これらの発明は、ユーザによる個人情報の登録を前提とする点で、問題がある。
すなわち、個人情報保護への意識が高まりをみせるなか、ユーザ、すなわち、サイトの閲覧者に個人情報を登録してもらうことは容易ではない。個人情報の収集が不十分であれば、たとえ、個別の消費者の趣味等と広告とをマッチングする手法等がすぐれていても、ダイレクトマーケティング手段としての有用性において劣る。
このような問題点を考慮して、本発明は、ユーザによる個人情報の登録を不要としつつ、適切なダイレクトマーケティングを可能とするシステムの提供を目的とする。

一方、インターネット上には、膨大な量のサイトが存在し、気に入ったページが見つかると、ＮｅｔｓｃａｐｅＮａｖｉｇａｔｏｒ（登録商標）でいうところのブックマークに追加、すなわち、特定のＷｅｂページのＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）の記録が行われる。
以下、この明細書で「ブックマーク」というときは、普通名詞の「ブックマーク」ではなく、ＮｅｔｓｃａｐｅＮａｖｉｇａｔｏｒの「ブックマーク」、あるいは、ＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒ（登録商標）の「お気に入り」の機能を意味する。
通常、ブックマークへは、気に入ったページが含まれるサイトの先頭ページのＵＲＬを保存することが多い。勿論、このブックマークには、同一サイト内の複数のページを入れることもできる。しかし、サイト先頭ページと、サイト内ページとが混在し、ブックマーク内の整理が煩雑となりがちである。また、気に入ったページをすべてブックマークに入れると、ブックマークのプルダウンリストの項目数が多くなり、見たいページを探すのが容易でなくなる。
したがって、本発明は、このようなブックマークの不便な点を解決することも目的とする。

このような目的を達成するために、本発明は、「Ｗｅｂしおり」という仕組みの提供を特徴とするものである。この「Ｗｅｂしおり」は、画像データと、この画像にリンクする処理スクリプトからなるＷｅｂしおりであって、Ｗｅｂサイトを構成する各Ｗｅｂページ毎に、コンテンツ要素の一つとして組み込まれ、選択状態あるいは非選択状態のいずれかの値をとり、非選択状態かつ前記画像が表示された状態において所定の操作がなされると、前記処理スクリプトは、値を選択状態に変えるとともに、該Ｗｅｂページが表示されている端末装置に接続する記憶装置の所定の場所に該ＷｅｂページのＵＲＬを保存し、選択状態かつ前記画像が表示された状態において所定の操作がなされると、前記処理スクリプトは、前記記憶装置の所定の場所から該ＷｅｂページのＵＲＬを取得し、前記ＷｅｂサイトのＷｅｂサーバに対し、該Ｗｅｂページデータの送信を要求することを特徴とする。

ここで、「値を選択状態に変える」とは、下記の実施形態でいう「しおりを挟む」ことに相当する。

このような構成をとることによって、多量のページを有するサイトであっても、そのサイトの訪問者は、サイト中の気に入ったページにＷｅｂしおりをすれば、次回からは、このＷｅｂしおりをマウスでクリック等するだけで、見たいページに直ちにジャンプできる。
ところで、Ｗｅｂしおりに対しマウス等を用いて特定する操作をすることは、システムに対し信号を送ることであり、本来は「ＷｅｂしおりをＯＮにする」といった表現が適切である。しかし、Ｗｅｂしおりは、紙で製本された本に挟む紙片（本物のしおり）と、イメージが共通することから、以下の説明では、「Ｗｅｂしおりを挟む」という表現を用いる。

なお、ブックマークと本発明のＷｅｂしおりを比較すると、以下の相違がある。
たとえば、運営サイトの先頭ページは、通常どおりブックマークに入れておく。ブックマークに入れるということは、気にいった本だけを、すぐに手に取れるように、手許のブックスタンドに置くことに相当する。これに対し、本発明のＷｅｂしおりは、一冊の本の気に入ったページにしおりを挟むことに相当する。
大規模なサイトは膨大な数のＷｅｂページを扱っている。この中には、気に入ったページが多数あり得る。その場合、気に入った個々のページをブックマークに入れるのでは、煩雑である。また、ブックマークでは、サイトへのアクセスと無関係にプルダウンリスト中に含まれてしまうが、本発明のＷｅｂしおりは、当該サイトにアクセスしているときのみ、画面上に表示されるだけである。
つまり、ブックマークと本発明のＷｅｂしおりとは、似て非なるものである。

上記の目的を達成するために、本発明のマーケティングシステムは、Ｗｅｂしおりを利用することを特徴とするとともに、インターネット上に開設されたＷｅｂサイトのホームページを提供するサイト運営者端末と、該Ｗｅｂサイト内のホームページを管理するＷｅｂページサーバと、該Ｗｅｂサイトのホームページに組み込まれたＷｅｂしおりに関連する情報を管理するシステム管理サーバと、該Ｗｅｂサイトにアクセスする閲覧者端末とを備え、前記サイト運営者端末は、任意個数のホームページの記述ファイルを、前記Ｗｅｂページサーバへアップロードするとともに、該ホームページにＷｅｂしおりがコンテンツ要素として組み込まれていれば、前記システム管理サーバに該ホームページを識別するページＩＤと、このページに付与されたカテゴリ情報並びにＵＲＬと、ダイレクトマーケティング用の広告ページのＵＲＬを送信し、前記システム管理サーバは、前記サイト運営者端末から受信したカテゴリ情報と該ホームページのＵＲＬと広告ページのＵＲＬを、ページＩＤに対応付けて記憶する一方、前記閲覧者端末は、入力部と画面表示部と記憶部を備え、前記Ｗｅｂページサーバから、ホームページの記述ファイルを受信すると、前記画面表示部に対し、前記Ｗｅｂしおりを含む該ホームページを表示させ、前記入力部を介して該Ｗｅｂしおりを選択・指示する所定の操作がなされると、前記処理スクリプトを実行させることにより、該ホームページのページＩＤとＵＲＬとを対にして前記記憶部に保存させるとともに、前記記憶部に１以上のページＩＤがすでに保存されているときは、所定のタイミングのもと、前記システム管理サーバに対し、前記の保存されているページＩＤを送信し、前記システム管理サーバは、前記閲覧者端末から受信したページＩＤに対応づけられた前記カテゴリ情報と共通性を有するホームページ並びに広告ページのＵＲＬを抽出し、抽出したＵＲＬを含む広告記述ファイルを生成し、前記閲覧者端末に送信することを特徴とする。

ここで、「ホームページ」とは、当該運営サイトにアクセスする閲覧者に公開されている通常のＷｅｂページのことをいう。一方、「広告ページ」とは、本発明のマーケティングシステム側がふさわしいと判断した閲覧者に対し、最新情報などの提供を目的として送信するための特別のＷｅｂページをいう。
「記述ファイル」とは、ＷｅｂページのコンテンツをＨＴＭＬなどで記述したデータファイルをいう。なお、Ｗｅｂページを記述する言語の種類は複数あるが、これらの言語の代名詞的に、以下、「ＨＴＭＬ」と表現する。
「カテゴリ情報」とは、Ｗｅｂページを分類するための情報であり、大カテゴリ、中カテゴリ、小カテゴリのように、階層化されていてもよい。下記の実施形態では、カテゴリ、サブカテゴリ、属性がカテゴリ情報に該当する。
「広告記述ファイル」とは、上述した「記述ファイル」の特別のものであって、それ自身がＷｅｂページを記述したデータファイルであり、Ｗｅｂしおりを選択した閲覧者にマッチするＷｅｂページ（ホームページと広告ページのいずれも含む）のＵＲＬの一覧表等をコンテンツとする。

このような構成をとることによって、閲覧者によるＷｅｂしおりの選択・指示という操作を介して、サイト側は当該閲覧者の趣味や興味に適合したページのページＩＤを把握できる。サイト側は、このページＩＤをインデックスキーとしてデータベースを参照し、当該ページと共通性がある他のページを抽出し、そのページのＵＲＬを含む広告宣伝用ページを生成する。このような広告宣伝用ページを当該閲覧者に送信することにより、効果的なダイレクトマーケティングが実現できる。なお、サイト側では、ページＩＤさえ把握できれば、目的を達成でき、閲覧者に関する個人情報を収集する必要はない。

また、本発明のマーケティングシステムは、インターネット上に開設されたＷｅｂサイトのホームページを提供するサイト運営者端末と、該Ｗｅｂサイト内のホームページを管理するＷｅｂページサーバと、該Ｗｅｂサイトの広告ページに関連する情報を管理するシステム管理サーバと、該Ｗｅｂサイトにアクセスする閲覧者端末とを備え、前記サイト運営者端末は、任意個数のホームページの記述ファイルを、前記Ｗｅｂページサーバへアップロードするとともに、Ｗｅｂしおりを利用するホームページの記述ファイルには、Ｗｅｂしおりをコンテンツ要素として組み込み、かつ、カテゴリ情報を記述する一方、前記閲覧者端末は、入力部と画面表示部と記憶部を備え、前記Ｗｅｂページサーバから、ホームページの記述ファイルを受信すると、前記画面表示部に対し、前記Ｗｅｂしおりを含む該ホームページを表示させ、前記入力部によって該Ｗｅｂしおりを選択・指示する所定の操作がなされると、前記記憶部に対し、該ホームページの前記カテゴリ情報とＵＲＬとを対にして保存させるとともに、前記記憶部に１以上のカテゴリ情報がすでに保存されているときは、所定のタイミングのもと、カテゴリ情報を集計し、前記システム管理サーバに対し、このカテゴリ集計結果を送信し、前記システム管理サーバは、前記閲覧者端末から集計結果を受信すると、集計されたカテゴリ情報と共通性を有するホームページ並びに広告ページを抽出し、抽出したページのＵＲＬを含む広告記述ファイルを生成し、前記閲覧者端末に送信することを特徴とするものでもよい。

このような構成をとることによって、閲覧者側が、趣味や興味に適合するカテゴリ等を集計し、その集計結果をサイト側に提供する。サイト側では、自ら管理する広告ページあるいはホームページの中から、類似のカテゴリを持つものをピックアップして、そのＵＲＬを含む広告宣伝用のページを当該閲覧者のために生成して送信する。

請求項１に記載の発明によれば、多量のページを有するサイトであっても、Ｗｅｂしおりを利用すれば、次回から、このＷｅｂしおりをクリック等するだけで、見たいページに直ちにジャンプできる。また、サイト側にとっても、訪問者に対し、Ｗｅｂしおりという機能を提供することで、この機能を持たないサイトに比べ、使い勝手がよく、他のサイトとの差別化をはかることができる。

また、Ｗｅｂしおりの利便性は、営利目的のサイトに限らない。自治体や学校・病院などの非営利機関も、最近では情報発信のためのサイトを設けることが多くなってきている。新しい情報を提供し続けると、ページ数も増加していく。Ｗｅｂしおり機能を組み込むならば、閲覧者にとって便利なことこのうえない。

請求項２、３に記載の発明によれば、Ｗｅｂサイトの運営者側は、閲覧者に個人情報の登録を一切要求していない。これは、個人情報保護という時代の要請に合致するものである。
それにとどまらず、運営者側は閲覧者に関する登録情報をデータベースに持つ必要がないので、データベースの管理に伴うコストが軽減される。
また、個人情報をデータベースに登録する場合を考えると、頻繁に更新しない限り、データベースの情報は陳腐化し固定化しがちである。ダイレクトマーケティングを効果的に行うには、本質的に移り気な消費者（＝閲覧者）が現在関心を持っている趣味や興味に柔軟に対応していくことが大事である。

本発明によれば、消費者の趣味や興味の把握が容易である。閲覧者側から送信されてくるページＩＤあるいはカテゴリ集計結果は、閲覧者が現在関心を持っているホームページに関するものであると推定できる。そのため、現在の閲覧者の趣味や興味を的確に吸い上げることができ、それにマッチした広告を提供することが可能になる。

ところで、サイト内の閲覧者の行動を吸い上げ、これをマーケティングに活かそうとすることが行われている。しかし、必ずしも、あるページを閲覧したからといって、その閲覧者が、そのページに興味をもっているとは限らない。
これに対し、本発明では、たとえ閲覧しても、そのページに興味がなければＷｅｂしおりを挟むことはない。Ｗｅｂしおりを挟むという意思的な動作が介在することによって、Ｗｅｂしおりを挟んだページに閲覧者が興味を持っていることを、高い精度で推定できる。

本発明のマーケティングシステムは、個人情報に依存しないことから、個人情報保護の時流に合致するとともに、Ｗｅｂしおりを利用し、個々の閲覧者に照準を合わせた広告の提供をすることから、移り気な消費者の現在の趣味や興味に即応できるものである。

（第１の実施の形態）
以下、本発明の第１の実施形態のシステムについて説明する。
本システムの構成例を、図１に示す。

サイト運営者端末１と閲覧者端末４は、インターネットＮを介して、それぞれＷｅｂページサーバ２及びシステム管理サーバ３と接続している。
このシステムは、多数の店舗がテナントとして入っている大型商業ビルなどが、Ｗｅｂサイト運営者となって、そのテナントのためにサイトをインターネット上に開設し、各店舗の紹介をするホームページなどを掲載する場合を想定している。
サイト運営者が、ホームページや広告ページを作成し、Ｗｅｂサイトのサーバに対し、アップロードする際に使用するコンピュータを、サイト運営者端末１と呼ぶ。図１では、サイト運営者端末１は１台しか記載していないが、台数に制限は設けない。１人のサイト運営者が、複数の端末を所有することもあるし、サイト運営者が複数いることもありうるからである。

サイト運営者端末１から送信されるホームページを管理するのが、Ｗｅｂページサーバ２であり、これは、通常のものである。Ｗｅｂページサーバ２は、各ホームページを記述したファイルを自ら格納していてもよいし、他のデータベースサーバ（図示せず）に格納してもよい。

システム管理サーバ３とは、本発明の大きな特徴の一つである「Ｗｅｂしおり」に関する情報の管理およびダイレクトマーケティングの実行、すなわち個別の閲覧者に適した広告の発信を担当するサーバである。以下、システム管理サーバ３を、その主たる役割、すなわち、「Ｗｅｂしおり」の機能の実装に着目して「Ｗｅｂしおりサーバ３」と呼ぶことにする。Ｗｅｂしおりサーバ３は、Ｗｅｂしおりに関する情報を格納するＷｅｂしおりデータベース５（以下、「ＷｅｂしおりＤＢ５」）と接続している。なお、ＷｅｂしおりＤＢ５は、Ｗｅｂしおりサーバ３の内蔵あるいは外付けの記憶装置でも、別のコンピュータでも、いずれで実現してもよい。

なお、Ｗｅｂページサーバ２とＷｅｂしおりサーバ３は、いずれも同一のサイト運営者によって管理される。したがって、Ｗｅｂページサーバ２とＷｅｂしおりサーバ３を同一のコンピュータで構成してもよい。

運営サイト上のホームページは、不特定多数の人々に公開されている。この運営サイトにインターネットＮを介してアクセスする人を閲覧者と呼び、閲覧者のコンピュータを閲覧者端末４と呼ぶことにする。図１では、閲覧者端末４は１台しか記載していないが、台数に制限は設けない。
閲覧者端末４は、適宜、マウスやキーボードなどの入力部６、画面表示部７およびハードディスクなどの記憶部８を備える。なお、閲覧者端末４は、コンピュータに限らず、携帯電話やＰＤＡなどでもよい。

サイト運営者端末１も閲覧者端末４もサーバ２，３にアクセスする場合、通常、インターネットのＷｅｂサービスを利用する。そのため、サイト運営者端末１も閲覧者端末４も、Ｗｅｂページを閲覧するためのソフトウェアであるＷｅｂブラウザがインストールされていることを前提とする。Ｗｅｂブラウザとしては、Ｉｎｔｅｒｎｅｔ
ＥｘｐｌｏｒｅｒまたはＮｅｔｓｃａｐｅＮａｖｉｇａｔｏｒが代表的であるが、なんでもよい。

ただし、Ｗｅｂブラウザは、マウスボタンの押下やキー入力などのイベント発生時の処理や、簡単な演算などを行うスクリプト言語をサポートしているものとする。このようなスクリプト言語も複数種類あるが、ＪａｖａＳｃｒｉｐｔ
（登録商標）が代表的なので、以下の説明では、このようなスクリプト言語の代名詞としてＪａｖａＳｃｒｉｐｔと表現する。

さらに、Ｗｅｂページの内容であるコンテンツを作成するためのソフトとして、ＭａｃｒｏｍｅｄｉａＦｌａｓｈ（登録商標）がインストールされていることを前提とする。ＭａｃｒｏｍｅｄｉａＦｌａｓｈ（以下「Ｆｌａｓｈ」）がこのようなソフトの事実上の標準となりつつありＷｉｎｄｏｗｓ（登録商標）やＭａｃｉｎｔｏｓｈ（登録商標）のような代表的なＯＳ上で実行可能だからである。

ただし、これは現時点での入手のしやすさなどの実装レベルを考慮したものであり、本発明は、これらの特定のソフトウェアやスクリプト言語などに限定されるものではない。例えば、Ｃ言語などで、Ｗｅｂしおりの機能を実現することができることは言うまでもない。

本実施形態のシステムは、サイトにアクセスする閲覧者に対する利便性と、サイトの運営者に対するマーケティングツールの提供に主眼がある。しかし、本実施形態が、その本来の目的を達成するためには、事前にホームページおよび広告ページのアップロードと、Ｗｅｂしおりに関連した情報の登録とを必要とする。
したがって、以下に、本システムの運用にあたり必要となる事前準備について説明する。

図２の処理フローに従い、サイト運営者端末１を主体として、どのように事前準備が行われるかを説明する。
サイト運営者端末１は、Ｗｅｂしおりサーバ３にＨＴＴＰリクエストを送信する（Ｓ１）。Ｗｅｂしおりサーバ３からログイン画面（図示せず）が送信（Ｓ２）されると，ユーザＩＤやパスワードなどの認証情報をＷｅｂしおりサーバ３に送信する（Ｓ３）。なお、認証情報として、生体情報等を用いてもよい。
もし、Ｗｅｂしおりサーバ３による認証に失敗したならば（Ｓ４でＮｏ）、Ｗｅｂしおりサーバ３から受信したエラー画面を表示し（Ｓ５）、処理を終了するか、再度ＨＴＴＰリクエストを送信する（Ｓ１）。

Ｗｅｂしおりサーバ３による認証に成功したならば（Ｓ４でＹｅｓ），サイト運営者端末１は、Ｗｅｂしおりサーバ３に対してカテゴリ設定画面を要求し（Ｓ６）、Ｗｅｂしおりサーバ３から送信（Ｓ７）された画面上で、カテゴリの新規追加、削除、編集などのカテゴリ設定のための処理を行う（Ｓ８）。この設定情報はＷｅｂしおりサーバ３に送信され、Ｗｅｂしおりサーバ３はＷｅｂしおりＤＢ５に登録をする（Ｓ９）。サイト運営者端末１は、カテゴリ設定処理を必要とする間（Ｓ１０でＹｅｓ）、Ｗｅｂしおりサーバ３に設定画面を要求し（Ｓ６）、設定処理を繰り返す。

ここで、ステップＳ８の処理内容を、図３および図４のカテゴリ設定画面例を用いて説明する。
カテゴリを追加するときは、図３の画面のテキスト入力フィールドＴｘｔ１に、カテゴリ名を入力し、追加ボタンＢｔｎ１をクリックする。ボタンＢｔｎ１のクリックというイベントによって、サイト運営者端末１から追加情報がＷｅｂしおりサーバ３に送られ、Ｗｅｂしおりサーバ３側のＣＧＩがステップＳ９の登録処理を行うことになる。このようなイベント発生を介した端末（クライアント）とサーバ間の処理は公知なので、詳細は省略し、以下の説明では、単に、ボタンをクリック等という表現をする。

いったん設定したカテゴリを削除したり編集したりするときは、図３の一覧表示ボタンＢｔｎ２をクリックし、図４の画面を表示させる。例えば、“カテゴリ１”を編集したいときは、編集ボタンＢｔｎ３をクリックし、編集用画面（図示せず）を表示させて、この画面上でカテゴリ名の修正やコメントの追加などのカテゴリ編集を行う。“カテゴリ２”を削除したいときは、削除ボタンＢｔｎ４をクリックすれば、削除情報がＷｅｂしおりサーバ３に送信されるので、ＷｅｂしおりＤＢ５から“カテゴリ２”は削除される。
なお、サブカテゴリや属性の追加・削除等も、上記のカテゴリの場合と同様なので、図示および説明は省略する。

ここで、カテゴリ等の分類の一例を図５に示す。図５のように、ツリー構造にすると、分類や追加削除が容易であり、検索やソートなどのコンピュータプログラムのアルゴリズムとの相性がよい。
ただし、これは例にすぎず、その運営サイトの目的や管理者の方針などによって自由に設定されるものである。
また、属性は、１つのカテゴリ、あるいはサブカテゴリに任意個数対応しうる。そのため、ビット列で表現するとよい。例えば、属性がＮ個ある場合、各属性に該当するか否かを１か０で表現すれば、Ｎ個のビット列で表現できる。このようにすれば、ＷｅｂしおりＤＢ５において、ページ毎に１個の属性欄を設ければ足り、Ｎ個の欄を設ける必要はない。

再び、図２のフローに戻って、事前準備の説明を続ける。
カテゴリ等の登録が済むと、次に、Ｗｅｂしおりの機能を利用する準備としてのＷｅｂしおり情報設定処理を行う。
サイト運営者端末１が、Ｗｅｂしおりサーバ３にＷｅｂしおり情報設定画面を要求する（Ｓ１１）と、Ｗｅｂしおりサーバ３から、図６に示すような設定画面が送信されてくる（Ｓ１２）。
このＷｅｂしおり情報設定画面上で、サイト運営者端末１は、Ｗｅｂページサーバ２にアップロードし、かつ、Ｗｅｂしおり機能を利用しようとするホームページについて、そのＵＲＬとカテゴリ、サブカテゴリ、属性を入力し、追加ボタンＢｔｎ５をクリックすることによって、入力内容をＷｅｂしおりサーバ３側に送信する（Ｓ１３）。ここで、カテゴリ名などは、すでにＷｅｂしおりサーバ３によってＷｅｂしおりＤＢ５に登録済みのものから選択する。Ｗｅｂしおりサーバ３は、受信した情報をＷｅｂしおりＤＢ５に登録する（Ｓ１４）。ここまでの処理によって、各店舗の紹介などを行うホームページとＷｅｂしおりとのリンクの準備ができたことになる。

ＷｅｂしおりＤＢ５に登録された内容を確認したいときは、図６の画面の一覧表示ボタンＢｔｎ６をクリックし、図７に示すＷｅｂしおり情報が設定されているホームページの一覧画面を表示させればよい。図７の各行のＵＲＬ、カテゴリ名、サブカテゴリ名及び属性は、ＷｅｂしおりＤＢ５に格納された１個のレコードに対応する。このＷｅｂしおりＤＢ５のレコードを参照するためのキーがページＩＤである。ページＩＤは当該運営サイトがＷｅｂページサーバ２で管理するホームページを一意に特定するものであり、後に詳しく説明するように、本発明のＷｅｂしおり機能にとって重要な意義を有する。

次に、広告ページの設定処理を行う。ここで設定される広告ページは、ステップＳ１３でしおり情報を設定したホームページに対応する店舗等の広告に関するものである。したがって、この広告ページと該ホームページは、同一のカテゴリ情報を持つ。サイト運営者端末１がＷｅｂしおりサーバ３に広告ページ設定画面の送信を要求する（Ｓ１５）と、Ｗｅｂしおりサーバ３は、図８に例示するような広告ページ設定画面を送信してくる（Ｓ１６）。サイト運営者端末１は、テキスト入力フィールドＴｘｔ２にＵＲＬを入力し、登録ボタンＢｔｎ７のクリックによって、Ｗｅｂしおりサーバ３に、この広告ページのＵＲＬを登録する（Ｓ１７）。この広告ページに付与するコメントなども適宜設定する。このコメントは、後に説明するように、閲覧者に送信するポップアップ広告（図１８参照）で使用するものである。
広告ページの表示に条件を設けたいときは、図示しない画面を介して表示条件等を設定し、Ｗｅｂしおりサーバ３に送信する（Ｓ１８）。Ｗｅｂしおりサーバ３は、受信した表示条件等を登録する（Ｓ１９）。表示条件としては、例えば、この広告ページの表示有効期限などがある。
上記の一連の処理により、ホームページに組み込むしおり機能の実現のために必要なデータは、ＷｅｂしおりＤＢ５に登録される。なお、広告ページのデータ本体の格納場所は、ＷｅｂしおりＤＢ５でも、Ｗｅｂページサーバ２でも、各店舗のコンピュータでも、どこであってもよい。

次に、ホームページを記述したファイルの例を図９に示す。図９は、閲覧者端末４のＷｅｂブラウザによって読み込まれ、画面表示部７に表示されるＨＴＭＬファイルを示したものである。ただし、本実施形態の説明に直接関係しない部分は省略してある。
行Ｌ１は、ＪａｖａＳｃｒｉｐｔで書かれたファイルｓｈｉｏｒｉ＿ｆｕｎｃｔｉｏｎ．ｊｓを参照すべきことを指示し、行Ｌ２は、このファイルに記述されているＪａｖａＳｃｒｉｐｔのファンクションｓｈｉｏｒｉ＿ｗｒｉｔｅ（）を、ページＩＤである０００１を入力引数として引用することを指示するものである。

図１０は、ファイルｓｈｉｏｒｉ＿ｆｕｎｃｔｉｏｎ．ｊｓの内容のうち、本実施形態の説明に必要な箇所を抜粋したものである。
行Ｌ３は、ＦｌａｓｈのデータをＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒで再生することを指示する。Ｌ４からＬ７は、ｓｈｉｏｒｉ．ｓｗｆを再生し、ページＩＤ（ｐｉｄ＝０００１）とカレントのＵＲＬをパラメータとすることを指示するものである。行Ｌ８は、ＮｅｔｓｃａｐｅＮａｖｉｇａｔｏｒの利用者が再生できるようにするものである。
つまり、行Ｌ４に記載されているファイルｓｈｉｏｒｉ．ｓｗｆがＷｅｂしおりの実体であり、Ｗｅｂしおりの画像とこれにリンクするスクリプトを保持するものである。
なお、図７に例示する画面では、スクリプト欄の表示ボタンをクリックすれば、これらのスクリプトの内容を表示できる。

ところで、図９に示すようなＨＴＭＬファイルは、ページ毎に異なるのは当然であるが、ｓｈｉｏｒｉ．ｓｗｆを再生し、Ｗｅｂしおりの機能を起動するための関数を記述したｓｈｉｏｒｉ＿ｆｕｎｃｔｉｏｎ．ｊｓはすべてのＨＴＭＬファイルにおいて参照される。ただし、ＨＴＭＬファイル側で行Ｌ２のページＩＤの値をそれぞれ変えなくてはならないことは言うまでもない。

以上のサーバ２，３への事前登録が済めば、閲覧者による閲覧が可能な状態となる。
次に、閲覧者端末４を主体とする処理の流れを説明する。
まず、閲覧者端末４がこの運営サイトに最初に訪問した場合を図１１のフローに従い説明する。
閲覧者端末４がＷｅｂページサーバ２に対し、ホームページ（通常は、サイトの先頭ページ）の閲覧を要求（Ｓ１０１）すると、Ｗｅｂページサーバ２がＨＴＭＬ形式のファイルを閲覧者端末４に送信する（Ｓ１０２）ので、閲覧者端末４のＷｅｂブラウザは、画面表示部７にこれを表示する。

このＨＴＭＬファイルにはＷｅｂしおり機能を組み込んだものと組み込んでいないものとがある。Ｗｅｂしおり機能を組み込んだものとは、例えば、図９の行Ｌ２のようなスクリプトが記述されているＨＴＭＬファイルのことである。
Ｗｅｂしおり機能が組み込まれていなければ（Ｓ１０３でＮｏ）、閲覧を終了する（Ｓ１０６でＹｅｓ）か、同じサイトの別ページの閲覧を要求する（Ｓ１０６でＮｏ，Ｓ１０１）。
もし、Ｗｅｂしおり機能が組み込まれていれば（Ｓ１０３でＹｅｓ）、画面表示部７にＷｅｂしおりの画像が表示される。Ｗｅｂしおりを画面に表示する仕方はタブ形式、プルダウン形式など、いろいろ考えられるが、どのような形式でもよい。図１２は、Ｗｅｂしおり表示の一例を示したものである。図１２のブラウザ画面ＳＣＲＮ１の右端にある矩形領域ＡＲ１は、Ｆｌａｓｈで作成されたＷｅｂしおり画像のための領域である。このＷｅｂしおり画像には、閲覧者端末４の入力部６を介した各種のイベント（マウスのクリック、ダブルクリックなど）と予め対応させた処理（しおりを挟む、しおりをとる、しおりから好みのページにジャンプするなど）を記述したスクリプトがリンクしている。

表示されたＷｅｂしおりに対して、マウスクリック等の所定の操作をする（Ｓ１０４でＹｅｓ）と、Ｗｅｂしおりにリンクされた処理スクリプトは、図１０の行Ｌ４〜Ｌ７に記述されているように、パラメータとして与えられたページＩＤとＵＲＬとを閲覧者端末４の記憶部８の所定の場所に格納する（Ｓ１０５）。このとき、例えば、画面のＷｅｂしおり表示は、図１３の左側から右側に示すように変化し、Ｗｅｂしおりが挟まれたことが一目でわかる。他のページの閲覧をするとき（Ｓ１０６でＮｏ）は、再びステップＳ１０１に戻る。
なお、ページＩＤなどのパラメータの保存は、ＦｌａｓｈではＳｈａｒｅｄＯｂｊｅｃｔオブジェクトを利用する。ＳｈａｒｅｄＯｂｊｅｃｔに保存されるデータは、バイナリデータの形式をとり、Ｆｌａｓｈによってのみ値の読み出しができる。このように、機能が限定されている点は、個人情報保護の要請に合致する。

閲覧者端末４の記憶部８の所定の場所に保存されるデータの構造を図１４に例示する。
Ｗｅｂしおりが挟まれたページのＵＲＬは閲覧者端末４側に保存されているので、図１５のように、他のページを表示中であっても、Ｗｅｂしおり表示領域ＡＲ１に表示されているＷｅｂしおりｍｋ１をクリックするだけで、そのＷｅｂしおりに対応づけられたページへただちにジャンプできる。
また、選択中のＷｅｂしおりを削除する処理を記述したスクリプトをＦｌａｓｈによるしおり画像にリンクさせておくこともできる。所定のイベントによってこの削除のためのスクリプトを実行させれば、画面上のしおり表示が消えるとともに、記憶部８からも削除される。
このように、閲覧者端末４は、Ｗｅｂしおりを挟んだり、Ｗｅｂしおりを取り除いたりが簡単な操作によってできる。

次に、閲覧者端末４がこの運営サイトに２回目以降に訪問した場合を図１６に従い説明する。
なお、閲覧者は、すでに１以上のＷｅｂしおりを挟んでいることを前提に説明する。

閲覧者端末４は、当該サイトにホームページの閲覧要求をする（Ｓ２０１）。Ｗｅｂページサーバ２はＨＴＭＬファイルを送信し（Ｓ２０２）、閲覧者端末４のＷｅｂブラウザは、受信したＨＴＭＬファイルを表示する。サイトへアクセスした直後のページは、通常、このサイトの先頭ページである。
受信したＨＴＭＬファイルに組み込まれているＷｅｂしおり機能により、ブラウザの画面の右端にはしおり画像が表示される（図１５参照）とともに、この画像とリンクされている各種処理スクリプトが実行可能な状態になる。

次に、閲覧者端末４はＷｅｂしおりサーバ３側へのＷｅｂしおり情報送信時間の経過の有無をチェックする（Ｓ２０３）。一日に何回も同じサイトを訪問する人もいるので、必ずしも訪問の都度、Ｗｅｂしおり情報をＷｅｂしおりサーバ３に送らなくてもよい。そのため、Ｗｅｂしおりサーバ３側へＷｅｂしおり情報を送信する時間間隔を予め設定しておく。このような時間コントロールの手法は、広く行われていることなので詳細は略する。
前回のサイト訪問から所定の時間が経過しているとき（Ｓ２０３でＮｏ）は、ＦｌａｓｈはＬｏａｄＶａｒｓオブジェクト等のメソッドによってＳｈａｒｅｄＯｂｊｅｃｔに保存しておいたページＩＤを取り出し、Ｗｅｂしおりサーバ３へ送信する（Ｓ２０４）。

Ｗｅｂしおりサーバ３はページＩＤを受信する（Ｓ２０５）と、カテゴリ集計処理を行う（Ｓ２０６）。これは、送信されてきたページＩＤをインデックスキーとしてＷｅｂしおりＤＢ５からカテゴリ情報、サブカテゴリ情報、属性情報を読み込み集計し、この集計結果に基づいて、同じカテゴリ、サブカテゴリ、あるいは属性等を有する広告ページをＡＮＤ検索あるいはＯＲ検索などで抽出する。このようにして抽出された広告ページは、当該閲覧者の趣味等にマッチすると考えられる。趣味等にマッチする広告がなければ（Ｓ２０７で“無”）、その旨の情報を送信する（Ｓ２０９）。マッチする広告が見つかれば（Ｓ２０７で“有”）、その広告ページのＵＲＬを含む広告記述ファイルを閲覧者端末４に送信する（Ｓ２０８）。この広告記述ファイルはＨＴＭＬやＦｌａｓｈ等で記述されており、Ｗｅｂブラウザによって、閲覧者端末４に“新着情報”として表示される。この“新着情報”には、主に広告ページへのリンクが掲載される。しかし、広告ページに限らず、ホームページであってもよい。閲覧者が、Ｗｅｂしおりを挟んでいないホームページであっても、現在の閲覧者の趣味や興味にマッチし、しかも、閲覧者がそのホームページの存在に気づいていないこともありうる。したがって、広告ページだけでなく、他のホームページへのリンクを掲載することも考慮すべきである。
なお、カテゴリなどの集計結果をもとに、どのような情報を発信するか、つまりダイレクトマーケティングの手法は、公知のものがあるので、ここでは説明を省略する。

Ｗｅｂしおりサーバ３からの送信を受けると（Ｓ２１０）、閲覧者端末４は、送信された情報に何らかの広告ページあるいはホームページのＵＲＬが含まれている場合（Ｓ２１１でＹｅｓ）は、しおり領域ＡＲ１に図１７に例示するような“新着情報”の表示ｍｋ２をする。この表示ｍｋ２もＦｌａｓｈによるＷｅｂしおり画像にリンクされている処理スクリプトによって行われることは言うまでもない。

この“新着情報”表示をクリックすると、図１８のようなポップアップウィンドウの表示をする（Ｓ２１２）。これは、Ｗｅｂブラウザ画面上に、該当する広告ページのＵＲＬとリンクした広告の文言を表示するものであり、下線付きの文言をマウスクリックすると（Ｓ２１３でＹｅｓ）、Ｗｅｂブラウザは別ウィンドウをオープンし、ここに該当するＵＲＬをもつ広告ページを表示する（Ｓ２１４）。
このような新着情報を含む当該サイトのページを閲覧し、その閲覧したページがＷｅｂしおり機能を組み込まれたものであった場合（Ｓ２１５でＹｅｓ）、Ｗｅｂしおりを挟むならば（Ｓ２１６でＹｅｓ）、記憶部８の所定の場所にそのページのページＩＤとＵＲＬとが保存される（Ｓ２１７）。つまり、そのページにＷｅｂしおりを挟んだことになる。ユーザは、Ｗｅｂしおりを挟めば、次回から、このＷｅｂしおりをクリック等するだけで、見たいページに直ちにジャンプできる。
なお、“新着情報”表示は、ポップアップ形式に限らず、Ｆｌａｓｈが提供するフローティングウィンドウの機能などによってもよい。

また、Ｆｌａｓｈの処理スクリプトにＷｅｂしおりを外す処理を記述しておくならば、いったんＷｅｂしおりを挟んでも簡単にとることができる。そのため、閲覧者端末４は、もはや関心の無いページからＷｅｂしおりをとることにより、不要なＷｅｂしおりが蓄積することを防止できる。

ところで、本実施形態では、データベースにＷｅｂしおり関連情報、つまり、ホームページ及び広告ページに関するカテゴリ情報やＵＲＬ等を登録しなければならないが、閲覧者の個人情報に比べれば、その規模が小さいので、頻繁な更新による負担も大きなものではない。
つまり、本実施形態のように個人情報の登録が不要であるということは、閲覧者だけではなく、運営者にとってもメリットのあることである。

（第２の実施の形態）
前記の第１の実施形態では、閲覧者にとって関心のあるカテゴリ等の集計処理を、Ｗｅｂしおりサーバ３が担当していた。
この第２の実施形態では、カテゴリ等の集計処理を、閲覧者端末４が担当する点で第１の実施形態と相違する。以下に、第１の実施形態と相違する点を中心に説明する。共通な点は、説明を省略するか、あるいは、ごく簡単な説明にとどめる。

この実施の形態のシステム構成は、図１に示す第１の実施の形態と同様である。

このシステムの運用開始前の事前準備に伴う処理を、図１９に示す。
第１の実施形態との相違は、次の２点である。まず、図１９からわかるとおり、図２のステップＳ１１からステップＳ１４までのＷｅｂしおり情報を、ＷｅｂしおりＤＢ５に登録する処理が省略されている。また、ステップＳ１７において、広告ページのＵＲＬを登録する際に、あわせて、対応するカテゴリ情報も登録する点が相違する。
なお、本実施形態では、Ｗｅｂしおり関連情報は、閲覧者端末４側に持たせることになる。この点は、後で説明する。

このようにＷｅｂしおり関連情報の登録サイドが異なることから、Ｗｅｂページサーバ２にアップロードするＨＴＭＬファイルの記述が、図２０に示すように、一部相違する。
つまり、サイト運営者端末１は、カテゴリ等をＷｅｂしおりＤＢ５に登録するかわりに、ページを記述したＨＴＭＬファイルに、カテゴリ等を関数の引数として記述することになる。
第１の実施形態では、Ｗｅｂしおり画像を再生する関数の引数は、ページＩＤ（図９の行Ｌ２を参照）だけであったが、本実施形態では、カテゴリＩＤ，サブカテゴリＩＤおよび属性を引数とする（図２０の行Ｌ２‘）。これに対応して、ＪａｖａＳｃｒｉｐｔの記述も一部相違する（図２１の行Ｌ１１〜Ｌ１７を参照）。

Ｗｅｂしおり機能を組み込んだホームページのアップロードが済めば、閲覧者端末４による閲覧が可能な状態となる。
以下、閲覧者端末４を主体とする処理の流れを説明する。
まず、閲覧者端末４がこの運営サイトに最初に訪問した場合を、図２２に従い説明する。
閲覧者端末４がＷｅｂページサーバ２に対し、ホームページ（たいていサイトの先頭ページ）の閲覧を要求（Ｓ３０１）すると、Ｗｅｂページサーバ２がＨＴＭＬ形式のファイルを閲覧者端末４に送信する（Ｓ３０２）ので、閲覧者端末４のＷｅｂブラウザは、これを表示する。

このＨＴＭＬファイルに、Ｗｅｂしおり機能が組み込まれていなければ（Ｓ３０３でＮｏ）、閲覧を終了する（Ｓ３０６でＹｅｓ）か、同じサイトの別のページの閲覧を要求する（Ｓ３０６でＮｏ，Ｓ３０１）。
もし、Ｗｅｂしおり機能が組み込まれていれば（Ｓ３０３でＹｅｓ）、画面にＷｅｂしおりの画像が表示される。表示の仕方（例えば、図１２参照）は、第１の実施形態と同様である。

表示されたＷｅｂしおりに対して、クリック等の所定の操作をする（Ｓ３０４でＹｅｓ）と、Ｆｌａｓｈは、図２０の行Ｌ１２〜Ｌ１７に記述されているように、パラメータとして与えられたカテゴリＩＤ、サブカテゴリＩＤ、属性およびカレントのＵＲＬとを、ＦｌａｓｈのＳｈａｒｅｄＯｂｊｅｃｔを利用して閲覧者端末４の記憶部８の所定の場所に格納する（Ｓ３０５）。このときの、画面上のＷｅｂしおりの変化は第１の実施形態と同様である（図１３参照）。
第１の実施形態と同様に、Ｗｅｂしおりが挟まれたページのＵＲＬは閲覧者端末４側に保存されているので、Ｗｅｂしおりをクリックするだけで、そのＵＲＬで特定されるホームページへただちにジャンプできる。

次に、閲覧者端末４がこのサイトに２回目以降に訪問した場合を図２３に従い説明する。
なお、閲覧者端末４は、すでに１以上のＷｅｂしおりを挟んでいることを前提に説明する。

閲覧者端末４は、Ｗｅｂページサーバ２に閲覧要求をすると（Ｓ４０１）。Ｗｅｂページサーバ２から送信される（Ｓ４０２）ＨＴＭＬファイルを、Ｗｅｂブラウザで表示し、続いて、閲覧者端末４はＷｅｂしおりサーバ３側へのしおり情報送信時間の経過の有無をチェックする（Ｓ４０３）点は、第１の実施形態と同様である。
前回のサイト訪問から所定の時間が経過しているとき（Ｓ４０３でＮｏ）の処理が、第１の実施形態と相違する。
すなわち、ＦｌａｓｈのＷｅｂしおり画像とリンクされている処理スクリプトによって、ＳｈａｒｅｄＯｂｊｅｃｔに保存しておいたカテゴリ、サブカテゴリ及び属性が取り出され、この処理スクリプトによって、カテゴリなどが集計される。そして、集計結果が、Ｗｅｂしおりサーバ３へ送信される（Ｓ４０４）。

Ｗｅｂしおりサーバ３は集計結果を受信する（Ｓ４０５）と、広告ページのＵＲＬとカテゴリ情報との対応テーブルを参照する。このテーブルから、受信した情報にふさわしい広告を検索し、ふさわしい広告がなければ（Ｓ４０６で“無”）、その旨の情報を送信する（Ｓ４０８）。ふさわしい広告が見つかれば（Ｓ４０６で“有”）、その広告ページのＵＲＬを含む広告記述ファイルを閲覧者端末４に送信する（Ｓ４０７）。

Ｗｅｂしおりサーバ３からの送信を受けとった後の閲覧者端末４の処理（Ｓ４０９以降）は、第１の実施形態とほぼ同様である。
ただし、新着情報を含む当該サイトのページを閲覧し、その閲覧したページがＷｅｂしおり機能を組み込まれたものであった場合（Ｓ４１４でＹｅｓ）、Ｗｅｂしおりを挟むならば（Ｓ４１５でＹｅｓ）、記憶部８の所定の場所に、そのページのページＩＤの代わりにカテゴリＩＤなどが保存される点で、第１の実施形態とは異なる。

前記の第１の実施形態とこの第２の実施形態とでは、閲覧者にとって、操作上の差異はない。これらの２つの実施形態のＧＵＩは同じであて、システムの内部的な処理が相違するにすぎない。
また、第１の実施形態とこの第２の実施形態とでは、閲覧者から運営者に送られてくる情報は、前者はページＩＤに対し、後者は集計したカテゴリ情報という相違はあるが、いずれも、サイト運営者及び各店舗等にとって、貴重なマーケティング情報となる。
さらに、前記実施形態のいずれのシステムも、既存のＷｅｂサイトに導入することは容易である。ＷｅｂページサーバにアップロードされているＨＴＭＬ等で記述されたファイルに、Ｗｅｂしおりのためのスクリプト（図９の行Ｌ２，図２０の行Ｌ２‘を参照）を追加し、Ｗｅｂしおりを実装するプログラムファイルを作成するとともに、新たにＷｅｂしおりサーバ３を追加することが、主たる改造点だからである。

なお、前記のように開示された実施の形態はすべての点で例示であって、制限的なものではない。したがって、種々の変形が可能である。しかし、その変形が特許請求の範囲に記載された技術思想に基づくものである限り、その変形は本発明の技術的範囲に含まれる。

インターネット上にサイトを設置する運営者にとって、効果的な広告宣伝を可能とするマーケティングツールとなるとともに、閲覧者に対する使い勝手のよいサイトの提供手段としても利用できる。

第１の実施形態のシステム構成図である。第１の実施形態の事前登録処理のフローである。第１の実施形態のカテゴリ設定画面例を示す図である。第１の実施形態のカテゴリ一覧画面例を示す図である。第１の実施形態のカテゴリ分類例を示す図である。第１の実施形態のしおり情報設定画面例を示す図である。第１の実施形態のしおり情報設定済みのページ一覧の画面表示例を示す図である。第１の実施形態の広告ページ設定画面例を示す図である。第１の実施形態のホームページを記述するＨＴＭＬファイルを例示する図である。第１の実施形態のＪａｖａＳｃｒｉｐｔによるスクリプト記述ファイルを例示する図である。第１の実施形態の閲覧者端末の初回の閲覧フローである。第１の実施形態のＷｅｂしおりを組み込んだホームページの表示例を示す図である。第１の実施形態のＷｅｂしおりの表示が変化した状態を示す図である。第１の実施形態の閲覧者端末に保存されるＷｅｂしおりデータのデータ構造を例示する図である。第１の実施形態のホームページ表示画面に他のページのＷｅｂしおりが表示されている状態を示す図である。第１の実施形態の閲覧者端末の２回目以降の閲覧フローである。第１の実施形態の閲覧者端末に新着の広告情報が送信された状態を示す図である。第１の実施形態の閲覧者端末に送信される広告記述ファイルの画面表示例を示す図である。第２の実施形態の事前登録処理のフローである。第２の実施形態のホームページを記述するＨＴＭＬファイルを例示する図である。第２の実施形態のＪａｖａＳｃｒｉｐｔによるスクリプト記述ファイルを例示する図である。第２の実施形態の閲覧者端末の初回の閲覧フローである。第２の実施形態の閲覧者端末の２回目以降の閲覧フローである。

符号の説明

１サイト運営者端末
２Ｗｅｂページサーバ
３システム管理サーバ（Ｗｅｂしおりサーバ）
４閲覧者端末
６（閲覧者端末４の）入力部
７（閲覧者端末４の）画面表示部
８（閲覧者端末４の）記憶部

Claims

画像データと、この画像にリンクする処理スクリプトからなるＷｅｂしおりであって、
Ｗｅｂサイトを構成する各Ｗｅｂページ毎に、コンテンツ要素の一つとして組み込まれ、
選択状態あるいは非選択状態のいずれかの値をとり、非選択状態かつ前記画像が表示された状態において所定の操作がなされると、前記処理スクリプトは、値を選択状態に変えるとともに、該Ｗｅｂページが表示されている端末装置に接続する記憶装置の所定の場所に該ＷｅｂページのＵＲＬを保存し、
選択状態かつ前記画像が表示された状態において所定の操作がなされると、前記処理スクリプトは、前記記憶装置の所定の場所から該ＷｅｂページのＵＲＬを取得し、前記ＷｅｂサイトのＷｅｂサーバに対し、該Ｗｅｂページデータの送信を要求することを特徴とするＷｅｂしおり。
請求項１に記載のＷｅｂしおりを利用するマーケティングシステムであって、
インターネット上に開設されたＷｅｂサイトのホームページを提供するサイト運営者端末と、該Ｗｅｂサイト内のホームページを管理するＷｅｂページサーバと、該Ｗｅｂサイトのホームページに組み込まれたＷｅｂしおりに関連する情報を管理するシステム管理サーバと、該Ｗｅｂサイトにアクセスする閲覧者端末とを備え、
前記サイト運営者端末は、
任意個数のホームページの記述ファイルを、前記Ｗｅｂページサーバへアップロードするとともに、
該ホームページにＷｅｂしおりがコンテンツ要素として組み込まれていれば、前記システム管理サーバに該ホームページを識別するページＩＤと、このページに付与されたカテゴリ情報並びにＵＲＬと、ダイレクトマーケティング用の広告ページのＵＲＬを送信し、
前記システム管理サーバは、
前記サイト運営者端末から受信したカテゴリ情報と該ホームページのＵＲＬと広告ページのＵＲＬを、ページＩＤに対応付けて記憶する一方、
前記閲覧者端末は、
入力部と画面表示部と記憶部を備え、
前記Ｗｅｂページサーバから、ホームページの記述ファイルを受信すると、前記画面表示部に対し、前記Ｗｅｂしおりを含む該ホームページを表示させ、
前記入力部を介して該Ｗｅｂしおりを選択・指示する所定の操作がなされると、前記処理スクリプトを実行させることにより、該ホームページのページＩＤとＵＲＬとを対にして前記記憶部に保存させるとともに、
前記記憶部に１以上のページＩＤがすでに保存されているときは、所定のタイミングのもと、前記システム管理サーバに対し、前記の保存されているページＩＤを送信し、
前記システム管理サーバは、
前記閲覧者端末から受信したページＩＤに対応づけられた前記カテゴリ情報と共通性を有するホームページ並びに広告ページのＵＲＬを抽出し、抽出したＵＲＬを含む広告記述ファイルを生成し、前記閲覧者端末に送信する
ことを特徴とするＷｅｂしおりを利用するマーケティングシステム。
請求項１に記載のＷｅｂしおりを利用するマーケティングシステムであって、
インターネット上に開設されたＷｅｂサイトのホームページを提供するサイト運営者端末と、該Ｗｅｂサイト内のホームページを管理するＷｅｂページサーバと、該Ｗｅｂサイトの広告ページに関連する情報を管理するシステム管理サーバと、該Ｗｅｂサイトにアクセスする閲覧者端末とを備え、
前記サイト運営者端末は、
任意個数のホームページの記述ファイルを、前記Ｗｅｂページサーバへアップロードするとともに、Ｗｅｂしおりを利用するホームページの記述ファイルには、Ｗｅｂしおりをコンテンツ要素として組み込み、かつ、カテゴリ情報を記述する一方、
前記閲覧者端末は、
入力部と画面表示部と記憶部を備え、
前記Ｗｅｂページサーバから、ホームページの記述ファイルを受信すると、前記画面表示部に対し、前記Ｗｅｂしおりを含む該ホームページを表示させ、
前記入力部によって該Ｗｅｂしおりを選択・指示する所定の操作がなされると、前記記憶部に対し、該ホームページの前記カテゴリ情報とＵＲＬとを対にして保存させるとともに、
前記記憶部に１以上のカテゴリ情報がすでに保存されているときは、所定のタイミングのもと、カテゴリ情報を集計し、前記システム管理サーバに対し、このカテゴリ集計結果を送信し、
前記システム管理サーバは、
前記閲覧者端末から集計結果を受信すると、集計されたカテゴリ情報と共通性を有するホームページ並びに広告ページを抽出し、抽出したページのＵＲＬを含む広告記述ファイルを生成し、前記閲覧者端末に送信する
ことを特徴とするＷｅｂしおりを利用するマーケティングシステム。