WO2020008600A1

WO2020008600A1 - ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム

Info

Publication number: WO2020008600A1
Application number: PCT/JP2018/025568
Authority: WO
Inventors: 信敬伊藤; 津留　雅文
Original assignee: バリューコマース株式会社
Priority date: 2018-07-05
Filing date: 2018-07-05
Publication date: 2020-01-09
Also published as: US20210120074A1; US11258845B2; EP3819779A4; JP7145215B2; EP3819779A1; JPWO2020008600A1

Abstract

一実施形態に係るブラウザ管理システムは、少なくとも一つのプロセッサを備える。少なくとも一つのプロセッサは、（Ａ）ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成し、（Ｂ）データ列を示す複数の画素を含む画像ファイルを生成し、（Ｃ）データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信する。

Description

ブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラム

　本発明の一側面はブラウザ管理システム、ブラウザ管理方法、ブラウザ管理プログラム、およびクライアントプログラムに関する。

　ユーザ端末のブラウザを管理するための仕組みが知られている。例えば、特許文献１には、トラッキングサーバーサイトを用いてユーザのアクティビティをトラッキングする方法が記載されている。この方法の第１プロセスでは、ユーザ端末においてバナー広告がクリックされた際に、トラッキングサーバーサイトがクリック情報に基づくクッキー用データを作成してユーザ端末に送信する。第２プロセスでは、広告主サイトが、ユーザ端末からクッキー用データを受信し、クッキー用データに基づいてクッキーをユーザ端末に書き込む。第３プロセスでは、商取引が完了した際に、広告主サイトがユーザ端末からクッキーを取得し、そのクッキーの記録情報を含むトラッキング電文を作成してトラッキングサーバーサイトに送信する。

特許第４６４７７１７号公報

　特許文献１に記載の技術はＨＴＴＰクッキー（ＨＴＴＰ　ｃｏｏｋｉｅ）の利用を前提とする。しかし、ＨＴＴＰクッキーを利用できない環境も存在するので、ＨＴＴＰクッキー以外の手法でブラウザを特定することが望まれている。

　本発明の一側面に係るブラウザ管理システムは、少なくとも一つのプロセッサを備え、少なくとも一つのプロセッサが、ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成し、データ列を示す複数の画素を含む画像ファイルを生成し、データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信する。

　本発明の一側面に係るブラウザ管理方法は、少なくとも一つのプロセッサにより実行されるブラウザ管理方法であって、ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成するステップと、データ列を示す複数の画素を含む画像ファイルを生成するステップと、データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信するステップとを含む。

　本発明の一側面に係るブラウザ管理プログラムは、ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成するステップと、データ列を示す複数の画素を含む画像ファイルを生成するステップと、データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信するステップとをコンピュータシステムに実行させる。

　このような側面においては、ブラウザを特定するためのデータ列を示す画像ファイルがユーザ端末のキャッシュに格納される。したがって、その画像ファイルを用いることで、ＨＴＴＰクッキーを用いることなくブラウザを特定することができる。

　本発明の一側面によれば、ＨＴＴＰクッキー以外の手法でブラウザを特定することができる。

第１実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。実施形態に係るブラウザ管理システムで用いられるコンピュータの一般的なハードウェア構成を示す図である。ユーザ端末の動作の一例を示すフローチャートである。第１実施形態に係るブラウザ管理システムの動作の一例を示すシーケンス図である。第２実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。第２実施形態に係るブラウザ管理システムの動作の一例を示すシーケンス図である。第３実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。第３実施形態に係るブラウザ管理システムの動作の一例を示すフローチャートである。第４実施形態に係るブラウザ管理システムの適用の一例を示す図である。第４実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。第４実施形態に係るブラウザ管理システムの動作の一例を示すシーケンス図である。第５実施形態に係るブラウザ管理システムの適用の一例を示す図である。第５実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。第５実施形態に係るブラウザ管理システムの動作の一例を示すシーケンス図である。第６実施形態に係るブラウザ管理システムの適用の一例を示す図である。第６実施形態に係るブラウザ管理システムの機能構成の一例を示す図である。第６実施形態に係るブラウザ管理システムの動作の一例を示すシーケンス図である。

　以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一または同等の要素には同一の符号を付し、重複する説明を省略する。

　［システムの概要］
　いくつかの実施形態において、ブラウザ管理システムは、ユーザ端末のブラウザを特定するための仕組みを提供するコンピュータシステムである。このブラウザ管理システムにより、ステートレス（ｓｔａｔｅｌｅｓｓ）なプロトコルを用いるコンピュータシステム上でステートフル（ｓｔａｔｅｆｕｌ）な処理を実現することが可能になる。

　ステートレスとは、現在の状態を示すデータをシステムが保持しない方式のことをいう。ステートレスなプロトコルの例としてＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）が挙げられるが、これに限定されない。一方、ステートフルとは、現在の状態を表すデータをシステムが保持し、その状態が処理に反映される方式のことをいう。

　ステートフルな処理により様々なサービスを実現することができる。そのサービスの例として、電子商取引（ＥＣ）、コンバージョン・トラッキング（ｃｏｎｖｅｒｓｉｏｎ　ｔｒａｃｋｉｎｇ）、アフィリエイト・トラッキング（ａｆｆｉｌｉａｔｅ　ｔｒａｃｋｉｎｇ）、アナリティクス（ａｎａｌｙｔｉｃｓ）、ターゲティング（ｔａｒｇｅｔｉｎｇ）、および不正アクセス対策が挙げられる。しかし、ステートフルな処理を伴うサービスの種類はこれらに限定されるものではない。ブラウザ管理システムは任意のサービスのために構築することができる。

　ステートフルな処理を実現するために、ブラウザ管理システムは、従来から知られているＨＴＴＰクッキーを用いるのではなく、その従来技術とは異なる新たな手法を用いる。具体的には、ブラウザ管理システムは、ブラウザを特定するためのデータ列（以下では単に「データ列」ともいう。）が埋め込まれた画像ファイル（以下では単に「画像ファイル」ともいう。）をユーザ端末に送信することで、そのデータ列をユーザ端末内に記憶させる。このデータ列が、ステートフルな処理を実現するために用いられる。以下では、いくつかの実施形態を例として示しながら、本開示におけるブラウザ管理システムについて詳細に説明する。

　［第１実施形態］
　図１は、第１実施形態に係るブラウザ管理システム１の機能構成の一例を示す図である。本実施形態では、ブラウザ管理システム１は第１サーバ１０を備える。第１サーバ１０は１以上のユーザ端末２０と通信ネットワークを介して接続することができる。本実施形態では、ユーザ端末２０はウェブサーバ３０と通信ネットワークを介して接続することもできる。コンピュータ同士をつなぐ通信ネットワークの構成は何ら限定されない。例えば、通信ネットワークはインターネットおよびイントラネットの少なくとも一つを用いて構築されてもよい。

　ユーザ端末２０は、任意のオンラインサービスを受ける人であるユーザが操作するコンピュータである。ユーザ端末２０はブラウザ２１およびキャッシュ２２を備える。ブラウザ２１は、ウェブページをモニタ上に表示するためのソフトウェアである。ユーザ端末２０は複数種類のブラウザ２１を備えてもよい。キャッシュ２２は、データを一時的にコンピュータに保存する機能である。キャッシュ２２の実現方法は限定されず、例えば、キャッシュメモリ、ディスクキャッシュ、またはキャッシュファイルを用いてキャッシュ２２が実現されてもよい。ユーザ端末として用いられるコンピュータの種類は限定されない。例えば、ユーザ端末は携帯型または据置型のパーソナルコンピュータであってもよい。あるいは、ユーザ端末は、高機能携帯電話機（スマートフォン）、携帯電話機、携帯情報端末（ＰＤＡ）、タブレットなどの携帯端末でもよい。

　ウェブサーバ３０は、ステートフルなサービスを提供可能なウェブサイト（以下では単に「ウェブサイト」という。）をユーザ端末２０に提供するコンピュータである。ウェブサイトとは、特定のドメイン名の下に置かれた１以上のウェブページの集合である。ウェブページとは、ブラウザで閲覧可能な１ページ分の文書である。ウェブサイトの例としてＥＣサイト、ニュースサイト、ポータルサイト、ブログサイト、およびソーシャル・ネットワーキング・サービス（ＳＮＳ）サイトが挙げられる。しかし、ウェブサイトの例はこれらに限定されない。ウェブサイトが何ら限定されないことに対応して、個々のウェブページの内容（例えば、掲載される情報、または実行可能な機能）も何ら限定されない。

　第１サーバ１０は、ユーザ端末２０のブラウザ２１を特定するための処理を実行するコンピュータである。より具体的には、第１サーバ１０は、データ列が埋め込まれた画像ファイルをユーザ端末２０に送信する。第１サーバ１０は機能要素として受信部１１、画像生成部１２、および送信部１３を備える。受信部１１は、ウェブページを処理するユーザ端末２０から画像ファイルの要求を受信する機能要素である。画像生成部１２は、その要求に応答して、データ列が埋め込まれた画像ファイルを生成する機能要素である。送信部１３は、データ列をキャッシュ２２に格納するためにその画像ファイルをユーザ端末２０に送信する機能要素である。

　第１サーバ１０は一または複数のコンピュータで構成される。複数のコンピュータを用いる場合には、これらのコンピュータがインターネットやイントラネットなどの通信ネットワークを介して接続されることで、論理的に一つの第１サーバ１０が構築される。

　図２は第１サーバ１０を構成するコンピュータ１００の一般的なハードウェア構成を示す。例えば、コンピュータ１００はプロセッサ１０１、主記憶部１０２、補助記憶部１０３、通信制御部１０４、入力装置１０５、および出力装置１０６を備える。プロセッサ１０１はオペレーティングシステムおよびアプリケーションプログラムを実行する。主記憶部１０２は例えばＲＯＭおよびＲＡＭで構成される。補助記憶部１０３は例えばハードディスクまたはフラッシュメモリで構成され、一般に主記憶部１０２よりも大量のデータを記憶する。補助記憶部１０３は、少なくとも１台のコンピュータを第１サーバ１０として機能させるための第１プログラムを記憶する。通信制御部１０４は例えばネットワークカードまたは無線通信モジュールで構成される。入力装置１０５は例えばキーボード、マウス、タッチパネルなどで構成される。出力装置１０６は例えばモニタおよびスピーカで構成される。

　第１サーバ１０の各機能要素は、プロセッサ１０１または主記憶部１０２の上に第１プログラムを読み込ませてそのプログラムを実行させることで実現される。第１プログラムは第１サーバ１０の各機能要素を実現するためのコードを含む。プロセッサ１０１は第１プログラムに従って、通信制御部１０４、入力装置１０５、または出力装置１０６を動作させ、主記憶部１０２または補助記憶部１０３におけるデータの読み出しおよび書き込みを行う。この処理により第１サーバ１０の各機能要素が実現される。処理に必要なデータまたはデータベースは主記憶部１０２または補助記憶部１０３内に格納されてもよい。

　第１プログラムは、例えば、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、半導体メモリなどの有形の記録媒体に固定的に記録された上で提供されてもよい。あるいは、第１プログラムは、搬送波に重畳されたデータ信号として通信ネットワークを介して提供されてもよい。提供された第１プログラムは補助記憶部１０３に格納されてもよい。

　本実施形態では第１サーバ１０はウェブサーバ３０とは別のコンピュータであるが、サーバの構成はこれに限定されない。例えば、一つのサーバが第１サーバ１０およびウェブサーバ３０の双方の機能を備えてもよい。

　図３を参照しながら、データ列の取得に関するユーザ端末２０での処理について説明する。図３はユーザ端末２０の動作の一例を示すフローチャートである。

　ステップＳ１１では、ユーザ端末２０は、ユーザがウェブサイトのウェブページを選択したことに応答して、そのウェブページをウェブサーバ３０から受信する。ウェブページの選択方法は限定されない。例えば、ウェブページは、リンクがクリックされることで選択されてもよいし、ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）が直接に入力されることで選択されてもよい。

　ステップＳ１２では、ユーザ端末２０はデータ列を取得するためのＪａｖａＳｃｒｉｐｔ（登録商標）を取得する。例えば、ユーザ端末２０は受信したウェブページに記述されている＜ｓｃｒｉｐｔ＞タグに従ってそのスクリプトを取得する。スクリプトはブラウザ２１上で実行される比較的簡易なプログラムである。ユーザ端末２０はスクリプトを実行することで後続のステップ（例えば、ステップＳ１３～Ｓ１７の少なくとも一部）を実行する。なお、スクリプトはＪａｖａＳｃｒｉｐｔ（登録商標）に限定されるものではなく、他のスクリプト言語が用いられてもよい。

　ステップＳ１３では、ユーザ端末２０は、ウェブサイトに対応するデータ列がキャッシュ２２内に記憶されているか否かを調べる。データ列が既にキャッシュ２２内に存在する場合には（ステップＳ１３においてＹＥＳ）、データ列を新たに取得する必要が無いので、ユーザ端末２０はデータ列を第１サーバ１０に要求しない。一方、データ列がキャッシュ２２内に存在しない場合には（ステップＳ１３においてＮＯ）、処理はステップＳ１４に進む。

　ステップＳ１４では、ユーザ端末２０は、ウェブサイトに対応するデータ列を第１サーバ１０から取得する。ユーザ端末２０は、データ列が埋め込まれた画像ファイルを第１サーバ１０から受信することでそのデータ列を取得する。

　ステップＳ１５では、ユーザ端末２０はそのデータ列をキャッシュ２２に格納する。ユーザ端末２０は画像ファイルをキャッシュ２２に格納してもよい。画像ファイルはデータ列を含むので、画像ファイルの格納はデータ列の格納の一例である。あるいは、ユーザ端末２０は画像ファイルからデータ列を抽出して、そのデータ列をキャッシュ２２に格納してもよい。データ列がキャッシュ２２に格納されることで、ユーザ端末２０はそのデータ列をサーバ側（ネットワーク側）に送信することができる。要求を受信するサーバはそのデータ列を取得することで、ブラウザ２１の現在の状態に基づく処理を実行することができ、これによりステートフルな処理が実現可能になる。

　ステップＳ１６では、ユーザ端末２０はキャッシュ２２からデータ列を読み出してそのデータ列を所定のサーバに送信する。データ列の送信先は限定されず、例えば、リダイレクトサーバ、ビーコンサーバ、およびウェブサーバ３０のいずれかであってもよい。

　ステップＳ１７では、ユーザ端末２０は受信したウェブページをモニタ上に表示する。

　ステップＳ１１～Ｓ１７は、ユーザ端末２０のブラウザ２１上にウェブページを表示するための処理である。この処理を実行するためにクライアントプログラムが用意される。そのクライアントプログラムがユーザ端末２０にインストールされることで、ユーザ端末２０はステップＳ１１～Ｓ１７の処理を実行できる。第１プログラムと同様に、クライアントプログラムは有形の記録媒体に固定的に記録された上で提供されてもよいし、通信ネットワークを介して提供されてもよい。クライアントプログラムは他のプログラムとは別に提供可能である。

　図４を参照しながら、画像ファイル（データ列）の提供に関するブラウザ管理システム１の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図４はブラウザ管理システム１の動作の一例を示すシーケンス図である。図４は、表示されようとするウェブサイトに対応するデータ列が未だキャッシュ２２に格納されていないことを前提とする。

　ステップＳ２１では、ユーザ端末２０が、ユーザにより選択されたウェブページに関連する処理を実行する。「ウェブページに関連する処理」とは、ウェブページをユーザ端末２０のブラウザ２１上に表示するための処理であり、上記のステップＳ１１～Ｓ１７の少なくとも一部を含む。

　ステップＳ２２では、ユーザ端末２０が画像要求を第１サーバ１０に送信する。この処理は、ステップＳ１４の一部であるということができる。画像要求は、画像ファイルを第１サーバ１０から取得するためのデータ信号である。第１サーバ１０では受信部１１がその画像要求を受信する。

　ステップＳ２３では、画像生成部１２が、ブラウザ２１を特定するためのデータ列を生成する。「ブラウザを特定する」とは、一のウェブサイトにおいて一つのブラウザを他のブラウザと区別して認識することをいう。データ列はブラウザ２１を特定する識別子であって、ユーザ端末２０を特定する識別子ではないことに留意されたい。データ列とは、コンピュータが処理可能な複数の文字で構成される一つの文字列で表現されるデータである。画像生成部１２はウェブサイトにおいてブラウザ２１を特定するために十分な情報量をデータ列が含むように該データ列を生成する。その情報量は２^ｎ（すなわち、ｎビット）で表すことができ、その指数ｎを大きくするほどデータ列の情報量を多くすることができる。

　一のウェブサイトにおいてブラウザ２１を特定することができる限り、指数ｎの具体的な値は任意に定められてよい。また、ブラウザ２１をそのように特定することができる限り、画像生成部１２は任意の手法を用いてデータ列を生成してよい。データ列は、将来、別のブラウザまたは同一ブラウザのために再度用いられる可能性がある値でもよいし、一回だけ生成される唯一の値（すなわち、将来、別のブラウザまたは同一ブラウザのために再度用いられる可能性が無い、使い捨ての値。）でもよい。データ列の構成は限定されない。例えば、画像生成部１２はシステム時刻（例えば、現在日時）およびＩＰアドレスの少なくとも一方を含むデータ列を生成してもよい。より具体的な例として、データ列は、第１サーバ１０のＩＰアドレスと、第１サーバ１０でユーザ端末２０のために実行されているスレッドを示すスレッドＩＤと、システム時刻との組合せを用いて生成されてもよい。あるいは、データ列は、ユーザ端末２０のＩＰアドレスおよびポート番号と、第１サーバ１０のＩＰアドレスおよびポート番号と、システム時刻との組合せを用いて生成されてもよい。あるいは、画像生成部１２は、乱数、自動インクリメント、またはシーケンスを利用してデータ列を生成してもよい。

　ステップＳ２４では、画像生成部１２がそのデータ列を示す複数の画素を含む画像ファイルを生成する。具体的には、画像生成部１２はデータ列を複数の画素の複数の画素値に変換することで画像ファイルを生成する。画像ファイルのカラーモード（色を設定する方法）、画素数、および生成方法は限定されず、画像生成部１２は任意の手法を用いて画像ファイルを生成してよい。

　一例として、画像ファイルはＲＧＢカラーで表されてもよい。複数の画素がＲＧＢ（赤、緑、青）で表される場合には、画像生成部１２はデータ列を複数の画素の複数の画素値（ＲＧＢ値）に変換することで、そのデータ列を複数の画素で表現し、該複数の画素を含む画像ファイルを生成する。なお、個々の画素は、ＲＧＢ値に加えてさらなる値で定義されてもよく、例えば、アルファ・ブレンディング（Ａｌｐｈａ　Ｂｌｅｎｄｉｎｇ）で用いられる、透過度を示すアルファ値をさらに用いて定義されてもよい。ＲＧＢの各色の情報量は８ビットなので、１画素の情報量は２^{（８×３）}（すなわち、２４ビット）である。データ列をｋ個の画素のＲＧＢ値に変換するならば、画像生成部１２は２^{（８×３×ｋ）}の情報量をｋ個の画素に埋め込むことができる。

　別の例として、画像ファイルはグレースケールで表されてもよい。複数の画素がグレースケールで表される場合には、画像生成部１２はデータ列を複数の画素の複数の画素値（グレースケール値）に変換することで、そのデータ列を複数の画素で表現し、該複数の画素を含む画像ファイルを生成する。グレースケールの情報量は８ビットなので、１画素の情報量は２^８（すなわち、８ビット）である。データ列をｋ個の画素のグレースケール値に変換するならば、画像生成部１２は２^{（８×ｋ）}の情報量をｋ個の画素に埋め込むことができる。

　上記の通りデータ列の情報量は限定されないので、そのデータ列が埋め込まれる画素の個数も限定されない。例えば、データ列を４個のＲＧＢ画素で表すとすれば、画像生成部１２は、情報量が２^{（８×３×４）}＝２^９６（すなわち、９６ビット）であるデータ列が埋め込まれた画像ファイルを生成することができる。データ列を９個のＲＧＢ画素で表すとすれば、画像生成部１２は、情報量が２^{（８×３×９）}＝２^２１６（すなわち、２１６ビット）であるデータ列が埋め込まれた画像ファイルを生成することができる。データ列を１０個のグレースケール画素で表すとすれば、画像生成部１２は、情報量が２^{（８×１０）}＝２^８０（すなわち、８０ビット）であるデータ列が埋め込まれた画像ファイルを生成することができる。データ列を１６個のグレースケール画素で表すとすれば、画像生成部１２は、情報量が２^{（８×１６）}＝２^１２８（すなわち、１２８ビット）であるデータ列が埋め込まれた画像ファイルを生成することができる。画像ファイルのカラーモードの種類にかかわらず、画素の個数ｋは２以上であればいくつでもよく、データ列の情報量に応じて決めることができる。

　画像生成部１２は、データ列が埋め込まれた複数の画素で構成される画像ファイルを生成してもよい。あるいは、画像生成部１２は、データ列が埋め込まれた複数の画素と、データ列が埋め込まれていない１以上の画素とで構成される画像ファイルを生成してもよい。すなわち、画像生成部１２は、データ列に加えて他の情報も含む画像ファイルを生成してもよい。

　生成される画像ファイルの形状は限定されない。例えば、画像ファイルの形状は正方形、長方形、直線状、ほぼ円形、または他の多角形でもよいし、より複雑な形状でもよい。ＲＧＢカラーの画像ファイルである場合には、例えば、画像生成部１２は２（画素）×２（画素）の画像ファイル（情報量は９６ビット）を生成してもよいし、３（画素）×３（画素）の画像ファイル（情報量は２１６ビット）を生成してもよい。

　ステップＳ２５では、送信部１３が画像ファイルをユーザ端末２０に送信する。この画像ファイルは、画像要求に対する応答であるといえる。ユーザ端末２０はその画像ファイルを受信する。この受信処理はステップＳ１４の一部であるということができる。

　ステップＳ２６では、ユーザ端末２０がデータ列をキャッシュ２２に格納する。この処理はステップＳ１５に対応する。ユーザ端末２０は受信した画像ファイルをキャッシュ２２に格納してもよいし、画像ファイルから抽出したデータ列をキャッシュ２２に格納してもよい。画像ファイルにはデータ列が埋め込まれているので、キャッシュ２２への画像ファイルの格納は、データ列をキャッシュ２２に格納する処理の一例である。ステップＳ２６よりも後にユーザ端末２０がブラウザ２１を介して同じウェブサイトにアクセスする際には、ユーザ端末２０はキャッシュ２２内の画像ファイルまたはデータ列を読み出して、その画像ファイルまたはデータ列を所定のサーバに送信することができる。この処理において、ユーザ端末２０は読み出した画像ファイルからデータ列を抽出してもよい。サーバはそのデータ列を保存および参照することで、ステートフルな処理を実行することができる。

　［第２実施形態］
　第２実施形態に係るブラウザ管理システム２は、第１実施形態で生成されたデータ列をサーバ側で保存する仕組みを提供する。この仕組みは、ステートレスなプロトコルを用いるコンピュータシステム上でステートフルな処理を実現するための構成の一例である。

　図５はブラウザ管理システム２の機能構成の一例を示す図である。本実施形態では、ブラウザ管理システム２は、第１実施形態で示したものと同じ第１サーバ１０と、データ列をサーバ側（ネットワーク側）に保存する第２サーバ４０とを備える。第１サーバ１０と同様に、第２サーバ４０もユーザ端末２０のブラウザ２１を特定するための処理を実行するコンピュータである。第１サーバ１０および第２サーバ４０のそれぞれは、１以上のユーザ端末２０と通信ネットワークを介して接続することができる。

　第２サーバ４０は機能要素として受信部４１および格納部４２を備える。受信部４１は、ユーザ端末２０からデータ列を受信する機能要素である。格納部４２は、そのデータ列をデータベース５０に格納する機能要素である。第２サーバ４０も一または複数のコンピュータ１００で構成される。複数のコンピュータを用いる場合には、これらのコンピュータがインターネットやイントラネットなどの通信ネットワークを介して接続されることで、論理的に一つの第２サーバ４０が構築される。コンピュータ１００は、少なくとも１台のコンピュータを第２サーバ４０として機能させるための第２プログラムを記憶する。第２プログラムは第２サーバ４０の各機能要素を実現するためのコードを含む。第２サーバ４０の各機能要素は、プロセッサ１０１または主記憶部１０２の上に第２プログラムを読み込ませてそのプログラムを実行させることで実現される。

　第１プログラムと同様に、第２プログラムは有形の記録媒体に固定的に記録された上で提供されてもよいし、通信ネットワークを介して提供されてもよい。第２プログラムは第１プログラムと共に提供されてもよいし、第１プログラムとは別に提供されてもよい。

　データベース５０は、データ列を記憶する装置である。データベース５０の実装方法は限定されず、例えばリレーショナル・データベースでもよい。データベース５０が設けられる場所は限定されず、例えば、データベース５０はブラウザ管理システム２の一構成要素でもよいし、ブラウザ管理システム２とは別のコンピュータシステム内に設けられてもよい。データベース５０は、キー（ｋｅｙ）を用いて値（ｖａｌｕｅ）の格納および取得を行うためのキー・バリュー・ストア（Ｋｅｙ－Ｖａｌｕｅ　Ｓｔｏｒｅ：ＫＶＳ）として機能してもよい。

　本実施形態では第２サーバ４０は第１サーバ１０ともウェブサーバ３０とも異なるコンピュータであるが、サーバの構成はこれに限定されない。例えば、一つのサーバが、第１サーバ１０、第２サーバ４０、およびウェブサーバ３０のうちの少なくとも二つのサーバの機能を備えてもよい。

　図６を参照しながら、ブラウザ管理システム２の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図６は、ブラウザ管理システム２の動作の一例を示すシーケンス図である。

　図６におけるステップＳ２１～Ｓ２６の処理は第１実施形態と同じなので（図４を参照）、これらのステップについての説明を省略する。

　ステップＳ２６の後のステップＳ２７では、ユーザ端末２０がキャッシュ２２からデータ列を取得する。この処理は、受信されたウェブページのＪａｖａＳｃｒｉｐｔ（登録商標）により実行されてもよいし、他のシステムイベントを契機に実行されてもよい。

　データ列の取得方法は限定されない。キャッシュ２２が画像ファイルを記憶している場合には、ユーザ端末２０はその画像ファイルをキャッシュ２２から読み出してもよい。この画像ファイルにはデータ列が埋め込まれているので、キャッシュ２２からの画像ファイルの読み出しは、キャッシュ２２からデータ列を取得する処理の一例である。あるいは、ユーザ端末２０は、キャッシュ２２から画像ファイルを読み出してこの画像ファイルからデータ列を抽出することで、データ列を取得してもよい。キャッシュ２２がデータ列を記憶している場合には、ユーザ端末２０はそのデータ列をキャッシュ２２から読み出すことでデータ列を取得できる。

　ステップＳ２８では、ユーザ端末２０がそのデータ列を第２サーバ４０に送信する。データ列の送信方法は限定されない。例えば、ユーザ端末２０はキャッシュ２２から読み出した画像ファイルを第２サーバ４０に送信してもよい。画像ファイルにはデータ列が埋め込まれているので、画像ファイルの送信は、データ列を送信する処理の一例である。あるいは、ユーザ端末２０は読み出したかまたは抽出したデータ列を第２サーバ４０に送信してもよい。例えば、ユーザ端末２０は、ＵＲＬパラメータにデータ列が設定されたＵＲＬを第２サーバ４０に送信してもよい。第２サーバ４０では、受信部４１がそのデータ列（画像ファイルの場合もあり得る）を受信する。

　ステップＳ２９では、格納部４２がそのデータ列をデータベース５０に格納する。受信部４１が画像ファイルを受信した場合には、格納部４２はその画像ファイルからデータ列を抽出してそのデータ列をデータベース５０に格納してもよい。あるいは、格納部４２はその画像ファイルをデータベース５０に格納してもよい。画像ファイルにはデータ列が埋め込まれているので、画像ファイルの格納は、データ列を格納する処理の一例である。受信部４１がデータ列を受信した場合には、格納部４２はそのデータ列をデータベース５０に格納してもよい。データ列がデータベース５０に格納されることで、サーバ側（ネットワーク側）でそのデータ列を後から参照することができる。したがって、ステートフルな処理を実行することが可能になる。格納部４２は、データ列と他の任意のデータ項目とを関連付けることでレコードを生成し、そのレコードをデータベース５０に格納してもよい。

　［第３実施形態］
　第３実施形態に係るブラウザ管理システム３は、第２実施形態で生成および格納されたデータ列を用いてサーバ側でブラウザを特定する仕組みを提供する。この仕組みは、ステートレスなプロトコルを用いるコンピュータシステム上でステートフルな処理を実現するための構成の一例である。

　図７はブラウザ管理システム３の機能構成の一例を示す図である。本実施形態では、ブラウザ管理システム３は、第２実施形態で示したものと同じ第１サーバ１０および第２サーバ４０と、データベース５０に格納されたデータ列を参照する第３サーバ６０とを備える。第１サーバ１０および第２サーバ４０と同様に、第３サーバ６０もユーザ端末２０のブラウザ２１を特定するための処理を実行するコンピュータである。第１サーバ１０、第２サーバ４０、および第３サーバ６０のそれぞれは、１以上のユーザ端末２０と通信ネットワークを介して接続することができる。

　第３サーバ６０は機能要素として受信部６１および判定部６２を備える。受信部６１は、処理の対象となるデータ（以下では「処理対象データ」という）をユーザ端末２０から受信する機能要素である。判定部６２は、その処理対象データをデータベース５０内のデータ列と比較することでブラウザ２１を特定する機能要素である。第３サーバ６０も一または複数のコンピュータ１００で構成される。複数のコンピュータを用いる場合には、これらのコンピュータがインターネットやイントラネットなどの通信ネットワークを介して接続されることで、論理的に一つの第３サーバ６０が構築される。コンピュータ１００は、少なくとも１台のコンピュータを第３サーバ６０として機能させるための第３プログラムを記憶する。第３プログラムは第３サーバ６０の各機能要素を実現するためのコードを含む。第３サーバ６０の各機能要素は、プロセッサ１０１または主記憶部１０２の上に第３プログラムを読み込ませてそのプログラムを実行させることで実現される。

　第１プログラムおよび第２プログラムと同様に、第３プログラムは有形の記録媒体に固定的に記録された上で提供されてもよいし、通信ネットワークを介して提供されてもよい。第３プログラムは第１プログラムおよび第２プログラムと共に提供されてもよいし、第１プログラムおよび第２プログラムの少なくとも一方とは別に提供されてもよい。

　本実施形態では第３サーバ６０は第１サーバ１０、第２サーバ４０、およびウェブサーバ３０のいずれとも異なるコンピュータであるが、サーバの構成はこれに限定されない。例えば、一つのサーバが、第１サーバ１０、第２サーバ４０、第３サーバ６０、およびウェブサーバ３０のうちの少なくとも二つのサーバの機能を備えてもよい。

　図８を参照しながら、ブラウザ管理システム３の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図８は、第３サーバ６０の動作の一例を示すフローチャートである。ブラウザ管理システム３はブラウザ管理システム２（第２実施形態）と同じ処理（図６を参照）を実行することができ、その結果、データベース５０にデータ列が格納される。図８は、或るウェブサイトにアクセスした或るブラウザ２１のデータ列がデータベース５０に格納された後にそのブラウザ２１から処理対象データを受信した際の処理を示す。

　ステップＳ３１では、第３サーバ６０の受信部６１がユーザ端末２０から処理対象データを取得する。処理対象データはデータ列を含み得るが、処理対象データの具体的な内容および構成は限定されない。

　ステップＳ３２では、判定部６２がその処理対象データとデータベース５０内のデータ列とを比較することでブラウザ２１を特定する。判定部６２は、処理対象データの少なくとも一部とデータベース５０内の１以上のデータ列とを比較することで、処理対象データがデータ列を含むか否かを判定する。データベース５０が画像ファイルを記憶している場合には、判定部６２は画像ファイルからデータ列を抽出して比較を実行する。処理対象データが、データベース５０内に存在するデータ列を含む場合には、判定部６２は、そのデータ列に対応するブラウザ２１から処理対象データが送られてきたと判定する。この結果、判定部６２は、処理対象データを送信したブラウザ２１を特定することができる。もし、処理対象データがデータベース５０内のいずれのデータ列も含まない場合には、判定部６２は処理対象データの送信元が不明であると判定する。

　判定部６２によりブラウザ２１が特定された後の処理は限定されない。第３サーバ６０はブラウザ２１を特定した後に任意の処理を実行することができる。あるいは、第３サーバ６０がブラウザ２１を特定した後に、ウェブサーバ３０などの他のサーバが任意の処理を実行してもよい。例えば、ブラウザ２１が特定された後に、第３サーバ６０または他のサーバはステートフルなサービスを提供するための任意の処理を実行してもよい。

　［第４実施形態］
　第４実施形態は、本開示に係るブラウザ管理システムをボランタリ・チェーン（ｖｏｌｕｎｔａｒｙ　ｃｈａｉｎ：ＶＣ）でのアフィリエイト・トラッキングに適用した例である。

　図９および図１０を参照しながら第４実施形態でのシステム構成を説明する。図９はブラウザ管理システム４の適用の一例を示す図である。図１０はブラウザ管理システム４の機能構成の一例を示す図である。本実施形態では、サーバ側（ネットワーク側）はメディアサーバ１１０、ＶＣウェブサーバ１２０、ＶＣ画像サーバ１３０、ＶＣリダイレクタ１４０、および広告主サーバ１５０を含む。ユーザ端末２０はこれらのサーバのそれぞれと通信ネットワーク（例えばインターネット）を介して接続することができる。

　メディアサーバ１１０は、ユーザ端末２０に対して広告媒体を提供するコンピュータである。メディアサーバ１１０は、アフィリエイト広告を含むウェブページ（広告媒体）をユーザ端末２０からの要求に応じて該ユーザ端末２０に送信する。アフィリエイト広告とは、インターネット上に設置された広告媒体上に掲載される広告であって、該広告媒体の閲覧者（ユーザ）がその広告をきっかけに商品を購入した場合に成功報酬が媒体主に付与される形態の広告である。広告媒体とは、アフィリエイト広告を閲覧者に伝達する媒介手段であり、より具体的には、任意の情報が掲載されたウェブページである。広告媒体上でのアフィリエイト広告の表現方法は限定されず、例えば、バナー広告でもよい。

　ＶＣウェブサーバ１２０はボランタリ・チェーンのウェブサーバであり、データ列を取得するためのスクリプトを提供するコンピュータである。そのスクリプトは、例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）でもよい。

　ＶＣ画像サーバ１３０は、データ列が埋め込まれた画像ファイルをユーザ端末２０に送信するコンピュータである。ＶＣ画像サーバ１３０は第１、第２、および第３実施形態における第１サーバ１０の一例であるということができる。ＶＣ画像サーバ１３０は機能要素として受信部１３１、画像生成部１３２、および送信部１３３を備える。受信部１３１は、ウェブページを表示するための処理を実行するユーザ端末２０から画像ファイルの要求を受信する機能要素である。画像生成部１３２は、その要求に応答して画像ファイルを生成する機能要素である。送信部１３３は、データ列をキャッシュ２２に格納するためにその画像ファイルをユーザ端末２０に送信する機能要素である。受信部１３１、画像生成部１３２、および送信部１３３はそれぞれ、上記の受信部１１、画像生成部１２、および送信部１３と同様の機能を実行する。

　ＶＣリダイレクタ１４０は、データ列をサーバ側（ネットワーク側）に保存するコンピュータである。ＶＣリダイレクタ１４０は第２および第３実施形態における第２サーバ４０の一例であるということができる。ＶＣリダイレクタ１４０は機能要素として受信部１４１および格納部１４２を備える。受信部１４１は、ユーザ端末２０からデータ列を受信する機能要素である。格納部１４２は、そのデータ列をデータベース５０に格納する機能要素である。受信部１４１および格納部１４２はそれぞれ、第２および第３実施形態における受信部４１および格納部４２と同様の機能を実行する。

　したがって、ＶＣ画像サーバ１３０およびＶＣリダイレクタ１４０はいずれも、ユーザ端末２０のブラウザ２１を特定するための処理を実行するコンピュータである。

　広告主サーバ１５０は、アフィリエイト広告の広告主により運営される仮想店舗をユーザに提供するコンピュータである。アフィリエイト広告をクリックすることで仮想店舗にアクセスしたユーザは、この仮想店舗で商品を購入することができる。商品とは、有償または無償で取引される任意の有体物または無体物であり、したがって、サービスの提供を含む概念である。商品の種類は何ら限定されない。

　図１１を参照しながら、ブラウザ管理システム４の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図１１は、ブラウザ管理システム４の動作の一例を示すシーケンス図である。

　ステップＳ４１では、ユーザ端末２０が、ＧＥＴメソッドを用いたＨＴＴＰリクエストをメディアサーバ１１０に送信する。

　ステップＳ４２では、メディアサーバ１１０がその要求で指定されたＨＴＭＬデータをユーザ端末２０に送信する。このＨＴＭＬデータは＜ｓｃｒｉｐｔ＞タグを含む。

　ステップＳ４３では、ユーザ端末２０がその＜ｓｃｒｉｐｔ＞タグで示されるＪａｖａＳｃｒｉｐｔ（登録商標）を取得するためのＨＴＴＰリクエスト（ＧＥＴメソッド）をＶＣウェブサーバ１２０に送信する。

　ステップＳ４４では、ＶＣウェブサーバ１２０がその要求に応答してＪａｖａＳｃｒｉｐｔ（登録商標）をユーザ端末２０に送信する。

　ステップＳ４５では、ユーザ端末２０がそのスクリプトを実行して、ＧＥＴメソッドを用いた画像要求をＶＣ画像サーバ１３０に送信する。ＶＣ画像サーバ１３０では受信部１３１がその画像要求を受信する。ステップＳ４５は上記のステップＳ２２に対応する。

　ステップＳ４６では、ＶＣ画像サーバ１３０の画像生成部１３２が、ユーザ端末２０のブラウザ２１を特定するためのデータ列を生成する。ステップＳ４６はステップＳ２３に対応する。

　ステップＳ４７では、画像生成部１３２がそのデータ列を示す複数の画素を含む画像ファイルを生成する。ステップＳ４７はステップＳ２４に対応する。

　ステップＳ４８では、ＶＣ画像サーバ１３０の送信部１３３がその画像ファイルをユーザ端末２０に送信する。ステップＳ４８はステップＳ２５に対応する。

　ユーザ端末２０はその画像ファイルを受信してデータ列をキャッシュ２２に格納する。この格納処理はステップＳ２６に対応する。したがって、ユーザ端末２０は画像ファイルを格納してもよいし、画像ファイルから抽出したデータ列を格納してもよい。

　ステップＳ４９では、ユーザ端末２０がＧＥＴメソッドを用いて、そのデータ列を含むＨＴＴＰリクエストをＶＣリダイレクタ１４０に送信する。ステップＳ４９はステップＳ２８に対応する。したがって、ユーザ端末２０は画像ファイルを送信してもよいし、画像ファイルから抽出したデータ列を送信してもよい。ＶＣリダイレクタ１４０では受信部１４１がそのデータ列を受信する。

　ステップＳ５０では、ＶＣリダイレクタ１４０の格納部１４２がそのデータ列をデータベース５０に格納する。ステップＳ５０はステップＳ２９に対応する。したがって、格納部１４２は画像ファイルを格納してもよいし、受信したデータ列または画像ファイルから抽出したデータ列を格納してもよい。

　格納部１４２は、データ列を他のデータ項目と関連付けることでレコードを生成し、そのレコードをデータベース５０に格納してもよい。例えば、格納部１４２は、ユーザＩＤ、媒体主ＩＤ、広告主ＩＤ、およびトラッキングキーのうちの少なくとも一つをレコードに含めてもよい。このレコードにより、ユーザＩＤ、媒体主ＩＤ、広告主ＩＤ、およびトラッキングキーのうちの少なくとも一つがデータ列と関連付けられる。ここで、ユーザＩＤは、ユーザを一意に特定するための識別子である。媒体主ＩＤは、広告媒体の出稿者である媒体主を一意に特定するための識別子である。広告主ＩＤは、アフィリエイト広告の広告主を一意に特定するための識別子である。トラッキングキーは、特定のウェブサイト内でのユーザの操作を追跡するために用いられる識別子である。

　ステップＳ５１では、ＶＣリダイレクタ１４０が、リダイレクトのために用いられるＨＴＴＰステータスコードである「３０２　Ｆｏｕｎｄ」をユーザ端末２０に送信する。ユーザ端末２０はそのデータ信号を受信する。

　ステップＳ５２では、ユーザ端末２０がその「３０２　Ｆｏｕｎｄ」に応答して、キャッシュ２２からデータ列を読み出し、そのデータ列を含むリクエスト（ＧＥＴメソッド）を広告主サーバ１５０に送信する。

　ステップＳ５３では、広告主サーバ１５０がそのリクエストに応答して、指定されたＨＴＭＬデータをユーザ端末２０に送信する。この広告主サーバ１５０は、ステップＳ５２で受信したデータ列が既にデータベース５０内に記憶されていることに基づいて、ステートフルな処理を実行することができる。

　［第５実施形態］
　第５実施形態は、本開示に係るブラウザ管理システムをアナリティクスに適用した例である。アナリティクスとは、ユーザがどのサイトからアクセスしてきたかを分析したり、ユーザがウェブサイト内でどのような経路を辿るかなどを分析したりする手法のことをいう。

　図１２および図１３を参照しながら第５実施形態でのシステム構成を説明する。図１２はブラウザ管理システム５の適用の一例を示す図である。図１３はブラウザ管理システム５の機能構成の一例を示す図である。本実施形態では、サーバ側（ネットワーク側）はメディアサーバ１１０、ＶＣウェブサーバ１２０、ＶＣ画像サーバ１３０、およびＶＣビーコンサーバ１６０を含む。ユーザ端末２０はこれらのサーバのそれぞれと通信ネットワーク（例えばインターネット）を介して接続することができる。

　メディアサーバ１１０、ＶＣウェブサーバ１２０、およびＶＣ画像サーバ１３０の構成は第４実施形態と同じである。

　ＶＣビーコンサーバ１６０は、データ列をサーバ側（ネットワーク側）に保存するコンピュータである。ＶＣビーコンサーバ１６０は第２および第３実施形態における第２サーバ４０の一例であるということができる。ＶＣビーコンサーバ１６０は機能要素として受信部１６１および格納部１６２を備える。受信部１６１は、ユーザ端末２０からデータ列を受信する機能要素である。格納部１６２は、そのデータ列をデータベース５０に格納する機能要素である。受信部１６１および格納部１６２はそれぞれ、上記の受信部４１および格納部４２と同様の機能を実行する。

　したがって、ＶＣ画像サーバ１３０およびＶＣビーコンサーバ１６０はいずれも、ユーザ端末２０のブラウザ２１を特定するための処理を実行するコンピュータである。

　図１４を参照しながら、ブラウザ管理システム５の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図１４は、ブラウザ管理システム５の動作の一例を示すシーケンス図である。

　ステップＳ６１～Ｓ６８の処理は、第５実施形態におけるステップＳ４１～Ｓ４８の処理と同じである。ユーザ端末２０は、ステップＳ６８でＶＣ画像サーバ１３０から送られてきた画像ファイルを受信してデータ列をキャッシュ２２に格納する。ユーザ端末２０は画像ファイルを格納してもよいし、画像ファイルから抽出したデータ列を格納してもよい。

　ステップＳ６９では、ユーザ端末２０がＧＥＴメソッドを用いて、そのデータ列を含むＨＴＴＰリクエストをＶＣビーコンサーバ１６０に送信する。ステップＳ６９は第２実施形態におけるステップＳ２８に対応する。したがって、ユーザ端末２０は画像ファイルを送信してもよいし、画像ファイルから抽出したデータ列を送信してもよい。ＶＣビーコンサーバ１６０では受信部１６１がそのデータ列を受信する。

　ステップＳ７０では、ＶＣビーコンサーバ１６０の格納部１６２がそのデータ列をデータベース５０に格納する。ステップＳ７０はステップＳ２９に対応する。したがって、格納部１６２は画像ファイルを格納してもよいし、受信したデータ列または画像ファイルから抽出したデータ列を格納してもよい。第４実施形態と同様に、格納部１６２は、データ列を他のデータ項目と関連付けることでレコードを生成し、そのレコードをデータベース５０に格納してもよい。例えば、格納部１６２は、ユーザＩＤ、媒体主ＩＤ、広告主ＩＤ、およびトラッキングキーのうちの少なくとも一つをレコードに含めてもよい。

　ステップＳ７１では、ＶＣビーコンサーバ１６０が、アナリティクスのために用いられる透過画像をユーザ端末２０に送信する。ユーザ端末２０はその透過画像を受信する。この透過画像は、ブラウザ２１を特定するためのデータ列が埋め込まれた画像ファイルとは異なる画像であることに留意されたい。

　［第６実施形態］
　第６実施形態は、本開示に係るブラウザ管理システムをターゲティングに適用した例である。ターゲティングとは、ユーザがインターネット上でどのウェブサイトにアクセスしたかを追跡する手法のことをいう。

　図１５および図１６を参照しながら第６実施形態でのシステム構成を説明する。図１５はブラウザ管理システム６の適用の一例を示す図である。図１６はブラウザ管理システム６の機能構成の一例を示す図である。本実施形態では、サーバ側（ネットワーク側）はメディアサーバ１１０、ＶＣウェブサーバ１２０、ＶＣ画像サーバ１３０、ＶＣビーコンサーバ１６０、および広告サーバ１７０を含む。ユーザ端末２０はこれらのサーバのそれぞれと通信ネットワーク（例えばインターネット）を介して接続することができる。

　メディアサーバ１１０、ＶＣウェブサーバ１２０、ＶＣ画像サーバ１３０、およびＶＣビーコンサーバ１６０の構成は第５実施形態と同じである。

　広告サーバ１７０は、広告媒体上に載せるアフィリエイト広告をユーザに提供するコンピュータである。広告サーバ１７０は、ブラウザ２１から送信された処理対象データとデータベース５０内のデータ列とを比較してブラウザ２１を特定する処理を実行してもよい。したがって、広告サーバ１７０は第３実施形態における第３サーバ６０の一例であるということができる。広告サーバ１７０は機能要素として受信部１７１および判定部１７２を備える。受信部１７１は、処理対象データをユーザ端末２０から受信する機能要素である。判定部１７２は、その処理対象データをデータベース５０内のデータ列と比較することでブラウザ２１を特定する機能要素である。受信部１７１および判定部１７２はそれぞれ、上記の受信部６１および判定部６２と同様の機能を実行する。

　したがって、ＶＣ画像サーバ１３０、ＶＣビーコンサーバ１６０、および広告サーバ１７０はいずれも、ユーザ端末２０のブラウザ２１を特定するための処理を実行するコンピュータである。

　図１７を参照しながら、ブラウザ管理システム６の動作を説明するとともに本実施形態に係るブラウザ管理方法について説明する。図１７は、ブラウザ管理システム６の動作の一例を示すシーケンス図である。

　ステップＳ８１～Ｓ９１の処理は、第５実施形態におけるステップＳ６１～Ｓ７１の処理と同じである。

　ステップＳ９２では、ユーザ端末２０が、アフィリエイト広告を取得するためのＨＴＴＰリクエスト（ＧＥＴメソッド）を広告サーバ１７０に送信する。このリクエストは、キャッシュ２２から読み出されたデータ列を含む。広告サーバ１７０では受信部１７１がそのリクエストを受信する。この受信はステップＳ３１に対応し、したがって、ＨＴＴＰリクエストは処理対象データに相当する。

　ステップＳ９３では、広告サーバ１７０の判定部１７２がそのリクエストに基づいてデータベース５０を参照することで、リクエストに含まれているものと同じデータ列がデータベース５０内に記憶されているか否かを判定する。判定部１７２はその判定結果に基づいてブラウザ２１を特定することができる。ステップＳ９３はステップＳ３２に対応する。広告サーバ１７０は、その判定結果に基づいて、ターゲティングに必要な更なる処理（この処理はステートフルな処理であるといえる。）を実行できる。

　ステップＳ９４では、広告サーバ１７０がそのリクエストに応答して、指定されたアフィリエイト広告のデータ（広告データ）をユーザ端末２０に送信する。ユーザ端末２０はその広告データを受信し、アフィリエイト広告を含む広告媒体をモニタ上に表示する。

　第４、第５、および第６実施形態では、ユーザ端末２０はＧＥＴメソッドを用いてＨＴＴＰリクエストを送信する。しかし、ＧＥＴメソッドの利用は必須ではなく、ユーザ端末２０は他のＨＴＴＰリクエストメソッド（例えばＰＯＳＴメソッド）を用いてもよい。

　［効果］
　以上説明したように、本発明の一側面に係るブラウザ管理システムは、少なくとも一つのプロセッサを備え、少なくとも一つのプロセッサが、ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成し、データ列を示す複数の画素を含む画像ファイルを生成し、データ列をユーザ端末のキャッシュに格納するために画像ファイルをユーザ端末に送信する。

　このような側面においては、ブラウザを特定するためのデータ列を示す画像ファイルがユーザ端末のキャッシュに格納される。したがって、その画像ファイルを用いることで、ＨＴＴＰクッキーを用いることなくブラウザを特定することができる。また、ブラウザを特定するためのデータ列を、従来から広く用いられている画像ファイルに埋め込むことで、特定のサービスに依存しない形でそのデータ列をキャッシュに保存し、必要に応じてそのデータ列をキャッシュから読み出すことができる。したがって、ＨＴＴＰクッキーに代わるこの新たな技術を様々なオンラインサービスに適用することができる。すなわち、データ列を画像ファイルに埋め込むこの新たな技術は汎用性が高い。

　他の側面に係るブラウザ管理システムでは、少なくとも一つのプロセッサが、データ列を、複数の画素に対応する複数の画素値に変換することで画像ファイルを生成してもよい。データ列を画素値に変換することで、データ列を効率的に画像ファイルに埋め込むことができる。

　他の側面に係るブラウザ管理システムでは、複数の画素がＲＧＢまたはグレースケールで表されてもよい。データ列をＲＧＢまたはグレースケールの画素値に変換することで、データ列を効率的に画像ファイルに埋め込むことができる。

　他の側面に係るブラウザ管理システムでは、ウェブページが、画像ファイルを取得するためのスクリプトを含み、少なくとも一つのプロセッサが、ユーザ端末でスクリプトが実行されたことに応答して、データ列の生成と、画像ファイルの生成と、画像ファイルの送信とを実行してもよい。ウェブページ内のスクリプトに従って画像ファイルを生成および送信することで、データ列が必要なタイミングで画像ファイルをユーザ端末に提供することができる。

　他の側面に係るブラウザ管理システムでは、少なくとも一つのプロセッサが、ユーザ端末によりキャッシュから読み出されて送信されたデータ列を取得してもよい。ユーザ端末のキャッシュに記憶されていたデータ列を取得することで、サーバ側でそのデータ列を保存することができ、その保存されたデータ列を用いてブラウザを特定することが可能になる。

　他の側面に係るブラウザ管理システムでは、データ列を含む文字列をユーザ端末から受信することでデータ列を取得してもよい。この場合には、サーバ側で画像ファイルからデータ列を抽出する必要がないので、サーバ側の処理負荷を低減することができる。

　他の側面に係るブラウザ管理システムでは、少なくとも一つのプロセッサが、ユーザ端末から画像ファイルを受信して該画像ファイルからデータ列を抽出することで、データ列を取得してもよい。この場合には、ユーザ端末で画像ファイルからデータ列を抽出する必要がないので、ユーザ端末の処理負荷を低減することができる。

　他の側面に係るブラウザ管理システムでは、少なくとも一つのプロセッサが、取得されたデータ列を記憶装置に格納してもよい。サーバ側でデータ列を保存することで、その保存されたデータ列を用いてブラウザを特定することが可能になる。

　他の側面に係るブラウザ管理システムでは、少なくとも一つのプロセッサが、データ列がデータベースに格納された後に、ユーザ端末から処理対象データを取得し、処理対象データと記憶装置内のデータ列とを比較し、処理対象データがデータ列を含む場合に、処理対象データがブラウザから送信されたと判定してもよい。ユーザ端末から送られてきたデータ（処理対象データ）を記憶装置内のデータ列と照合することでブラウザを特定することができる。

　本発明の一側面に係るクライアントプログラムは、上記のブラウザ管理システムから画像ファイルを受信するステップと、データ列をキャッシュに格納するステップとをコンピュータに実行させる。このような側面においては、ブラウザを特定するためのデータ列がユーザ端末のキャッシュに格納される。したがって、そのデータ列を用いることで、ＨＴＴＰクッキーを用いることなくブラウザを特定することができる。

　［変形例］
　以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能である。

　ブラウザ管理システムの構成は上記の各実施形態に限定されず、ブラウザ管理システムは１以上の任意のサーバを用いて構成されてよい。いずれにしても、ブラウザ管理システムは少なくとも一つのプロセッサを備える。ブラウザ管理システムが複数のプロセッサを備える場合には、第１の処理を実行するプロセッサは、第２の処理を実行するプロセッサと同じでもよいし異なってもよい。「少なくとも一つのプロセッサが第１の処理および第２の処理を実行する」ことは、どのプロセッサがどの処理を実行するかについて何ら限定しないことを意味する。

　上記のいくつかの実施形態ではデータベース５０がデータ列を記憶するが、記憶装置はデータベース５０に限定されない。ブラウザ管理システムは、データベース以外の記憶装置（例えば、任意の種類のメモリ）にデータ列を格納してもよい。

　少なくとも一つのプロセッサにより実行されるブラウザ管理方法の処理手順は上記実施形態での例に限定されない。例えば、上述したステップ（処理）の一部が省略されてもよいし、別の順序で各ステップが実行されてもよい。また、上述したステップのうちの任意の２以上のステップが組み合わされてもよいし、ステップの一部が修正または削除されてもよい。あるいは、上記の各ステップに加えて他のステップが実行されてもよい。

　１～６…ブラウザ管理システム、１０…第１サーバ、１１…受信部、１２…画像生成部、１３…送信部、２０…ユーザ端末、２１…ブラウザ、２２…キャッシュ、３０…ウェブサーバ、４０…第２サーバ、４１…受信部、４２…格納部、５０…データベース（記憶装置）、６０…第３サーバ、６１…受信部、６２…判定部、１１０…メディアサーバ、１２０…ＶＣウェブサーバ、１３０…ＶＣ画像サーバ、１３１…受信部、１３２…画像生成部、１３３…送信部、１４０…ＶＣリダイレクタ、１４１…受信部、１４２…格納部、１５０…広告主サーバ、１６０…ＶＣビーコンサーバ、１６１…受信部、１６２…格納部、１７０…広告サーバ、１７１…受信部、１７２…判定部。

Claims

　少なくとも一つのプロセッサを備え、
　前記少なくとも一つのプロセッサが、
　　ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成し、
　　前記データ列を示す複数の画素を含む画像ファイルを生成し、
　　前記データ列を前記ユーザ端末のキャッシュに格納するために前記画像ファイルを前記ユーザ端末に送信する、
ブラウザ管理システム。
　前記少なくとも一つのプロセッサが、前記データ列を、前記複数の画素に対応する複数の画素値に変換することで前記画像ファイルを生成する、
請求項１に記載のブラウザ管理システム。
　前記複数の画素がＲＧＢまたはグレースケールで表される、
請求項１または２に記載のブラウザ管理システム。
　前記ウェブページが、前記画像ファイルを取得するためのスクリプトを含み、
　前記少なくとも一つのプロセッサが、前記ユーザ端末で前記スクリプトが実行されたことに応答して、前記データ列の生成と、前記画像ファイルの生成と、前記画像ファイルの送信とを実行する、
請求項１～３のいずれか一項に記載のブラウザ管理システム。
　前記少なくとも一つのプロセッサが、前記ユーザ端末により前記キャッシュから読み出されて送信された前記データ列を取得する、
請求項１～４のいずれか一項に記載のブラウザ管理システム。
　前記少なくとも一つのプロセッサが、前記データ列を含む文字列を前記ユーザ端末から受信することで前記データ列を取得する、
請求項５に記載のブラウザ管理システム。
　前記少なくとも一つのプロセッサが、前記ユーザ端末から前記画像ファイルを受信して該画像ファイルから前記データ列を抽出することで、前記データ列を取得する、
請求項５に記載のブラウザ管理システム。
　前記少なくとも一つのプロセッサが、取得された前記データ列を記憶装置に格納する、
請求項５～７のいずれか一項に記載のブラウザ管理システム。
　前記少なくとも一つのプロセッサが、
　　前記データ列が前記記憶装置に格納された後に、前記ユーザ端末から処理対象データを取得し、
　　前記処理対象データと前記記憶装置内のデータ列とを比較し、
　　前記処理対象データが前記データ列を含む場合に、前記処理対象データが前記ブラウザから送信されたと判定する、
請求項８に記載のブラウザ管理システム。
　少なくとも一つのプロセッサにより実行されるブラウザ管理方法であって、
　ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成するステップと、
　前記データ列を示す複数の画素を含む画像ファイルを生成するステップと、
　前記データ列を前記ユーザ端末のキャッシュに格納するために前記画像ファイルを前記ユーザ端末に送信するステップと
を含むブラウザ管理方法。
　ユーザ端末のブラウザ上にウェブページを表示するための処理に応答して、該ブラウザを特定するためのデータ列を生成するステップと、
　前記データ列を示す複数の画素を含む画像ファイルを生成するステップと、
　前記データ列を前記ユーザ端末のキャッシュに格納するために前記画像ファイルを前記ユーザ端末に送信するステップと
をコンピュータシステムに実行させるブラウザ管理プログラム。
　請求項１～９のいずれか一項に記載のブラウザ管理システムから前記画像ファイルを受信するステップと、
　前記データ列を前記キャッシュに格納するステップと
をコンピュータに実行させるクライアントプログラム。