So far I've seen two real-world implementations of this algorithm. One for Java EE right here in OWASP and a second one developed by F5 iRules.

Adobe has published their official server-side workarounds.
The Adobe solutions work by changing either the Content-Type or Content-Disposition headers in order to force the pdf to be downloaded avoiding the Adobe plug-in. I think the "Content-Type" change is less desirable as I've seen it working improperly in some cases. The downside of either implementation is that for long-established commercial websites, this changes the effective functionality of the site in that pdf's (on PC's configured with Adobe plug in), no longer open up in the browser.

Ideally, in order not to lose the functionality, we can clear the "anchor/fragment" off of the original URL by forcing a redirect to an URL containing a "hard to reproduce" but verifiable token in the query string (or even in the location).

More details of the attack are discussed elsewhere. The software in the public domain to make it easy for anyone to use for any purpose.

Approach

My initial approach was almost the same as the approach described for the Java EE implementation. The main difference was that in the case that a request arrives with a query string, but one which doesn't match our generated token, instead of setting the Content-Disposition and forcing a download of the file, we redirect to the same URL containing a newly generated token in the query string.

On further study, I simplified the approach, hopefully maintaining the same level of security. This consists of at most a single rewrite based on two conditions, the file is a pdf and it has a correctly generated token in the query string. If the two conditions are not met, we redirect to the same pdf but with a valid token in the query string.
This method skips step 2 and 3 of the Ami algorithm. Purposefully the query string is cleared out on the redirect and only the token is passed. The reason is to avoid possible other hacks playing around with the query string. Unless the pdf is dynamically created and depends on get parameters, this shouldn't be a problem.
Certainly it is possible to implement a version of rewrite rules which will allow us also to maintain the original query string, without difficulty.

The first rewrite condition matches all pdf files. The second condition matches all requests whose query string doesn't match our generated token, which is created by passing the client IP address %{REMOTE_ADDR} and the query string supplied in the request %{QUERY_STRING}.

Assuming we are requesting a pdf file, there are different cases that the second part of this rule handles.

First time request without any query string, e.g.

http://www.aaa.com/test.pdf

tokenize is called with the client ip address (the query string is empty), e.g.

tokenize - mod_rewrite prg

Now on to "tokenize". This is a mod_rewrite RewriteMap external program. It is run on initialization of the rewrite engine and loops on stdin where it receives text to transform, delimited by newlines. Output is on stdout, terminated by newline. Our version of tokenize interprets the input text as two pieces, some client-based info, such as client-ip or other, and a possible token to check, for example

192.168.0.1TOKENDELIMITERRMoa43/zBdWp+E474FkoOkgJ2ZKNds6N

Tokenize will generate a token using all of the text before "TOKENDELIMITER" + any extra info such as current time (maybe taking out minutes). If the token generated matches the stuff after "TOKENDELIMITER" it will write a blank line on stdout, otherwise it will write out the new token on stdout, e.g.

TOKENDELIMITERRMoa43/zBdWp+E474FkoOkgJ2ZKNds6N

"C" source code

This code has been only minimally tested. Please help verify the approach and the implementation used here.

Note: In order to use, you must fill in key and initial value (key & iv), and of course these should be kept secret.
Also you may want to modify how time/date are used as well as any other system variables you might want
to add in.