If the transfer rates are relatively small you could make your product completely passive as in don't allow anything to connect to device, let the device send data to a web server and request incoming data from same web server periodically.
Give each adapter a unique Id ( which can me stored in the microcontroller's eeprom memory or something like that) and the micro connects to the website and does a request that looks something like this GET /receive?uid=12345&lastpacket=24354 wherethe uid is the unique id of the device and lastpacket is the unique id or time stamp of the last packet of data the server sent to you, so that in case connection is suddenly broken , the adapter can reconnect and resume transfer of data without losing anything.
in theory the connection can be kept open up to minutes or hours, because that's how online radios typically work these days, so ISPs shouldn't interrupt you. But in the worst case that you have a bad router or switch that kills connections or they freeze after some time, the micro can close connection and create another request to the remote server using the last packet id as resume point.
As for sending data to user, this could also be done using a simple POST http request to the web server with data encoded in a variable or optionally declaring the data as a file upload of unknown/very long size and just killing the connection when you feel like stopping transferring messages. you can use even a GET request encoding the data to send in a parameter in the URL, but you'd have to be careful about length of URLs (less than about 4K would probably be safe)
On the server side, the incoming and outgoing data could be kept in RAM using a memory / disk backed database (think memcached but with no loss guarantee, keep data in ram and delete packets as soon as they're transferred and no longer needed to be stored)
The problem with this system is the added latency between device and user - you get the latency between device and server and then from server to user and matching but otherwise with html 5 and javascript these days you can make some kid of terminal fairly easily. Also, if the user turns out to have a static IP or that your application can break through his firewall and your server can connect from outside to the user's computer inside a network, it could optionally instruct your adapter to talk directly to that user's ip:port pair until disconnected, and then fall back to default device-server-user behavior.
Think o all "shoutboxes" that are on various forums which pretty much work on the same concepts.
ps and html 5 also has web sockets which makes chat back and forth very easy.
ps. my keyboard died, using a temporary shitty one with very hard to press buttons so in my posts i may miss some letters, sorry if they look bad or are hard to read