(used to work for Nextel, know their location infrastructure well).
I suspect that the basic reason for this is that customer care doesn't have the tools to do it.
The network infrastructure is there, and the tools are there, but Sprint probably hasn't invested in giving this kind of capability to care organizations. Plus, there ARE some (minor, overblown, redherring but real) concerns there about impersonation, spoofing and such, particularly in Boost land where the amount of information known about customers is pretty minimal to begin with.

I've worked most of my career with PowerPoint types -- people who are actually creating the things because they're the MBAs presenting the concepts.

99% of them don't know how to use Powerpoint beyond dragging squares and changing colors. Styles, templates, master slides, etc are foreign concepts to them.

Often times, these are folks who got MBAs after spending years creating static HTML pages. They did it using FrontPage.

Becoming a competent HTML editor is not difficult, but it still is a skillset that not everyone has.

There are still plenty of corporate websites for even large multi bilion $$ companies that are not database driven. Sometimes, it just doesn't need a database. 400 pages clearly is too many... but I've seen sites developed with 40 static HTML pages. Maintenance is a pain, but it's more expedient to hire an HTML editor than to hire the staff to install, configure and maintain even a simple/FOSS CMS.

EOM

That is a significant point.
The architecture of the BlackBerry system requires all traffic going to a BlackBerry device from an Enterprise email server to go through RIM's NOCs -- all Americas email traffic goes go through the Canada NOC at some point, all EMEA traffic goes through their NOC in the UK. [reference]

While all the transmissions are encrypted end-to-end (to the point that the system has passed US-government security reviews for secure traffic), the transmission of a US President's data traffic through systems that are outside of US jurisdiction and government control can be tricky.

But then again, this gets eliminated if they go with any other wireless email device that does not use RIM's infrastructure; there are plenty, and they can be made to work.

n01, you're on the right track thinking about going with a publisher.

I used to run developer programs for a large US wireless carrier, and now do so for a large Latin American wireless carrier. In general, I encourage small Java ME developers not to bury themselves trying to negotiate with the carrier directly. Unless you have something extremely innovative or a brand that a mid-level product manager type in a wireless company can recognize, you're probably going to lose a lot of money, time and brain cells getting anyone who can launch your product at SprATiT-zon to respond to you. And say you DO get their attention: that's almost even worse, since coming up with some kind of content distribution agreement with a gigantic corporation will consume all your waking hours.

So start small, and grow from there depending on how your app does.

- Make sure the stuff works. You should start researching Mobile Publishers out now, but before you do, make sure your game is rock-solid on as many devices as possible.
- Work with a content porting service. There are companies that can help you make sure your game works on all these devices. One I know of that I can recommend (they used to be a development shop as well, they know the pain of the small developer) is Tira Wireless -- they have a program that can take your midlet and help you port it to the hundreds of devices you'll need to build the MIDlet for to get any traction: http://gomobile.tirawireless.com/xwiki/bin/view/Main/WebHome
- Get your MIDlet run through a generic certification program like JavaVerified. Many operators require it, it is a very good basic quality test that meets about 96% of the requirements of any operator, and at least shows that you're serious. One company I've worked with that does a good job with that is NSTL (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.nstl.com%2Fjavaverified%2Fgui%2Fhome_main.asp). The other labs that do Java Verified (RelQ, Babel, CapGemini) also have good reputations.
- Join the developer programs of operators worldwide you'd WANT to work with. It will give you a sense of whether or not they care about developers like you. Companies in English-speaking countries that I think are able/willing to work with smaller developers are AT&T, Orange, Sprint (the Nextel side), T-Mobile to a certain extent, and of course, we are (although I must say that you're probably not quite there yet to work with us, mostly due to language issues). Particularly, make sure you can that it is easy to get the data services you need for your application to work - since yours uses a data network, if it's tricky to get the service (or tricky for you as a developer to get it working) chances are you're going to be hitting a brick wall sooner rather than later. The forums on these sites will give you a good idea of where the pain points are for developers.

NOW, find a publisher.
There are a number Publishers or Aggregators that work with guys like you to get good game placement without trying to gouge you too badly. I will mention two that I have worked with and respect (and that have a good reputation), and that are of a size that would work well with what your game sounds like it does.

- Digital Chocolate - focuses on social mobile games. Good company to do business with from a carrier's perspective. http://www.digitalchocolate.com/
- Cellmania - they're an aggregator that also runs a number of storefronts for various operators worldwide. They do a good job putting apps on the long tail to see what happens with it. http://www.cellmania.com/content_providers/

IF YOU ARE SERIOUS about it, then do this. There is money to be made if your application really is good and different and sticky.
If you're not in a position or willing to spend some money on it up front, or to dedicate serious free time to it, don't try to do the cell phone thing. You're better off with other platforms:

Option A: Port it to the BlackBerry, participate in their Venture Fund, and see what happens. They're really trying to kickstart their developer community for consumer applications, and yours sounds like it could REALLY use the always-on network that the BB device can boast. Plus, the BB is all-Java on native, so you won't have to recode too much, and BlackBerry apps tend to sell for higher prices than their Java ME counterparts on sites like Handango.
Option B: Port it to the PalmOS -- you're going to live in Shareware Land on this, but you'll get your app out there, and it can support Java ME without too much of a fuss.
Option C: Port it to Android -- who knows how this is going to work. I don't think any developers or providers know yet how they're going to make money on content here, but it's getting people talking. Once the app store is up, perhaps it will be a different story.
Option C: Port it to Windows Mobile -- again, you're going to live in Shareware land on this, mostly because there aren't too many carriers who have figured out the Windows Mobile distribution channel.

Good luck.

At around the same time that sarcasm detection became a necessary skill for a good sysadmin.