I'd simply drop the idea of imposter lockout. It's first of all very fragile since it only kicks in if he and the valid user use the program at the same time (not that likely), and if they do, you have absolutely no idea which of the two sessions is the "real" one. So whomever you kick out, half of the time you're wrong and actually helping the "imposter".

Also, being connected is a red herring. First of all HTTP is stateless, so there is no such thing. And even if there was a real connection, it wouldn;'t mean much, since the user could just have kept the old browser connected even if he's not behind the computer.

So I'd simply assume that a new session means the user moved, and just invalidate the old session. If imposter avoidance is impotant, give the user a message that you did so, so that the user (who supposedly knows he used the program recently somewhere else or not) gets a chance to decide if there is an imposter or not. In the scenario you started with where the imposter is working at the same time, the session will probably move between the two parties several times, and each will be aware of the existance of the other.