I follow your idea, but what I'd imagine the biggest stumbling block to be here would be the complexity of the service. Phone service has been around for so long, everyone just sort of expects it to work like it always has.

Now, I'm not saying you can't do this idea, here's how you'd pull it off though. First, you get customers with an easy to access product with a killer feature just like PVRs did. Give them a phone with the simplest of your ideas, like the call time blocking with messages, etc. Do just one feature. Put that in a REALLY slick package (think Moto Razr) and sell it at Target/WalMart (that would be the hardest part).

Once you have a good number of product owners, release the next version. Educate your customer base all the way. Bring them up to speed. The big numbers you'd need to succeed likely won't be smart enough to use this whole product as you describe it.

I have never experienced VoIP in all my geeky years, actually. Is there a way to access or "intercept" the actual data coming into a phone from a VoIP provider? Also, not that it seems likely, but do they have any third party access or APIs developers can access?

If so, this would be a killer application. To elaborate on mccorkle's elaboration as well, we could just have the apps walk them through in the classic "wizard" sense of things. Sort of like "Step 1) Enter a number of the person you want to screen" with a big pretty page on there. Then "Step 2) What do you want to do with this person? a) send directly to voice mail? b) let ring forever c) forward to another number" etc etc.

I always liked the way the rules editor in MS Outlook walks the average user through fairly complex programming functions. They do it in the classic "if this, then do this, unless it is this" fashion which are alot like "if" statements in your average programming language. They could use some improvement, but most users in my corporate environment get them after a few mins (and some of those same people can't reseat a keyboard!)

Technically speaking the app is fairly easy to build using something like Asterisk, which is an open source voip pbx. The only real pain is bridging to the "old school" phone network, but there are companies out there like VoicePulse that provide such a service, so you can build your application in a pure voip/internet context and not really worry about direclty dealing with complicated old school phone signalling technology, since VoicePulse provides a pure internet bridge to that mess.

So my idea is to set up a server that sits in the middle of a phone call path, and does filtering based on user preferences as input via the web. In a pure voip setting it is pretty easy and cheap to do, but when you bring in the PSTN to the picture (incoming and outgoing), you start to rack up tolls which would eventually have to make their way back to the subscriber, so that is kind of a downer for this idea.

Another approach would be to handle everything on the cell phone itself, which is what I think mccorckle was suggesting, and sell people some custom software they can install on their phone that would implement those features. They could configure it on the phone itself, or maybe through a webserver as phones start getting connected to the internet. This way there are no extra tolls to worry about, no bandwidth fees, etc. Of course, this has its downsides too, because it is coupled with the phone and carries the same problems as desktop software versus a managed web application.

As branchcut said above, Asterisk (http://asterisk.org/) provides the facility to do all that you are looking for.
Perhaps a better target market would be VoIP providers?
We could develop an application, or management console for asterisk (or similar) that could allow them to easily on-sell these types of services to their clients.

..I already do most of the above with my asterisk box, and it really isn't that tough to set-up, but I am a geek.