Williamson v. Google Inc.
Filing
1
COMPLAINT FOR PATENT INFRINGEMENT filed with Jury Demand against Google Inc. - Magistrate Consent Notice to Pltf. ( Filing fee $ 400, receipt number 311-1464208.) - filed by Richard A. Williamson. (Attachments: # 1 Exhibit A, # 2 Exhibit B, # 3 Exhibit C, # 4 Civil Cover Sheet)(dmp, )
EXHIBIT C
2/18/2014
Cache-busting with legacy DFP tags - DoubleClick for Publishers Help
Help
Contact Us
Community
Cache-busting with legacy DFP tags
When you use a browser to view websites for the first time, the browser will save certain items, like images, to a specific
folder on your hard drive. The next time you visit that website, the browser will check this folder first to see if it already has
some of the items on the page. If so, it won't bother to download them again and instead just loads the files from the folder on
your hard drive in order to make the page load faster for you. This process is called caching.
For example, if you’ve gone to Google.com before, your browser may save the Google logo in its cache. The next time you go
to Google.com, the browser calls the image file from the cache, instead of calling the Google.com server for the logo image a
second time and making you wait while it re-sends the same image you already have.
While browser caching can be helpful for an Internet user, it’s problematic when it comes to ad serving. When a user loads a
page with ad tags, the browser first checks if it has something in its cache to serve to the ad tag, such as a creative file that
was delivered to that tag in the past. If the browser finds a creative in the cache that’s served to that tag before, it will serve
that creative.
This is a problem because it means that you could be serving old creatives to users, and most importantly, DFP won’t count
an impression for that creative because no call to the ad server was made when the browser retrieved a creative file from its
cache. Browser caching can lead to impression counting discrepancies.
You can defeat browser caching and ensure that a fresh call is always made to the ad server by dynamically generating a part
of the ad tags for each ad slot every time a web page is displayed. Doing so ensures that each time users navigate from web
page to web page, a call is made to the ad servers rather than to the browser's cache.
We recommend using a dynamically generated random number attribute in the DFP ad tag (o d v l e to achieve the goal
r=au)
of forcing the browser not to use its cache. This enables the ad servers to count impressions each time a unique user
requests a web page with ads, even if the user requests the same web page more than once.
This section discusses the following topics:
Using o d v l e
r=au
Example ad tag using o d v l e
r=au
Using ord=value
One of the reserved key-values for DFP tags is o d v l e Using this key-value and dynamically generating a random
r=au.
number for the value ensures that a fresh call is made to the ad server with each page load. The browser interprets each
random number as a new request and consequently requests a new ad from the ad server. Each time the page is loaded, the
random number changes, causing the browser to interpret it as a new request, so it skips checking the browser cache for a
file to serve to the page.
https://support.google.com/dfp_premium/answer/1116933?hl=en
1/3
2/18/2014
Cache-busting with legacy DFP tags - DoubleClick for Publishers Help
The o d v l emust be the last key-value in the ad tag and can only be followed by a question mark (?) before the tag is
r=au
closed. Adding in the question mark at the end is an additional method for forcing the browser to make a fresh call rather than
going to its cache.
Additionally, while the value generated for o d v l eshould be different each time the page is refreshed, the value should
r=au
always remain consistent across different ad tags on the same page. For example, on the first page load, ad tag A and ad tag
B will both have o d 8 3 2 as the last key-value, while on the second page load when the page is refreshed, ad tag A and
r=87?
ad tag B will both have o d 3 2 0 as the last key-value.
r=50?
The value needs to remain consistent because the other function of o d v l eis to identify that these ad calls are coming
r=au
from the same page. If on the same page load, you have ad tags with different o dvalue numbers, the ad server will think it’s
r
serving ads to two entirely separate pages, which will interfere with features like roadblocks and competitive ad exclusion
labels that depend on knowing which calls are coming from the same page.
There are a few different ways to populate o d v l ewith a random number every time your web page is loaded.
r=au
DoubleClick recommends that you use the same technology to dynamically generate random numbers as you use to
generate HTML pages on your website. For example, if your website is written in ASP, use ASP to generate random numbers
for the o d v l ekey-value. Your web developer team should be able to advise you on the best solution for your website’s
r=au
setup.
For standard HTML page, you can use a JavaScript random number generator like this:
vrod=Nme(r)| Mt.lo(ahrno(*01)
a r
ubrod | ahforMt.adm)1e2;
Since you only want to generate one new random number per page load, make sure you include this code just once on each
page. It can be placed in the first ad tag on the page or somewhere in the source code with JavaScript tags around it before
the ad tags on the page.
Please note that when you generate an ad tag using a tag generator, the tag may include a random number generator in the
tag itself. Check your code so that you don’t have multiple ad tags on the same page, each with its own random number
generator, resulting in inconsistent numbers for o d v l eacross ad calls in the same page load.
r=au
Please also note that including non-integers in random number strings can cause back-end problems in DART. DoubleClick
therefore recommends that your random numbers contain only integers. We recommend having at least 8 integers in the
random number string.
Example ad tag using ord=value
Here’s an example of an ad tag with o d v l eproperly implemented. The example below is of a JavaScript ad tag with a
r=au
random number generator within the ad tag, but even with iframe and image ad tags, the random number generator and
o d v l ewill be set up in a similar manner.
r=au
srp ye"etjvsrp"
vrod=Nme(r)| Mt.lo(ahrno(*01)
a r
ubrod | ahforMt.adm)1e2;
dcmn.rt(\srp>)
/cit
<
a
he=ht:/ddulcikntNewr_oejm/is_ee_dui/eodlvla_n
rf"tp/a.obelc.e/ntokcd/upfrtlvla_ntscn_ee_dui
tkyvletl=ienme;zwdhhih;r=24680"tre=_ln"
;e=au;ietl_ubrs=itxegtod13579? agt"bak>
/ocit
Build and serve legacy DFP tags
Generating ad tags
Examples of JavaScript, iframe, and image DART ad tags
Pass custom targeting criteria into legacy DART ad tags
Cache-busting with legacy DFP tags
Stub files and iframe busters
Using legacy DFP tags in another ad serving system
How helpful is this article:
Not at all helpful
Not very helpful
Somewhat helpful
Very helpful
Extremely helpful
0
©2013 Google Inc. | DoubleClick is a division of Google Inc.
Privacy Policy
Terms of Service
Program Policies
DoubleClick Home
English
https://support.google.com/dfp_premium/answer/1116933?hl=en
3/3
Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.
Why Is My Information Online?