Implementing remember me with token and series acr

I am attempting to implement a "remember me" utility using the system outlined here: Improved persistent login cookie

However there is an issue with the logic here for me and was wondering if anyone can clear this up for me.

A user is given a session ID. This a randomly generated string and is persistent over the lifetime of the user's account.
A user is given a token ID. This is a randomly generated string and is recreated every time the user successfully logs in.

Both of these values are stored as signed cookies on the user's machine and in the database.

The idea is that if someone manages to spoof the user's token and series and log-in as the user then they will generate a new token ID. The next time the legitimate user attempts to log-in then they will have a matching series but an invalid token thus notifying the system that a security breach has taken place and any necessary action can be taken (clearing the user's token).

This is great. However what happens when a user attempts to use my application from multiple devices or browsers? Say a user logs into my service with Chrome and checks remember me. Next time they log-in via Firefox and also selects remember me. A new token will have been generated so that the next time the user attempts to login with Chrome a false theft would be triggered - no?

If this is the case how can I implement this solution more reliably? I am well aware that cookie based authorisation is by it's very nature less secure and would not allow a cookie authorised user to perform any damaging actions such as purchases.

The original post that the "Improved persistent login cookie" refers, (found here: http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/) states:

The cookie should consist of the user's username, followed by a separator character, followed by some large random number (128 bits seems mind-bogglingly large enough to be acceptable). The server keeps a table of number->username associations, which is looked up to verify the validity of the cookie. If the cookie supplies a random number and username that are mapped to each other in the table, the login is accepted.

At any time, a username may be mapped to several such numbers

So, the user can have many persistent tokens at the same time.