h a l f b a k e r yGetting blown into traffic is never fun.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
I have a cell phone with a voice mail service. The way the voice mail service works, is that if someone calls me, and leaves a message, my phone will tell me that someone has left a message... but I still have to make a phone call from my phone, to the voice mail service, in order to actually listen
to that message.
I propose that the voice mail service establish a data connection with the phone, and copy the voice messages over that connection onto the cell phone.
Then, whenever I want to listen to my messages, I can get them instantly, through a program on the phone, since they're already *on* the phone... no additional connection need be made.
When deleting a message from the phone, I would be given an option: delete only from the phone, delete only from the central database, or delete from both. If I delete a message from the database, or both phone and database, a (low priority) data message would be sent to the database. It wouldn't necessarily be sent right away, but eventually, when the cell tower has enough unused bandwith.
Other features: The data connection can be a "low priority" one, to conserve cell service bandwith. When listening to voicemails that your phone has downloaded, you don't need to be in range of a cell tower. I could record voice mails that I want to send, without sending them right away, and listen to how they sound before actually sending them (like composing an email).
When sending messages, the user would have the option of using a normal priority data connection (and be charged by the phone company, assuming the user doesn't have an unlimited data plan), which would send the voice mail right away, as quickly as possible, or low priority data connection (which would be free or reduced cost, even without an unlimited data plan), which would send the voice mail only when the cell tower has enough bandwidth.
Voicemail forwarding as .WAV
Voicemail_20forwarding_20as_20_2eWAV Prior art [8th of 7, Jun 29 2009]
[link]
|
|
[-] as well as meaning your phone would have to have and maintain sufficient memory for x time of messages and that you would be charged airtime for the auto-downloading of same, I don't see any advantages save that you could then listen to messages while in an 'out' area. |
|
|
As far as sending messages is concerned, I don't get it if you mean voice messages. (granted I've managed to avoid getting a cellphone, sometimes not by much). |
|
|
What I'd like (and phone-makers bend over backwards to avoid doing) is to one-button record a call or a portion(matters not to me whether there's the statutory 'beep' or not) so I don't have to grab a pen and paper to write something down. |
|
|
Cell phones nowadays have lots of memory, so that's not a problem. |
|
|
As for being charged for downloading... the way I see it is, regardless of *how* you get your messages, the cell phone company will *eventually* send them to your phone. |
|
|
It is to their advantage, if they can send them to you as low priority data, when the tower nearest you is at a time of low use, instead of waiting until you request your messages, which will probably occur some time during peak usage. |
|
|
If you really don't want entire messages being sent automatically, the system could be configured to only send you message headers, showing time/date the message was made, message length, and caller-id. |
|
|
Either way, by being able to view message headers, you can choose what order to listen to your voice mails, or even whether you want to listen to a voice mail... depending on who it's from, you might want to delete it without listening to it. |
|
|
"regardless of *how* you get your messages, the cell phone company will *eventually* send them to your phone"
Not really. When you dial in to your voicemail, the messages still aren't stored locally. |
|
|
I think this is great ... and definitely cheaper to do as a VOIP data packet than over a live GSM call (for the network, not only the customer), even without the ability to make use of demand troughs to optimise network use. |
|
|
There are lots of other things that you might want to apply the same thinking to. For instance, you should be able to get your banking (balances, last transactions etc) sent to your phone so that you don't then need to login to your bank's web/mobile site to check something ... rather have info immediately at hand. |
|
|
(Security of on-phone app would obviously be built to required level) |
|
|
Also - there are added benefits of having your own copy of voicemails (or banking transactions, or whatever) rather than relying on their stored version. |
|
|
You can store them in your own database, add fields, sort and view by different criteria, etc |
|
|
So - I think this idea has much more merit than it first appears! Definite iced bun from me! |
|
| |