IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ バリューコマース株式会社の特許一覧

特許7145215ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム
<>
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図1
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図2
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図3
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図4
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図5
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図6
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図7
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図8
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図9
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図10
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図11
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図12
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図13
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図14
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図15
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図16
  • 特許-ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム 図17
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-09-21
(45)【発行日】2022-09-30
(54)【発明の名称】ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム
(51)【国際特許分類】
   G06F 15/00 20060101AFI20220922BHJP
【FI】
G06F15/00 420Z
【請求項の数】 9
(21)【出願番号】P 2020528633
(86)(22)【出願日】2018-07-05
(86)【国際出願番号】 JP2018025568
(87)【国際公開番号】W WO2020008600
(87)【国際公開日】2020-01-09
【審査請求日】2020-10-12
(73)【特許権者】
【識別番号】599158144
【氏名又は名称】バリューコマース株式会社
(74)【代理人】
【識別番号】100088155
【弁理士】
【氏名又は名称】長谷川 芳樹
(74)【代理人】
【識別番号】100113435
【弁理士】
【氏名又は名称】黒木 義樹
(74)【代理人】
【識別番号】100144440
【弁理士】
【氏名又は名称】保坂 一之
(72)【発明者】
【氏名】伊藤 信敬
(72)【発明者】
【氏名】津留 雅文
【審査官】多賀 実
(56)【参考文献】
【文献】特開2014-241114(JP,A)
【文献】特開2014-130542(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 15/00
(57)【特許請求の範囲】
【請求項1】
少なくとも一つのプロセッサを備え、
前記少なくとも一つのプロセッサが、
ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するための識別子であるデータ列を生成し、
前記データ列を示す複数の画素を含む画像ファイルを生成し、
前記データ列を前記ユーザ端末のキャッシュに格納するために前記画像ファイルを前記ユーザ端末に送信し、
前記ユーザ端末により前記キャッシュから読み出されて送信された前記データ列を取得して、該取得されたデータ列を記憶装置に格納し、
前記データ列が前記記憶装置に格納された後に、アフィリエイト広告を取得するためのHTTPリクエストを前記ユーザ端末から取得し、
前記HTTPリクエストと前記記憶装置内のデータ列とを比較し、
前記HTTPリクエストが前記データ列を含む場合に、前記HTTPリクエストが前記ブラウザから送信されたと判定して、前記ブラウザを特定し、
HTTPクッキーを用いることなく、前記ユーザ端末の前記特定されたブラウザ上に、前記アフィリエイト広告を含む前記ウェブページを表示させる、
ブラウザ管理システム。
【請求項2】
前記少なくとも一つのプロセッサが、前記データ列を、前記複数の画素に対応する複数の画素値に変換することで前記画像ファイルを生成する、
請求項1に記載のブラウザ管理システム。
【請求項3】
前記複数の画素がRGBまたはグレースケールで表される、
請求項1または2に記載のブラウザ管理システム。
【請求項4】
前記ウェブページが、前記画像ファイルを取得するためのスクリプトを含み、
前記少なくとも一つのプロセッサが、前記ユーザ端末で前記スクリプトが実行されたことに応答して、前記データ列の生成と、前記画像ファイルの生成と、前記画像ファイルの送信とを実行する、
請求項1~3のいずれか一項に記載のブラウザ管理システム。
【請求項5】
前記少なくとも一つのプロセッサが、前記データ列を含む文字列を前記ユーザ端末から受信することで前記データ列を取得する、
請求項1~4のいずれか一項に記載のブラウザ管理システム。
【請求項6】
前記少なくとも一つのプロセッサが、前記ユーザ端末から前記画像ファイルを受信して該画像ファイルから前記データ列を抽出することで、前記データ列を取得する、
請求項1~4のいずれか一項に記載のブラウザ管理システム。
【請求項7】
少なくとも一つのプロセッサにより実行されるブラウザ管理方法であって、
ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するための識別子であるデータ列を生成するステップと、
前記データ列を示す複数の画素を含む画像ファイルを生成するステップと、
前記データ列を前記ユーザ端末のキャッシュに格納するために前記画像ファイルを前記ユーザ端末に送信するステップと、
前記ユーザ端末により前記キャッシュから読み出されて送信された前記データ列を取得して、該取得されたデータ列を記憶装置に格納するステップと、
前記データ列が前記記憶装置に格納された後に、アフィリエイト広告を取得するためのHTTPリクエストを前記ユーザ端末から取得するステップと、
前記HTTPリクエストと前記記憶装置内のデータ列とを比較するステップと、
前記HTTPリクエストが前記データ列を含む場合に、前記HTTPリクエストが前記ブラウザから送信されたと判定して、前記ブラウザを特定するステップと、
HTTPクッキーを用いることなく、前記ユーザ端末の前記特定されたブラウザ上に、前記アフィリエイト広告を含む前記ウェブページを表示させるステップと
を含むブラウザ管理方法。
【請求項8】
ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するための識別子であるデータ列を生成するステップと、
前記データ列を示す複数の画素を含む画像ファイルを生成するステップと、
前記データ列を前記ユーザ端末のキャッシュに格納するために前記画像ファイルを前記ユーザ端末に送信するステップと、
前記ユーザ端末により前記キャッシュから読み出されて送信された前記データ列を取得して、該取得されたデータ列を記憶装置に格納するステップと、
前記データ列が前記記憶装置に格納された後に、アフィリエイト広告を取得するためのHTTPリクエストを前記ユーザ端末から取得するステップと、
前記HTTPリクエストと前記記憶装置内のデータ列とを比較するステップと、
前記HTTPリクエストが前記データ列を含む場合に、前記HTTPリクエストが前記ブラウザから送信されたと判定して、前記ブラウザを特定するステップと、
HTTPクッキーを用いることなく、前記ユーザ端末の前記特定されたブラウザ上に、前記アフィリエイト広告を含む前記ウェブページを表示させるステップと
をコンピュータシステムに実行させるブラウザ管理プログラム。
【請求項9】
請求項1~6のいずれか一項に記載のブラウザ管理システムから前記画像ファイルを受信するステップと、
前記データ列を前記キャッシュに格納するステップと
をコンピュータに実行させるクライアントプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の一側面はブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラムに関する。
【背景技術】
【0002】
ユーザ端末のブラウザを管理するための仕組みが知られている。例えば、特許文献1には、トラッキングサーバーサイトを用いてユーザのアクティビティをトラッキングする方法が記載されている。この方法の第1プロセスでは、ユーザ端末においてバナー広告がクリックされた際に、トラッキングサーバーサイトがクリック情報に基づくクッキー用データを作成してユーザ端末に送信する。第2プロセスでは、広告主サイトが、ユーザ端末からクッキー用データを受信し、クッキー用データに基づいてクッキーをユーザ端末に書き込む。第3プロセスでは、商取引が完了した際に、広告主サイトがユーザ端末からクッキーを取得し、そのクッキーの記録情報を含むトラッキング電文を作成してトラッキングサーバーサイトに送信する。
【先行技術文献】
【特許文献】
【0003】
【文献】特許第4647717号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1に記載の技術はHTTPクッキー(HTTP cookie)の利用を前提とする。しかし、HTTPクッキーを利用できない環境も存在するので、HTTPクッキー以外の手法でブラウザを特定することが望まれている。
【課題を解決するための手段】
【0005】
本発明の一側面に係るブラウザ管理システムは、少なくとも一つのプロセッサを備え、少なくとも一つのプロセッサが、ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成し、データ列を示す複数の画素を含む画像ファイルを生成し、データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信する。
【0006】
本発明の一側面に係るブラウザ管理方法は、少なくとも一つのプロセッサにより実行されるブラウザ管理方法であって、ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成するステップと、データ列を示す複数の画素を含む画像ファイルを生成するステップと、データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信するステップとを含む。
【0007】
本発明の一側面に係るブラウザ管理プログラムは、ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成するステップと、データ列を示す複数の画素を含む画像ファイルを生成するステップと、データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信するステップとをコンピュータシステムに実行させる。
【0008】
このような側面においては、ブラウザを特定するためのデータ列を示す画像ファイルがユーザ端末のキャッシュに格納される。したがって、その画像ファイルを用いることで、HTTPクッキーを用いることなくブラウザを特定することができる。
【発明の効果】
【0009】
本発明の一側面によれば、HTTPクッキー以外の手法でブラウザを特定することができる。
【図面の簡単な説明】
【0010】
図1】第1実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。
図2】実施形態に係るブラウザ管理システムで用いられるコンピュータの一般的なハードウェア構成を示す図である。
図3】ユーザ端末の動作の一例を示すフローチャートである。
図4】第1実施形態に係るブラウザ管理システムの動作の一例を示すシーケンス図である。
図5】第2実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。
図6】第2実施形態に係るブラウザ管理システムの動作の一例を示すシーケンス図である。
図7】第3実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。
図8】第3実施形態に係るブラウザ管理システムの動作の一例を示すフローチャートである。
図9】第4実施形態に係るブラウザ管理システムの適用の一例を示す図である。
図10】第4実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。
図11】第4実施形態に係るブラウザ管理システムの動作の一例を示すシーケンス図である。
図12】第5実施形態に係るブラウザ管理システムの適用の一例を示す図である。
図13】第5実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。
図14】第5実施形態に係るブラウザ管理システムの動作の一例を示すシーケンス図である。
図15】第6実施形態に係るブラウザ管理システムの適用の一例を示す図である。
図16】第6実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。
図17】第6実施形態に係るブラウザ管理システムの動作の一例を示すシーケンス図である。
【発明を実施するための形態】
【0011】
以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一または同等の要素には同一の符号を付し、重複する説明を省略する。
【0012】
[システムの概要]
いくつかの実施形態において、ブラウザ管理システムは、ユーザ端末のブラウザを特定するための仕組みを提供するコンピュータシステムである。このブラウザ管理システムにより、ステートレス(stateless)なプロトコルを用いるコンピュータシステム上でステートフル(stateful)な処理を実現することが可能になる。
【0013】
ステートレスとは、現在の状態を示すデータをシステムが保持しない方式のことをいう。ステートレスなプロトコルの例としてHTTP(Hypertext Transfer Protocol)が挙げられるが、これに限定されない。一方、ステートフルとは、現在の状態を表すデータをシステムが保持し、その状態が処理に反映される方式のことをいう。
【0014】
ステートフルな処理により様々なサービスを実現することができる。そのサービスの例として、電子商取引(EC)、コンバージョン・トラッキング(conversion tracking)、アフィリエイト・トラッキング(affiliate tracking)、アナリティクス(analytics)、ターゲティング(targeting)、および不正アクセス対策が挙げられる。しかし、ステートフルな処理を伴うサービスの種類はこれらに限定されるものではない。ブラウザ管理システムは任意のサービスのために構築することができる。
【0015】
ステートフルな処理を実現するために、ブラウザ管理システムは、従来から知られているHTTPクッキーを用いるのではなく、その従来技術とは異なる新たな手法を用いる。具体的には、ブラウザ管理システムは、ブラウザを特定するためのデータ列(以下では単に「データ列」ともいう。)が埋め込まれた画像ファイル(以下では単に「画像ファイル」ともいう。)をユーザ端末に送信することで、そのデータ列をユーザ端末内に記憶させる。このデータ列が、ステートフルな処理を実現するために用いられる。以下では、いくつかの実施形態を例として示しながら、本開示におけるブラウザ管理システムについて詳細に説明する。
【0016】
[第1実施形態]
図1は、第1実施形態に係るブラウザ管理システム1の機能構成の一例を示す図である。本実施形態では、ブラウザ管理システム1は第1サーバ10を備える。第1サーバ10は1以上のユーザ端末20と通信ネットワークを介して接続することができる。本実施形態では、ユーザ端末20はウェブサーバ30と通信ネットワークを介して接続することもできる。コンピュータ同士をつなぐ通信ネットワークの構成は何ら限定されない。例えば、通信ネットワークはインターネットおよびイントラネットの少なくとも一つを用いて構築されてもよい。
【0017】
ユーザ端末20は、任意のオンラインサービスを受ける人であるユーザが操作するコンピュータである。ユーザ端末20はブラウザ21およびキャッシュ22を備える。ブラウザ21は、ウェブページをモニタ上に表示するためのソフトウェアである。ユーザ端末20は複数種類のブラウザ21を備えてもよい。キャッシュ22は、データを一時的にコンピュータに保存する機能である。キャッシュ22の実現方法は限定されず、例えば、キャッシュメモリ、ディスクキャッシュ、またはキャッシュファイルを用いてキャッシュ22が実現されてもよい。ユーザ端末として用いられるコンピュータの種類は限定されない。例えば、ユーザ端末は携帯型または据置型のパーソナルコンピュータであってもよい。あるいは、ユーザ端末は、高機能携帯電話機(スマートフォン)、携帯電話機、携帯情報端末(PDA)、タブレットなどの携帯端末でもよい。
【0018】
ウェブサーバ30は、ステートフルなサービスを提供可能なウェブサイト(以下では単に「ウェブサイト」という。)をユーザ端末20に提供するコンピュータである。ウェブサイトとは、特定のドメイン名の下に置かれた1以上のウェブページの集合である。ウェブページとは、ブラウザで閲覧可能な1ページ分の文書である。ウェブサイトの例としてECサイト、ニュースサイト、ポータルサイト、ブログサイト、およびソーシャル・ネットワーキング・サービス(SNS)サイトが挙げられる。しかし、ウェブサイトの例はこれらに限定されない。ウェブサイトが何ら限定されないことに対応して、個々のウェブページの内容(例えば、掲載される情報、または実行可能な機能)も何ら限定されない。
【0019】
第1サーバ10は、ユーザ端末20のブラウザ21を特定するための処理を実行するコンピュータである。より具体的には、第1サーバ10は、データ列が埋め込まれた画像ファイルをユーザ端末20に送信する。第1サーバ10は機能要素として受信部11、画像生成部12、および送信部13を備える。受信部11は、ウェブページを処理するユーザ端末20から画像ファイルの要求を受信する機能要素である。画像生成部12は、その要求に応答して、データ列が埋め込まれた画像ファイルを生成する機能要素である。送信部13は、データ列をキャッシュ22に格納するためにその画像ファイルをユーザ端末20に送信する機能要素である。
【0020】
第1サーバ10は一または複数のコンピュータで構成される。複数のコンピュータを用いる場合には、これらのコンピュータがインターネットやイントラネットなどの通信ネットワークを介して接続されることで、論理的に一つの第1サーバ10が構築される。
【0021】
図2は第1サーバ10を構成するコンピュータ100の一般的なハードウェア構成を示す。例えば、コンピュータ100はプロセッサ101、主記憶部102、補助記憶部103、通信制御部104、入力装置105、および出力装置106を備える。プロセッサ101はオペレーティングシステムおよびアプリケーションプログラムを実行する。主記憶部102は例えばROMおよびRAMで構成される。補助記憶部103は例えばハードディスクまたはフラッシュメモリで構成され、一般に主記憶部102よりも大量のデータを記憶する。補助記憶部103は、少なくとも1台のコンピュータを第1サーバ10として機能させるための第1プログラムを記憶する。通信制御部104は例えばネットワークカードまたは無線通信モジュールで構成される。入力装置105は例えばキーボード、マウス、タッチパネルなどで構成される。出力装置106は例えばモニタおよびスピーカで構成される。
【0022】
第1サーバ10の各機能要素は、プロセッサ101または主記憶部102の上に第1プログラムを読み込ませてそのプログラムを実行させることで実現される。第1プログラムは第1サーバ10の各機能要素を実現するためのコードを含む。プロセッサ101は第1プログラムに従って、通信制御部104、入力装置105、または出力装置106を動作させ、主記憶部102または補助記憶部103におけるデータの読み出しおよび書き込みを行う。この処理により第1サーバ10の各機能要素が実現される。処理に必要なデータまたはデータベースは主記憶部102または補助記憶部103内に格納されてもよい。
【0023】
第1プログラムは、例えば、CD-ROM、DVD-ROM、半導体メモリなどの有形の記録媒体に固定的に記録された上で提供されてもよい。あるいは、第1プログラムは、搬送波に重畳されたデータ信号として通信ネットワークを介して提供されてもよい。提供された第1プログラムは補助記憶部103に格納されてもよい。
【0024】
本実施形態では第1サーバ10はウェブサーバ30とは別のコンピュータであるが、サーバの構成はこれに限定されない。例えば、一つのサーバが第1サーバ10およびウェブサーバ30の双方の機能を備えてもよい。
【0025】
図3を参照しながら、データ列の取得に関するユーザ端末20での処理について説明する。図3はユーザ端末20の動作の一例を示すフローチャートである。
【0026】
ステップS11では、ユーザ端末20は、ユーザがウェブサイトのウェブページを選択したことに応答して、そのウェブページをウェブサーバ30から受信する。ウェブページの選択方法は限定されない。例えば、ウェブページは、リンクがクリックされることで選択されてもよいし、URL(Uniform Resource Locator)が直接に入力されることで選択されてもよい。
【0027】
ステップS12では、ユーザ端末20はデータ列を取得するためのJavaScript(登録商標)を取得する。例えば、ユーザ端末20は受信したウェブページに記述されている<script>タグに従ってそのスクリプトを取得する。スクリプトはブラウザ21上で実行される比較的簡易なプログラムである。ユーザ端末20はスクリプトを実行することで後続のステップ(例えば、ステップS13~S17の少なくとも一部)を実行する。なお、スクリプトはJavaScript(登録商標)に限定されるものではなく、他のスクリプト言語が用いられてもよい。
【0028】
ステップS13では、ユーザ端末20は、ウェブサイトに対応するデータ列がキャッシュ22内に記憶されているか否かを調べる。データ列が既にキャッシュ22内に存在する場合には(ステップS13においてYES)、データ列を新たに取得する必要が無いので、ユーザ端末20はデータ列を第1サーバ10に要求しない。一方、データ列がキャッシュ22内に存在しない場合には(ステップS13においてNO)、処理はステップS14に進む。
【0029】
ステップS14では、ユーザ端末20は、ウェブサイトに対応するデータ列を第1サーバ10から取得する。ユーザ端末20は、データ列が埋め込まれた画像ファイルを第1サーバ10から受信することでそのデータ列を取得する。
【0030】
ステップS15では、ユーザ端末20はそのデータ列をキャッシュ22に格納する。ユーザ端末20は画像ファイルをキャッシュ22に格納してもよい。画像ファイルはデータ列を含むので、画像ファイルの格納はデータ列の格納の一例である。あるいは、ユーザ端末20は画像ファイルからデータ列を抽出して、そのデータ列をキャッシュ22に格納してもよい。データ列がキャッシュ22に格納されることで、ユーザ端末20はそのデータ列をサーバ側(ネットワーク側)に送信することができる。要求を受信するサーバはそのデータ列を取得することで、ブラウザ21の現在の状態に基づく処理を実行することができ、これによりステートフルな処理が実現可能になる。
【0031】
ステップS16では、ユーザ端末20はキャッシュ22からデータ列を読み出してそのデータ列を所定のサーバに送信する。データ列の送信先は限定されず、例えば、リダイレクトサーバ、ビーコンサーバ、およびウェブサーバ30のいずれかであってもよい。
【0032】
ステップS17では、ユーザ端末20は受信したウェブページをモニタ上に表示する。
【0033】
ステップS11~S17は、ユーザ端末20のブラウザ21上にウェブページを表示するための処理である。この処理を実行するためにクライアントプログラムが用意される。そのクライアントプログラムがユーザ端末20にインストールされることで、ユーザ端末20はステップS11~S17の処理を実行できる。第1プログラムと同様に、クライアントプログラムは有形の記録媒体に固定的に記録された上で提供されてもよいし、通信ネットワークを介して提供されてもよい。クライアントプログラムは他のプログラムとは別に提供可能である。
【0034】
図4を参照しながら、画像ファイル(データ列)の提供に関するブラウザ管理システム1の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図4はブラウザ管理システム1の動作の一例を示すシーケンス図である。図4は、表示されようとするウェブサイトに対応するデータ列が未だキャッシュ22に格納されていないことを前提とする。
【0035】
ステップS21では、ユーザ端末20が、ユーザにより選択されたウェブページに関連する処理を実行する。「ウェブページに関連する処理」とは、ウェブページをユーザ端末20のブラウザ21上に表示するための処理であり、上記のステップS11~S17の少なくとも一部を含む。
【0036】
ステップS22では、ユーザ端末20が画像要求を第1サーバ10に送信する。この処理は、ステップS14の一部であるということができる。画像要求は、画像ファイルを第1サーバ10から取得するためのデータ信号である。第1サーバ10では受信部11がその画像要求を受信する。
【0037】
ステップS23では、画像生成部12が、ブラウザ21を特定するためのデータ列を生成する。「ブラウザを特定する」とは、一のウェブサイトにおいて一つのブラウザを他のブラウザと区別して認識することをいう。データ列はブラウザ21を特定する識別子であって、ユーザ端末20を特定する識別子ではないことに留意されたい。データ列とは、コンピュータが処理可能な複数の文字で構成される一つの文字列で表現されるデータである。画像生成部12はウェブサイトにおいてブラウザ21を特定するために十分な情報量をデータ列が含むように該データ列を生成する。その情報量は2(すなわち、nビット)で表すことができ、その指数nを大きくするほどデータ列の情報量を多くすることができる。
【0038】
一のウェブサイトにおいてブラウザ21を特定することができる限り、指数nの具体的な値は任意に定められてよい。また、ブラウザ21をそのように特定することができる限り、画像生成部12は任意の手法を用いてデータ列を生成してよい。データ列は、将来、別のブラウザまたは同一ブラウザのために再度用いられる可能性がある値でもよいし、一回だけ生成される唯一の値(すなわち、将来、別のブラウザまたは同一ブラウザのために再度用いられる可能性が無い、使い捨ての値。)でもよい。データ列の構成は限定されない。例えば、画像生成部12はシステム時刻(例えば、現在日時)およびIPアドレスの少なくとも一方を含むデータ列を生成してもよい。より具体的な例として、データ列は、第1サーバ10のIPアドレスと、第1サーバ10でユーザ端末20のために実行されているスレッドを示すスレッドIDと、システム時刻との組合せを用いて生成されてもよい。あるいは、データ列は、ユーザ端末20のIPアドレスおよびポート番号と、第1サーバ10のIPアドレスおよびポート番号と、システム時刻との組合せを用いて生成されてもよい。あるいは、画像生成部12は、乱数、自動インクリメント、またはシーケンスを利用してデータ列を生成してもよい。
【0039】
ステップS24では、画像生成部12がそのデータ列を示す複数の画素を含む画像ファイルを生成する。具体的には、画像生成部12はデータ列を複数の画素の複数の画素値に変換することで画像ファイルを生成する。画像ファイルのカラーモード(色を設定する方法)、画素数、および生成方法は限定されず、画像生成部12は任意の手法を用いて画像ファイルを生成してよい。
【0040】
一例として、画像ファイルはRGBカラーで表されてもよい。複数の画素がRGB(赤、緑、青)で表される場合には、画像生成部12はデータ列を複数の画素の複数の画素値(RGB値)に変換することで、そのデータ列を複数の画素で表現し、該複数の画素を含む画像ファイルを生成する。なお、個々の画素は、RGB値に加えてさらなる値で定義されてもよく、例えば、アルファ・ブレンディング(Alpha Blending)で用いられる、透過度を示すアルファ値をさらに用いて定義されてもよい。RGBの各色の情報量は8ビットなので、1画素の情報量は2(8×3)(すなわち、24ビット)である。データ列をk個の画素のRGB値に変換するならば、画像生成部12は2(8×3×k)の情報量をk個の画素に埋め込むことができる。
【0041】
別の例として、画像ファイルはグレースケールで表されてもよい。複数の画素がグレースケールで表される場合には、画像生成部12はデータ列を複数の画素の複数の画素値(グレースケール値)に変換することで、そのデータ列を複数の画素で表現し、該複数の画素を含む画像ファイルを生成する。グレースケールの情報量は8ビットなので、1画素の情報量は2(すなわち、8ビット)である。データ列をk個の画素のグレースケール値に変換するならば、画像生成部12は2(8×k)の情報量をk個の画素に埋め込むことができる。
【0042】
上記の通りデータ列の情報量は限定されないので、そのデータ列が埋め込まれる画素の個数も限定されない。例えば、データ列を4個のRGB画素で表すとすれば、画像生成部12は、情報量が2(8×3×4)=296(すなわち、96ビット)であるデータ列が埋め込まれた画像ファイルを生成することができる。データ列を9個のRGB画素で表すとすれば、画像生成部12は、情報量が2(8×3×9)=2216(すなわち、216ビット)であるデータ列が埋め込まれた画像ファイルを生成することができる。データ列を10個のグレースケール画素で表すとすれば、画像生成部12は、情報量が2(8×10)=280(すなわち、80ビット)であるデータ列が埋め込まれた画像ファイルを生成することができる。データ列を16個のグレースケール画素で表すとすれば、画像生成部12は、情報量が2(8×16)=2128(すなわち、128ビット)であるデータ列が埋め込まれた画像ファイルを生成することができる。画像ファイルのカラーモードの種類にかかわらず、画素の個数kは2以上であればいくつでもよく、データ列の情報量に応じて決めることができる。
【0043】
画像生成部12は、データ列が埋め込まれた複数の画素で構成される画像ファイルを生成してもよい。あるいは、画像生成部12は、データ列が埋め込まれた複数の画素と、データ列が埋め込まれていない1以上の画素とで構成される画像ファイルを生成してもよい。すなわち、画像生成部12は、データ列に加えて他の情報も含む画像ファイルを生成してもよい。
【0044】
生成される画像ファイルの形状は限定されない。例えば、画像ファイルの形状は正方形、長方形、直線状、ほぼ円形、または他の多角形でもよいし、より複雑な形状でもよい。RGBカラーの画像ファイルである場合には、例えば、画像生成部12は2(画素)×2(画素)の画像ファイル(情報量は96ビット)を生成してもよいし、3(画素)×3(画素)の画像ファイル(情報量は216ビット)を生成してもよい。
【0045】
ステップS25では、送信部13が画像ファイルをユーザ端末20に送信する。この画像ファイルは、画像要求に対する応答であるといえる。ユーザ端末20はその画像ファイルを受信する。この受信処理はステップS14の一部であるということができる。
【0046】
ステップS26では、ユーザ端末20がデータ列をキャッシュ22に格納する。この処理はステップS15に対応する。ユーザ端末20は受信した画像ファイルをキャッシュ22に格納してもよいし、画像ファイルから抽出したデータ列をキャッシュ22に格納してもよい。画像ファイルにはデータ列が埋め込まれているので、キャッシュ22への画像ファイルの格納は、データ列をキャッシュ22に格納する処理の一例である。ステップS26よりも後にユーザ端末20がブラウザ21を介して同じウェブサイトにアクセスする際には、ユーザ端末20はキャッシュ22内の画像ファイルまたはデータ列を読み出して、その画像ファイルまたはデータ列を所定のサーバに送信することができる。この処理において、ユーザ端末20は読み出した画像ファイルからデータ列を抽出してもよい。サーバはそのデータ列を保存および参照することで、ステートフルな処理を実行することができる。
【0047】
[第2実施形態]
第2実施形態に係るブラウザ管理システム2は、第1実施形態で生成されたデータ列をサーバ側で保存する仕組みを提供する。この仕組みは、ステートレスなプロトコルを用いるコンピュータシステム上でステートフルな処理を実現するための構成の一例である。
【0048】
図5はブラウザ管理システム2の機能構成の一例を示す図である。本実施形態では、ブラウザ管理システム2は、第1実施形態で示したものと同じ第1サーバ10と、データ列をサーバ側(ネットワーク側)に保存する第2サーバ40とを備える。第1サーバ10と同様に、第2サーバ40もユーザ端末20のブラウザ21を特定するための処理を実行するコンピュータである。第1サーバ10および第2サーバ40のそれぞれは、1以上のユーザ端末20と通信ネットワークを介して接続することができる。
【0049】
第2サーバ40は機能要素として受信部41および格納部42を備える。受信部41は、ユーザ端末20からデータ列を受信する機能要素である。格納部42は、そのデータ列をデータベース50に格納する機能要素である。第2サーバ40も一または複数のコンピュータ100で構成される。複数のコンピュータを用いる場合には、これらのコンピュータがインターネットやイントラネットなどの通信ネットワークを介して接続されることで、論理的に一つの第2サーバ40が構築される。コンピュータ100は、少なくとも1台のコンピュータを第2サーバ40として機能させるための第2プログラムを記憶する。第2プログラムは第2サーバ40の各機能要素を実現するためのコードを含む。第2サーバ40の各機能要素は、プロセッサ101または主記憶部102の上に第2プログラムを読み込ませてそのプログラムを実行させることで実現される。
【0050】
第1プログラムと同様に、第2プログラムは有形の記録媒体に固定的に記録された上で提供されてもよいし、通信ネットワークを介して提供されてもよい。第2プログラムは第1プログラムと共に提供されてもよいし、第1プログラムとは別に提供されてもよい。
【0051】
データベース50は、データ列を記憶する装置である。データベース50の実装方法は限定されず、例えばリレーショナル・データベースでもよい。データベース50が設けられる場所は限定されず、例えば、データベース50はブラウザ管理システム2の一構成要素でもよいし、ブラウザ管理システム2とは別のコンピュータシステム内に設けられてもよい。データベース50は、キー(key)を用いて値(value)の格納および取得を行うためのキー・バリュー・ストア(Key-Value Store:KVS)として機能してもよい。
【0052】
本実施形態では第2サーバ40は第1サーバ10ともウェブサーバ30とも異なるコンピュータであるが、サーバの構成はこれに限定されない。例えば、一つのサーバが、第1サーバ10、第2サーバ40、およびウェブサーバ30のうちの少なくとも二つのサーバの機能を備えてもよい。
【0053】
図6を参照しながら、ブラウザ管理システム2の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図6は、ブラウザ管理システム2の動作の一例を示すシーケンス図である。
【0054】
図6におけるステップS21~S26の処理は第1実施形態と同じなので(図4を参照)、これらのステップについての説明を省略する。
【0055】
ステップS26の後のステップS27では、ユーザ端末20がキャッシュ22からデータ列を取得する。この処理は、受信されたウェブページのJavaScript(登録商標)により実行されてもよいし、他のシステムイベントを契機に実行されてもよい。
【0056】
データ列の取得方法は限定されない。キャッシュ22が画像ファイルを記憶している場合には、ユーザ端末20はその画像ファイルをキャッシュ22から読み出してもよい。この画像ファイルにはデータ列が埋め込まれているので、キャッシュ22からの画像ファイルの読み出しは、キャッシュ22からデータ列を取得する処理の一例である。あるいは、ユーザ端末20は、キャッシュ22から画像ファイルを読み出してこの画像ファイルからデータ列を抽出することで、データ列を取得してもよい。キャッシュ22がデータ列を記憶している場合には、ユーザ端末20はそのデータ列をキャッシュ22から読み出すことでデータ列を取得できる。
【0057】
ステップS28では、ユーザ端末20がそのデータ列を第2サーバ40に送信する。データ列の送信方法は限定されない。例えば、ユーザ端末20はキャッシュ22から読み出した画像ファイルを第2サーバ40に送信してもよい。画像ファイルにはデータ列が埋め込まれているので、画像ファイルの送信は、データ列を送信する処理の一例である。あるいは、ユーザ端末20は読み出したかまたは抽出したデータ列を第2サーバ40に送信してもよい。例えば、ユーザ端末20は、URLパラメータにデータ列が設定されたURLを第2サーバ40に送信してもよい。第2サーバ40では、受信部41がそのデータ列(画像ファイルの場合もあり得る)を受信する。
【0058】
ステップS29では、格納部42がそのデータ列をデータベース50に格納する。受信部41が画像ファイルを受信した場合には、格納部42はその画像ファイルからデータ列を抽出してそのデータ列をデータベース50に格納してもよい。あるいは、格納部42はその画像ファイルをデータベース50に格納してもよい。画像ファイルにはデータ列が埋め込まれているので、画像ファイルの格納は、データ列を格納する処理の一例である。受信部41がデータ列を受信した場合には、格納部42はそのデータ列をデータベース50に格納してもよい。データ列がデータベース50に格納されることで、サーバ側(ネットワーク側)でそのデータ列を後から参照することができる。したがって、ステートフルな処理を実行することが可能になる。格納部42は、データ列と他の任意のデータ項目とを関連付けることでレコードを生成し、そのレコードをデータベース50に格納してもよい。
【0059】
[第3実施形態]
第3実施形態に係るブラウザ管理システム3は、第2実施形態で生成および格納されたデータ列を用いてサーバ側でブラウザを特定する仕組みを提供する。この仕組みは、ステートレスなプロトコルを用いるコンピュータシステム上でステートフルな処理を実現するための構成の一例である。
【0060】
図7はブラウザ管理システム3の機能構成の一例を示す図である。本実施形態では、ブラウザ管理システム3は、第2実施形態で示したものと同じ第1サーバ10および第2サーバ40と、データベース50に格納されたデータ列を参照する第3サーバ60とを備える。第1サーバ10および第2サーバ40と同様に、第3サーバ60もユーザ端末20のブラウザ21を特定するための処理を実行するコンピュータである。第1サーバ10、第2サーバ40、および第3サーバ60のそれぞれは、1以上のユーザ端末20と通信ネットワークを介して接続することができる。
【0061】
第3サーバ60は機能要素として受信部61および判定部62を備える。受信部61は、処理の対象となるデータ(以下では「処理対象データ」という)をユーザ端末20から受信する機能要素である。判定部62は、その処理対象データをデータベース50内のデータ列と比較することでブラウザ21を特定する機能要素である。第3サーバ60も一または複数のコンピュータ100で構成される。複数のコンピュータを用いる場合には、これらのコンピュータがインターネットやイントラネットなどの通信ネットワークを介して接続されることで、論理的に一つの第3サーバ60が構築される。コンピュータ100は、少なくとも1台のコンピュータを第3サーバ60として機能させるための第3プログラムを記憶する。第3プログラムは第3サーバ60の各機能要素を実現するためのコードを含む。第3サーバ60の各機能要素は、プロセッサ101または主記憶部102の上に第3プログラムを読み込ませてそのプログラムを実行させることで実現される。
【0062】
第1プログラムおよび第2プログラムと同様に、第3プログラムは有形の記録媒体に固定的に記録された上で提供されてもよいし、通信ネットワークを介して提供されてもよい。第3プログラムは第1プログラムおよび第2プログラムと共に提供されてもよいし、第1プログラムおよび第2プログラムの少なくとも一方とは別に提供されてもよい。
【0063】
本実施形態では第3サーバ60は第1サーバ10、第2サーバ40、およびウェブサーバ30のいずれとも異なるコンピュータであるが、サーバの構成はこれに限定されない。例えば、一つのサーバが、第1サーバ10、第2サーバ40、第3サーバ60、およびウェブサーバ30のうちの少なくとも二つのサーバの機能を備えてもよい。
【0064】
図8を参照しながら、ブラウザ管理システム3の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図8は、第3サーバ60の動作の一例を示すフローチャートである。ブラウザ管理システム3はブラウザ管理システム2(第2実施形態)と同じ処理(図6を参照)を実行することができ、その結果、データベース50にデータ列が格納される。図8は、或るウェブサイトにアクセスした或るブラウザ21のデータ列がデータベース50に格納された後にそのブラウザ21から処理対象データを受信した際の処理を示す。
【0065】
ステップS31では、第3サーバ60の受信部61がユーザ端末20から処理対象データを取得する。処理対象データはデータ列を含み得るが、処理対象データの具体的な内容および構成は限定されない。
【0066】
ステップS32では、判定部62がその処理対象データとデータベース50内のデータ列とを比較することでブラウザ21を特定する。判定部62は、処理対象データの少なくとも一部とデータベース50内の1以上のデータ列とを比較することで、処理対象データがデータ列を含むか否かを判定する。データベース50が画像ファイルを記憶している場合には、判定部62は画像ファイルからデータ列を抽出して比較を実行する。処理対象データが、データベース50内に存在するデータ列を含む場合には、判定部62は、そのデータ列に対応するブラウザ21から処理対象データが送られてきたと判定する。この結果、判定部62は、処理対象データを送信したブラウザ21を特定することができる。もし、処理対象データがデータベース50内のいずれのデータ列も含まない場合には、判定部62は処理対象データの送信元が不明であると判定する。
【0067】
判定部62によりブラウザ21が特定された後の処理は限定されない。第3サーバ60はブラウザ21を特定した後に任意の処理を実行することができる。あるいは、第3サーバ60がブラウザ21を特定した後に、ウェブサーバ30などの他のサーバが任意の処理を実行してもよい。例えば、ブラウザ21が特定された後に、第3サーバ60または他のサーバはステートフルなサービスを提供するための任意の処理を実行してもよい。
【0068】
[第4実施形態]
第4実施形態は、本開示に係るブラウザ管理システムをボランタリ・チェーン(voluntary chain:VC)でのアフィリエイト・トラッキングに適用した例である。
【0069】
図9および図10を参照しながら第4実施形態でのシステム構成を説明する。図9はブラウザ管理システム4の適用の一例を示す図である。図10はブラウザ管理システム4の機能構成の一例を示す図である。本実施形態では、サーバ側(ネットワーク側)はメディアサーバ110、VCウェブサーバ120、VC画像サーバ130、VCリダイレクタ140、および広告主サーバ150を含む。ユーザ端末20はこれらのサーバのそれぞれと通信ネットワーク(例えばインターネット)を介して接続することができる。
【0070】
メディアサーバ110は、ユーザ端末20に対して広告媒体を提供するコンピュータである。メディアサーバ110は、アフィリエイト広告を含むウェブページ(広告媒体)をユーザ端末20からの要求に応じて該ユーザ端末20に送信する。アフィリエイト広告とは、インターネット上に設置された広告媒体上に掲載される広告であって、該広告媒体の閲覧者(ユーザ)がその広告をきっかけに商品を購入した場合に成功報酬が媒体主に付与される形態の広告である。広告媒体とは、アフィリエイト広告を閲覧者に伝達する媒介手段であり、より具体的には、任意の情報が掲載されたウェブページである。広告媒体上でのアフィリエイト広告の表現方法は限定されず、例えば、バナー広告でもよい。
【0071】
VCウェブサーバ120はボランタリ・チェーンのウェブサーバであり、データ列を取得するためのスクリプトを提供するコンピュータである。そのスクリプトは、例えば、JavaScript(登録商標)でもよい。
【0072】
VC画像サーバ130は、データ列が埋め込まれた画像ファイルをユーザ端末20に送信するコンピュータである。VC画像サーバ130は第1、第2、および第3実施形態における第1サーバ10の一例であるということができる。VC画像サーバ130は機能要素として受信部131、画像生成部132、および送信部133を備える。受信部131は、ウェブページを表示するための処理を実行するユーザ端末20から画像ファイルの要求を受信する機能要素である。画像生成部132は、その要求に応答して画像ファイルを生成する機能要素である。送信部133は、データ列をキャッシュ22に格納するためにその画像ファイルをユーザ端末20に送信する機能要素である。受信部131、画像生成部132、および送信部133はそれぞれ、上記の受信部11、画像生成部12、および送信部13と同様の機能を実行する。
【0073】
VCリダイレクタ140は、データ列をサーバ側(ネットワーク側)に保存するコンピュータである。VCリダイレクタ140は第2および第3実施形態における第2サーバ40の一例であるということができる。VCリダイレクタ140は機能要素として受信部141および格納部142を備える。受信部141は、ユーザ端末20からデータ列を受信する機能要素である。格納部142は、そのデータ列をデータベース50に格納する機能要素である。受信部141および格納部142はそれぞれ、第2および第3実施形態における受信部41および格納部42と同様の機能を実行する。
【0074】
したがって、VC画像サーバ130およびVCリダイレクタ140はいずれも、ユーザ端末20のブラウザ21を特定するための処理を実行するコンピュータである。
【0075】
広告主サーバ150は、アフィリエイト広告の広告主により運営される仮想店舗をユーザに提供するコンピュータである。アフィリエイト広告をクリックすることで仮想店舗にアクセスしたユーザは、この仮想店舗で商品を購入することができる。商品とは、有償または無償で取引される任意の有体物または無体物であり、したがって、サービスの提供を含む概念である。商品の種類は何ら限定されない。
【0076】
図11を参照しながら、ブラウザ管理システム4の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図11は、ブラウザ管理システム4の動作の一例を示すシーケンス図である。
【0077】
ステップS41では、ユーザ端末20が、GETメソッドを用いたHTTPリクエストをメディアサーバ110に送信する。
【0078】
ステップS42では、メディアサーバ110がその要求で指定されたHTMLデータをユーザ端末20に送信する。このHTMLデータは<script>タグを含む。
【0079】
ステップS43では、ユーザ端末20がその<script>タグで示されるJavaScript(登録商標)を取得するためのHTTPリクエスト(GETメソッド)をVCウェブサーバ120に送信する。
【0080】
ステップS44では、VCウェブサーバ120がその要求に応答してJavaScript(登録商標)をユーザ端末20に送信する。
【0081】
ステップS45では、ユーザ端末20がそのスクリプトを実行して、GETメソッドを用いた画像要求をVC画像サーバ130に送信する。VC画像サーバ130では受信部131がその画像要求を受信する。ステップS45は上記のステップS22に対応する。
【0082】
ステップS46では、VC画像サーバ130の画像生成部132が、ユーザ端末20のブラウザ21を特定するためのデータ列を生成する。ステップS46はステップS23に対応する。
【0083】
ステップS47では、画像生成部132がそのデータ列を示す複数の画素を含む画像ファイルを生成する。ステップS47はステップS24に対応する。
【0084】
ステップS48では、VC画像サーバ130の送信部133がその画像ファイルをユーザ端末20に送信する。ステップS48はステップS25に対応する。
【0085】
ユーザ端末20はその画像ファイルを受信してデータ列をキャッシュ22に格納する。この格納処理はステップS26に対応する。したがって、ユーザ端末20は画像ファイルを格納してもよいし、画像ファイルから抽出したデータ列を格納してもよい。
【0086】
ステップS49では、ユーザ端末20がGETメソッドを用いて、そのデータ列を含むHTTPリクエストをVCリダイレクタ140に送信する。ステップS49はステップS28に対応する。したがって、ユーザ端末20は画像ファイルを送信してもよいし、画像ファイルから抽出したデータ列を送信してもよい。VCリダイレクタ140では受信部141がそのデータ列を受信する。
【0087】
ステップS50では、VCリダイレクタ140の格納部142がそのデータ列をデータベース50に格納する。ステップS50はステップS29に対応する。したがって、格納部142は画像ファイルを格納してもよいし、受信したデータ列または画像ファイルから抽出したデータ列を格納してもよい。
【0088】
格納部142は、データ列を他のデータ項目と関連付けることでレコードを生成し、そのレコードをデータベース50に格納してもよい。例えば、格納部142は、ユーザID、媒体主ID、広告主ID、およびトラッキングキーのうちの少なくとも一つをレコードに含めてもよい。このレコードにより、ユーザID、媒体主ID、広告主ID、およびトラッキングキーのうちの少なくとも一つがデータ列と関連付けられる。ここで、ユーザIDは、ユーザを一意に特定するための識別子である。媒体主IDは、広告媒体の出稿者である媒体主を一意に特定するための識別子である。広告主IDは、アフィリエイト広告の広告主を一意に特定するための識別子である。トラッキングキーは、特定のウェブサイト内でのユーザの操作を追跡するために用いられる識別子である。
【0089】
ステップS51では、VCリダイレクタ140が、リダイレクトのために用いられるHTTPステータスコードである「302 Found」をユーザ端末20に送信する。ユーザ端末20はそのデータ信号を受信する。
【0090】
ステップS52では、ユーザ端末20がその「302 Found」に応答して、キャッシュ22からデータ列を読み出し、そのデータ列を含むリクエスト(GETメソッド)を広告主サーバ150に送信する。
【0091】
ステップS53では、広告主サーバ150がそのリクエストに応答して、指定されたHTMLデータをユーザ端末20に送信する。この広告主サーバ150は、ステップS52で受信したデータ列が既にデータベース50内に記憶されていることに基づいて、ステートフルな処理を実行することができる。
【0092】
[第5実施形態]
第5実施形態は、本開示に係るブラウザ管理システムをアナリティクスに適用した例である。アナリティクスとは、ユーザがどのサイトからアクセスしてきたかを分析したり、ユーザがウェブサイト内でどのような経路を辿るかなどを分析したりする手法のことをいう。
【0093】
図12および図13を参照しながら第5実施形態でのシステム構成を説明する。図12はブラウザ管理システム5の適用の一例を示す図である。図13はブラウザ管理システム5の機能構成の一例を示す図である。本実施形態では、サーバ側(ネットワーク側)はメディアサーバ110、VCウェブサーバ120、VC画像サーバ130、およびVCビーコンサーバ160を含む。ユーザ端末20はこれらのサーバのそれぞれと通信ネットワーク(例えばインターネット)を介して接続することができる。
【0094】
メディアサーバ110、VCウェブサーバ120、およびVC画像サーバ130の構成は第4実施形態と同じである。
【0095】
VCビーコンサーバ160は、データ列をサーバ側(ネットワーク側)に保存するコンピュータである。VCビーコンサーバ160は第2および第3実施形態における第2サーバ40の一例であるということができる。VCビーコンサーバ160は機能要素として受信部161および格納部162を備える。受信部161は、ユーザ端末20からデータ列を受信する機能要素である。格納部162は、そのデータ列をデータベース50に格納する機能要素である。受信部161および格納部162はそれぞれ、上記の受信部41および格納部42と同様の機能を実行する。
【0096】
したがって、VC画像サーバ130およびVCビーコンサーバ160はいずれも、ユーザ端末20のブラウザ21を特定するための処理を実行するコンピュータである。
【0097】
図14を参照しながら、ブラウザ管理システム5の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図14は、ブラウザ管理システム5の動作の一例を示すシーケンス図である。
【0098】
ステップS61~S68の処理は、第5実施形態におけるステップS41~S48の処理と同じである。ユーザ端末20は、ステップS68でVC画像サーバ130から送られてきた画像ファイルを受信してデータ列をキャッシュ22に格納する。ユーザ端末20は画像ファイルを格納してもよいし、画像ファイルから抽出したデータ列を格納してもよい。
【0099】
ステップS69では、ユーザ端末20がGETメソッドを用いて、そのデータ列を含むHTTPリクエストをVCビーコンサーバ160に送信する。ステップS69は第2実施形態におけるステップS28に対応する。したがって、ユーザ端末20は画像ファイルを送信してもよいし、画像ファイルから抽出したデータ列を送信してもよい。VCビーコンサーバ160では受信部161がそのデータ列を受信する。
【0100】
ステップS70では、VCビーコンサーバ160の格納部162がそのデータ列をデータベース50に格納する。ステップS70はステップS29に対応する。したがって、格納部162は画像ファイルを格納してもよいし、受信したデータ列または画像ファイルから抽出したデータ列を格納してもよい。第4実施形態と同様に、格納部162は、データ列を他のデータ項目と関連付けることでレコードを生成し、そのレコードをデータベース50に格納してもよい。例えば、格納部162は、ユーザID、媒体主ID、広告主ID、およびトラッキングキーのうちの少なくとも一つをレコードに含めてもよい。
【0101】
ステップS71では、VCビーコンサーバ160が、アナリティクスのために用いられる透過画像をユーザ端末20に送信する。ユーザ端末20はその透過画像を受信する。この透過画像は、ブラウザ21を特定するためのデータ列が埋め込まれた画像ファイルとは異なる画像であることに留意されたい。
【0102】
[第6実施形態]
第6実施形態は、本開示に係るブラウザ管理システムをターゲティングに適用した例である。ターゲティングとは、ユーザがインターネット上でどのウェブサイトにアクセスしたかを追跡する手法のことをいう。
【0103】
図15および図16を参照しながら第6実施形態でのシステム構成を説明する。図15はブラウザ管理システム6の適用の一例を示す図である。図16はブラウザ管理システム6の機能構成の一例を示す図である。本実施形態では、サーバ側(ネットワーク側)はメディアサーバ110、VCウェブサーバ120、VC画像サーバ130、VCビーコンサーバ160、および広告サーバ170を含む。ユーザ端末20はこれらのサーバのそれぞれと通信ネットワーク(例えばインターネット)を介して接続することができる。
【0104】
メディアサーバ110、VCウェブサーバ120、VC画像サーバ130、およびVCビーコンサーバ160の構成は第5実施形態と同じである。
【0105】
広告サーバ170は、広告媒体上に載せるアフィリエイト広告をユーザに提供するコンピュータである。広告サーバ170は、ブラウザ21から送信された処理対象データとデータベース50内のデータ列とを比較してブラウザ21を特定する処理を実行してもよい。したがって、広告サーバ170は第3実施形態における第3サーバ60の一例であるということができる。広告サーバ170は機能要素として受信部171および判定部172を備える。受信部171は、処理対象データをユーザ端末20から受信する機能要素である。判定部172は、その処理対象データをデータベース50内のデータ列と比較することでブラウザ21を特定する機能要素である。受信部171および判定部172はそれぞれ、上記の受信部61および判定部62と同様の機能を実行する。
【0106】
したがって、VC画像サーバ130、VCビーコンサーバ160、および広告サーバ170はいずれも、ユーザ端末20のブラウザ21を特定するための処理を実行するコンピュータである。
【0107】
図17を参照しながら、ブラウザ管理システム6の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図17は、ブラウザ管理システム6の動作の一例を示すシーケンス図である。
【0108】
ステップS81~S91の処理は、第5実施形態におけるステップS61~S71の処理と同じである。
【0109】
ステップS92では、ユーザ端末20が、アフィリエイト広告を取得するためのHTTPリクエスト(GETメソッド)を広告サーバ170に送信する。このリクエストは、キャッシュ22から読み出されたデータ列を含む。広告サーバ170では受信部171がそのリクエストを受信する。この受信はステップS31に対応し、したがって、HTTPリクエストは処理対象データに相当する。
【0110】
ステップS93では、広告サーバ170の判定部172がそのリクエストに基づいてデータベース50を参照することで、リクエストに含まれているものと同じデータ列がデータベース50内に記憶されているか否かを判定する。判定部172はその判定結果に基づいてブラウザ21を特定することができる。ステップS93はステップS32に対応する。広告サーバ170は、その判定結果に基づいて、ターゲティングに必要な更なる処理(この処理はステートフルな処理であるといえる。)を実行できる。
【0111】
ステップS94では、広告サーバ170がそのリクエストに応答して、指定されたアフィリエイト広告のデータ(広告データ)をユーザ端末20に送信する。ユーザ端末20はその広告データを受信し、アフィリエイト広告を含む広告媒体をモニタ上に表示する。
【0112】
第4、第5、および第6実施形態では、ユーザ端末20はGETメソッドを用いてHTTPリクエストを送信する。しかし、GETメソッドの利用は必須ではなく、ユーザ端末20は他のHTTPリクエストメソッド(例えばPOSTメソッド)を用いてもよい。
【0113】
[効果]
以上説明したように、本発明の一側面に係るブラウザ管理システムは、少なくとも一つのプロセッサを備え、少なくとも一つのプロセッサが、ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成し、データ列を示す複数の画素を含む画像ファイルを生成し、データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信する。
【0114】
本発明の一側面に係るブラウザ管理方法は、少なくとも一つのプロセッサにより実行されるブラウザ管理方法であって、ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成するステップと、データ列を示す複数の画素を含む画像ファイルを生成するステップと、データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信するステップとを含む。
【0115】
本発明の一側面に係るブラウザ管理プログラムは、ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成するステップと、データ列を示す複数の画素を含む画像ファイルを生成するステップと、データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信するステップとをコンピュータシステムに実行させる。
【0116】
このような側面においては、ブラウザを特定するためのデータ列を示す画像ファイルがユーザ端末のキャッシュに格納される。したがって、その画像ファイルを用いることで、HTTPクッキーを用いることなくブラウザを特定することができる。また、ブラウザを特定するためのデータ列を、従来から広く用いられている画像ファイルに埋め込むことで、特定のサービスに依存しない形でそのデータ列をキャッシュに保存し、必要に応じてそのデータ列をキャッシュから読み出すことができる。したがって、HTTPクッキーに代わるこの新たな技術を様々なオンラインサービスに適用することができる。すなわち、データ列を画像ファイルに埋め込むこの新たな技術は汎用性が高い。
【0117】
他の側面に係るブラウザ管理システムでは、少なくとも一つのプロセッサが、データ列を、複数の画素に対応する複数の画素値に変換することで画像ファイルを生成してもよい。データ列を画素値に変換することで、データ列を効率的に画像ファイルに埋め込むことができる。
【0118】
他の側面に係るブラウザ管理システムでは、複数の画素がRGBまたはグレースケールで表されてもよい。データ列をRGBまたはグレースケールの画素値に変換することで、データ列を効率的に画像ファイルに埋め込むことができる。
【0119】
他の側面に係るブラウザ管理システムでは、ウェブページが、画像ファイルを取得するためのスクリプトを含み、少なくとも一つのプロセッサが、ユーザ端末でスクリプトが実行されたことに応答して、データ列の生成と、画像ファイルの生成と、画像ファイルの送信とを実行してもよい。ウェブページ内のスクリプトに従って画像ファイルを生成および送信することで、データ列が必要なタイミングで画像ファイルをユーザ端末に提供することができる。
【0120】
他の側面に係るブラウザ管理システムでは、少なくとも一つのプロセッサが、ユーザ端末によりキャッシュから読み出されて送信されたデータ列を取得してもよい。ユーザ端末のキャッシュに記憶されていたデータ列を取得することで、サーバ側でそのデータ列を保存することができ、その保存されたデータ列を用いてブラウザを特定することが可能になる。
【0121】
他の側面に係るブラウザ管理システムでは、データ列を含む文字列をユーザ端末から受信することでデータ列を取得してもよい。この場合には、サーバ側で画像ファイルからデータ列を抽出する必要がないので、サーバ側の処理負荷を低減することができる。
【0122】
他の側面に係るブラウザ管理システムでは、少なくとも一つのプロセッサが、ユーザ端末から画像ファイルを受信して該画像ファイルからデータ列を抽出することで、データ列を取得してもよい。この場合には、ユーザ端末で画像ファイルからデータ列を抽出する必要がないので、ユーザ端末の処理負荷を低減することができる。
【0123】
他の側面に係るブラウザ管理システムでは、少なくとも一つのプロセッサが、取得されたデータ列を記憶装置に格納してもよい。サーバ側でデータ列を保存することで、その保存されたデータ列を用いてブラウザを特定することが可能になる。
【0124】
他の側面に係るブラウザ管理システムでは、少なくとも一つのプロセッサが、データ列がデータベースに格納された後に、ユーザ端末から処理対象データを取得し、処理対象データと記憶装置内のデータ列とを比較し、処理対象データがデータ列を含む場合に、処理対象データがブラウザから送信されたと判定してもよい。ユーザ端末から送られてきたデータ(処理対象データ)を記憶装置内のデータ列と照合することでブラウザを特定することができる。
【0125】
本発明の一側面に係るクライアントプログラムは、上記のブラウザ管理システムから画像ファイルを受信するステップと、データ列をキャッシュに格納するステップとをコンピュータに実行させる。このような側面においては、ブラウザを特定するためのデータ列がユーザ端末のキャッシュに格納される。したがって、そのデータ列を用いることで、HTTPクッキーを用いることなくブラウザを特定することができる。
【0126】
[変形例]
以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能である。
【0127】
ブラウザ管理システムの構成は上記の各実施形態に限定されず、ブラウザ管理システムは1以上の任意のサーバを用いて構成されてよい。いずれにしても、ブラウザ管理システムは少なくとも一つのプロセッサを備える。ブラウザ管理システムが複数のプロセッサを備える場合には、第1の処理を実行するプロセッサは、第2の処理を実行するプロセッサと同じでもよいし異なってもよい。「少なくとも一つのプロセッサが第1の処理および第2の処理を実行する」ことは、どのプロセッサがどの処理を実行するかについて何ら限定しないことを意味する。
【0128】
上記のいくつかの実施形態ではデータベース50がデータ列を記憶するが、記憶装置はデータベース50に限定されない。ブラウザ管理システムは、データベース以外の記憶装置(例えば、任意の種類のメモリ)にデータ列を格納してもよい。
【0129】
少なくとも一つのプロセッサにより実行されるブラウザ管理方法の処理手順は上記実施形態での例に限定されない。例えば、上述したステップ(処理)の一部が省略されてもよいし、別の順序で各ステップが実行されてもよい。また、上述したステップのうちの任意の2以上のステップが組み合わされてもよいし、ステップの一部が修正または削除されてもよい。あるいは、上記の各ステップに加えて他のステップが実行されてもよい。
【符号の説明】
【0130】
1~6…ブラウザ管理システム、10…第1サーバ、11…受信部、12…画像生成部、13…送信部、20…ユーザ端末、21…ブラウザ、22…キャッシュ、30…ウェブサーバ、40…第2サーバ、41…受信部、42…格納部、50…データベース(記憶装置)、60…第3サーバ、61…受信部、62…判定部、110…メディアサーバ、120…VCウェブサーバ、130…VC画像サーバ、131…受信部、132…画像生成部、133…送信部、140…VCリダイレクタ、141…受信部、142…格納部、150…広告主サーバ、160…VCビーコンサーバ、161…受信部、162…格納部、170…広告サーバ、171…受信部、172…判定部。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17