section using a style sheet (.ess file), but with no technical effect.
The files "elt._1 .png," "elt_2.png," "elt_3.png" are three monitoring elements, here
images in png format.
When this message M2 is received, the browser B must retrieve monitoring
elements in order to be able to produce the page and display it on the screen of the
communication terminal on which it is deployed.
It therefore transmits a request M3 for monitoring elements to the monitoring server.
Typically, this request is made of GET messages in accordance with the HTTP
protocol, with one GET message corresponding to one monitoring element.
Based on the DIV section of the example, the browser B may form three GET
messages sent to the server www.st.com:
GET tracker/elt_1 .png
GET tracker/elt_2.png
GET tracker/elt_3.png
This step of receiving a monitoring element request is designated E 1 on the
flowchart in Figure 4.
Upon receiving this request, the monitoring server ST may implement a second step
E2 of determining whether that request is a first request from the browser B.
This determination may be done based on the number of monitoring elements
requested in the request M3. If the set of monitoring elements is requested, it is a first
request. Otherwise, as we shall see later on, it is not a first request: There are monitoring
elements in the browser's cache memory which are not being requested again.
In the depicted example, it is a first request. The monitoring server ST may then
implement:
- a step E3 of calculating an identifier for the browser B, then
a step E4 of determining a cache duration value associated with each monitoring
element of that set, and
a step E5 of transmitting the set of these monitoring elements and calculated
values to the browser B.
This identifier may be a counter, incremented each time a new browser enters into
contact with the monitoring server ST.
According to one preferential embodiment of the invention, this identifier is made up
of a first part containing identification information transmitted in the request M3, and a
second part formed of that counter.
This identification information may be the fingerprint of the browser B and may
correspond to the "User Agent" header of messages M3 in accordance with the HTTP
protocol. This header is a character string specifying the software used to connect to an
HTTP server. As described above, it generally comprises the browser type (Mozilla, IE,
Chrome, etc.) and a version number.
The counter makes it possible to uniquely distinguish between browsers with the
same fingerprint.
Compared to an embodiment where the identifier is made of the counter alone, this
implementation makes it possible to reduce the meter's size and therefore the number of
monitoring elements. Thus, it is possible to reduce the memory resources on the
monitoring server and in the browser's cache memory, as well as the volume of
information to be transmitted.
It is also possible to use the transmission IP address of the request M3. This makes
it possible to further reduce the space needed for the counter, because the counter will no
longer be serving any purpose but to distinguish between browsers that belong to the
same IP space and have the same fingerprint.
The length of the counter should therefore be defined in advance, which means
estimating the expected maximum number of browsers that have the same fingerprint and
belong to the same IP space. This number may be configured with a default value and can
be edited by an administrator.
This length n (in bits) may be expressed based on the counter's maximum number N
by the formula: n=[log2(N)]+1
The monitoring server ST saves n monitoring elements. These monitoring elements
are files of different types (images, text, etc.). They are not necessarily all of the same
type.
The next step E4 consists of determining a cache duration value associated with
each monitoring element in that set of n elements.
There is actually a mechanism that allows browsers to store all or some of the
downloaded elements in a cache memory. Thus, during a second visit to the same Web
page, the browser will not re-download the elements already present in the cache
memory. This mechanism makes it possible to minimize the transmitted volume of data.
The cache memory may be on the hard drive or the volatile memory of the
communication terminal on which the browser is deployed.
According to one embodiment, the cache duration values are determined based on
the counter's binary writing.
Thus, this counter may be written bn...b3-b2-b1 , where bi is the bit with significance
i .
The value v(i) for the element corresponding to the bit with significance i is given
based on the following formula:
if b(i)=1 , v(i)=max
if b(i)=0, v(i)=0
wherein max is the maximum possible value for a given cache duration. It may also
be an arbitrarily long value, long enough for the cache to not expire between two requests
from the same browser.
The next step E5 consists of transmitting to the browser B the monitoring elements
themselves and the cache duration values that were determined for each of them.
This transmission may consist of as many messages M4 as there are messages M3
in the request.
This is because, in the HTTP protocol, each GET message corresponds to a "200
OK" response message containing the requested element. In the example above, there
will therefore be three messages containing the monitoring elements elt._1 .png, elt_2.png,
and elt_3.png.
Each response message may contain the corresponding cache duration value in the
HTTP header.
If b(i)=0, this header may look like:
Status Code: 200 OK
Cache-control: private, no-transform, max-age=0
content-type: text/xml
Content-length: 670
server: jetty(6.1 .x)
If b(i)=1 , this header may look like:
Status Code: 200 OK
Cache-control: private, no-transform, max-age=2 147483647
content-type: text/xml
Content-length: 670
server: jetty(6.1 .x)
The parameter max-age in the cache-control line contains the value v(i) which is
equal to either 0, or the maximum allowed value. This parameter is defined in section
14.9.3 of RFC 2616 of the IETF.
It may be useful to additionally indicate the parameter "private" in order to prevent
"proxies" (local intermediary elements that implement a cache mechanism) located
between the browser B and the server from saving these monitoring elements in the
cache and thereby from interfering with the invention's mechanism.
This keyword indicates that the management of the cache mechanism for these
monitoring elements is "private," meaning that sole responsibility rests with the client (the
browser B) and the server.
In the three-monitoring-element example described above, it is assumed that the
calculated identifier is 3, or "011" in binary. The cache values are therefore 0 for elt_3.png,
and max (i.e. 2147483647 seconds in this case) for elt_2.png and elt_1 .png.
The monitoring elements are saved in the cache memory of the browser B.
When the same browser B transmits a new request to the content server SC, it
receives a portion related to the monitoring server ST as previously mentioned. If it is the
same page, that portion may be identical to the one previously received (unless, for
example, it had been updated in the meantime).
In a manner known in and of itself, the browser is adapted to retrieve the monitoring
elements in order to be able to produce the page and display it on the screen of the
communication terminal on which it is deployed. This retrieval is performed based on the
elements already present in the cache memory and based on the associated cache
duration value.
When the associated value had been set to 0 by the server, regardless of the time
between that request and the previous one, the browser must request the element from
the monitoring server ST again. It therefore transmits a GET message requesting the
element in question.
If the associated value had been set to "max," the browser B uses the saved
monitoring element to present it to the user, without transmitting any messages to the
monitoring server.
In our example, the browser therefore transmits two GET messages sent to the
server www.st.com:
GET tracker/elt_1 .png
GET tracker/elt_2.png
The browser's behavior is caused by information transmitted by the monitoring
server ST in accordance with the invention, but the browser itself obeys the standard
behavior of a browser in accordance with the HTTP protocol. The invention involves no
changes to the browser or communication terminal.
The monitoring server ST receives this monitoring element request in a step E 1.
The step E2 consists of determining whether or not it is a first request.
As not all of the monitoring elements are being requested again (the element
elt_3.png is not being requested), the server ST may deduce from this that it is not a first
request, and therefore that the browser B is already "known."
The monitoring server ST may then trigger a step E6 of determining that browser's
identifier.
This determination is based on monitoring elements requested in the request, by a
mechanism opposite the one used to generate the identifier.
In the described implementation, the positions of the monitoring elements makes it
possible to write the identifier in binary form. If the elements elt_1 .png and elt_2.png have
been requested, the bits with significance 1 and 2 are set to 1; and if the element
elt_3.png has not been request, the bit with significance 3 is set to 0. The browser's
identifier is therefore written "011" in binary, or 3.
As the identifier is known, the monitoring server ST can implement different
monitoring strategies. It may saved the collected information, particularly the URL
addresses viewed on the content servers, and thereby build a profile of the browser's user
based on his or her browsing history. Based on this profile, it may determine suitable
advertising insets.
It may also use this information to build statistics on the visitors of a particular
content site or set of sites.
In one variant of the invention, it is possible to use the HTTP protocol's redirect
mechanism to reduce the length n of the counter and therefore the number of monitoring
elements to use.
This redirect mechanism relies on messages 302 and 307 of the HTTP protocol.
In the portion related to the monitoring server ST, an address URL1 may be
indicated. This address URL1 is configured in the monitoring server ST to redirect to an
address URL2.
During a first visit, the browser follows the redirect, but during a second visit, the
redirect is saved by the browser, which then directly queries the second address URL2.
It is possible to use this behavior to identify the users, by chaining together multiple
redirects r 1 , r2, r3, r4, r5.
Whenever a user connects to a site for the first time, it follows the chained redirect:
r 1 -> r2 -> r3 -> r4 -> r5. It automatically downloads the redirect elements r 1 , r2, r3, r4, r5.
The server may set different cache values for each redirect element, for example a
null value for r2 and r5 and a very high value for the other elements.
Thus, during a later visit, the browser goes directly to the address indicated by r2
and follows the following path: r2 -> r5.
It will therefore be possible to deduce from this that the browser has the elements
r 1 , r3 and r4 in its cache, and based on this information, to distinguish between multiple
users.
One alternative may consist of using different redirect codes rather than different
cache values. For example, it is possible to use redirect code 301 and redirect code 302.
By chaining together redirects with these two code values, it is possible to obtain a binary
tree as depicted in Figure 5. In this figure, it is assumed that the rising branches
correspond to code value 301 and that the descending branches correspond to code
value 302.
The browsers generally have a maximum value of the number of tolerated redirects
(for example, 5). This way, this mechanism only makes it possible to distinguish a limited
number of users, here 2 =32
According to one embodiment of the invention, this mechanism is used to
complement the use of monitoring elements in order to reduce the number of them to be
managed. This implementation of the invention thereby makes it possible to reduce the
resources needed for the invention on the servers, in the browser's cache memory and in
transmissions on the communications network.
To do so, the identification of the browser may be preceded by a first part (the most
significant) indicating redirect elements.
In a manner similar to what was previously described as a possible implementation
of writing the identifier based on the monitoring elements, this first part may be written
rk...r3-r2-r1 in which ri is the bit with significance i and k is the number of possible
redirects.
The chained redirects may be indicated by the bit with matching significance in said
first part.
The value v(i) for the redirect element corresponding to the bit with significance i is
given based on the following formula:
if ri=1 , v(i)=max
if ri=0, v(i)=0
wherein max is the maximum possible value for a given cache duration. It may also
be an arbitrarily long value, long enough for the cache to not expire between two requests
from the same browser.
Another possible formula may be based on different redirect codes:
if ri=1 , v(i)=301
if ri=0, v(i)=302
The identifier of the browser with the first part may be written rk...r3-r2-r1- bn...b3-
b2-b1 . The total length is equal to k+n.
CLAIMS
1) A method for monitoring browsers (B) for a communications network (N), wherein
a monitoring server contains a set of monitoring elements, and implements
a step (E1 ) of receiving a monitoring element request from a browser (B)
a step (E2) of determining whether said request is a first request from said
browser,
if so, a step (E3) of calculating an identifier for the browser, then a step (E4) of
determining a cache duration value associated with each monitoring element of
said set, and a step (E5) of transmitting the set of said monitoring elements
and said values to said browser;
if not, a step (E6) of determining said browser's identifier based on the
monitoring elements requested in said request,
2) A method according to the preceding claim, wherein whether a request is a first
request may be determined based on the number of monitoring elements requested in
said request.
3) A method according to one of the preceding claims, comprising a prior first step of
said browser transmitting a content request to a content server, and of said content server
transmitting both the requested content and an inset containing links leading to said
monitoring elements.
4) A method according to one of the preceding claims, wherein said identifier is
made up of a first part containing identification information transmitted in said request, and
a second part formed of a counter.
5) A method according to the preceding claim, wherein the number of monitoring
elements in said set is equal to the length of said counter, expressed in bits.
6) A method according to the preceding claim, wherein the value of a bit b(i) with
significance i and the cache duration value associated with the monitoring element at
position i may follow the following relationship:
if b(i)=1 , v(i)=max
if b(i)=0, v(i)=0
wherein 'max' is the maximum possible value for a given cache duration.
7) A method according to the preceding claim, wherein said identifier is preceded by
a first part indicating chained redirects.
8) A method according to the preceding claim, wherein said chained redirects are
indicated by the bit with matching significance in said first part.
9) A method according to one of claims 7 or 8, wherein each redirect among said
chained redirects is associated with a cache value of zero or a maximum possible value
for a cache value.
10) A method according to one of claims 7 or 8, wherein each redirect among said
chained redirects may be associated with a 301 or 302 redirect code.
11) A monitoring server containing a set of monitoring elements and means for
implementing the method according to one of the preceding claims.
12) A server comprising a monitoring server according to the preceding claim and a
content server.