Cathy,
   
  The wbtrvmemo is the new notes file system, and yes I see the same thing. I do not believe it takes up any additional seats, but if it does let me know ASAP. I think if it did I would have heard about it by now though.
 

Same here, 5 user license but something like 10 or more users showing up in the monitor. It doesn't complain.
 
My guess is that one user is counted as one instance of a program running on one machine. So two copies of EVO counts as two users but three connections from within the same Evo instance count as one.
 
On an unrelated note, it sucks that pervasive is per user licensed... How about a switch to Firebird or PostgreSQL some time in the future? <ducks>

I am seeing the same thing.  Found it when trying to find out why a user was locked out of AP.  I found that even though the user had logged completely out of EVO the pervasive monitor had 6 open connections for this user.
 
Anyone having this same issue on EVO?  I just updated from DBA to EVO and just noticed the problem.

What you see in the Pervasive Monitor is each SESSION, not each LICENSE.  A session is established by the application to talk to the database -- kind of like having its own phone line direct to the server.  The Pervasive engine tracks licenses, on the other hand, by "unique network address" accessing the engine.  Therefore, if you run a database application from 6 workstations and the server, you will use up 7 licenses.  If you do not run anything on the server itself, this will only be 6 licenses.
 
There is one caveat to this that usually messes people up:
 
If you are right near your user count limit, and a workstation gets "abnormally terminated", whereby it is unable to close the application properly, the session (and thus license) will remain open on the server.  This can prevent you from signing in from a different computer right away, but would have no impact on signing in from the SAME machine.  
 
These orphaned connections will get cleaned up in time by the TCP watchdog process, which will send an "are you alive?" watchdog packet to each workstation session when it has not received a request for the last 2 hours.  If the workstation doesn't respond, the session will be cleaned up properly.  If the session DOES respond (which can happen if you End-Task the application, but don't reboot the PC to reset the database client), then the session can stay indefinitely.  [Yet another reason why you should reboot if you ever crash your app.]
 
You can alter this time limit easily be enabling the Pervasive Auto-ReConnect (PARC) feature of the database, which will reduce the clean-up time to 3 minutes (by default).  Of course, this also decreases the watchdog timer and increases the overhead, so a busy system may see a performance penalty if you enable PARC.