Greg,
The AM server and the Token Application (SmartPhone or PC for SoftToken, FOB for Hardware Token) both calculate TokenCodes based on the time, with the AM server presumed to have the correct time.
SecurID is designed to learn about time drift, which is the difference in time on the token relative to the presumed correct time on the AM server.
By waiting about 2 minutes to press enter for a logon with your token, you are telling the AM server that your token's clock is 2 minutes slower than the server's clock. The AM server will note this time difference or time offset of minus 2 minutes, and expect the same slowness on future logons.
You cannot reuse any tokencode, and as soon as you successfully authenticate with any tokencode, all previous tokencodes become invalid. What you are seeing is functions as designed, a way to handle imperfect time in an imperfect world. But by doing what you did, you have handicapped the token, so that if you logon again next time with the correct token, the AM server will think your token is now two minutes fast (compared to what it was), and may prompt for a Next TokenCode. The AM server will adjust your token time offset back assuming you do this. You can read more about this in various KB articles on Token and time offset, as well as the rsautil synctokens command at the linux prompt
