In the emerging all-IP world of converged wireless networks, courtesy of IMS, it’s a cinch to add new services to the mix.

IMS allows services to be plugged in to the call pathway. In legacy networks that are circuit-switched, any processing of the audio pathway is usually a function of the switch, or some adjunct to it. This is switch-centric or switch-bound processing. For various reasons, it is not easy to add a new service to a switch. One reason might be that only the switch supplier can do it. This vendor lock-in means it will be expensive and slow to realise new services that are switch-centric. Consequently, telecoms operators are not abound with services.

IMS uses a method of call processing called SIP. It doesn’t matter if you don’t know what SIP is. What matters is that it is an open standard and it is easy to implement a piece of software that can “talk” SIP. With SIP-centric networks, there is no vendor lock-in. Potentially, anyone in a garage can develop a SIP-based service. Whether operators will allow this or not is another matter.

You can think of IMS as a router (as well as other things). If a user tries to make a call, their phone starts sending SIP signals through the IMS network. What the network can do is to say “Ah, this call is from Bob and as Bob is a subscriber to the ‘insane toad’ service, so I should route his call via the ‘insane toad’ server in case it wants to do something ‘insane’ for Bob”.

Now that you understand the essence of IMS, I can introduce the “insane toad” idea. It is relatively simple with SIP to introduce audio into the call. This is needed in any case for things like announcements, such as “please wait while we divert your call…” etc.

Think of being able to introduce our own announcements. A SIP server can be hosted on the Web and have a web (or WAP) interface. We could upload our own announcements. However, “insane toad” goes a step further…

When the IMS network detects a call is being made by an “insane toad” service subscriber (all subscription information like this is stored in a big database called an HSS), the “insane toad” server can cause a screen to pop-up on the user’s terminal.

What this screen does in this idea is to allow the user to select audio clips that they want to play during the call. If, for some unfathomable reason, they might like to hear a bizarre animated creature croaking or laughing, they could hit the “toad laugh” button and insert such a sound into the call.

Think of it as an audio version of smilie icons used in IM. In fact, this is how the service might work. The caller would select the icon for the sound and the callee would hear it and also receive the icon on the phone at the same time.

Using a Web-based front-end, users could upload their own clips, although I suspect that the operators would want control over the clips. I can’t think why!

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my “100 Mobile Product Ideas” free e-book

Earlier, I mentioned Gataga, the “social exploration” engine. Go check it out, if you haven’t already.

In the post, I suggested that the mobile interface was inefficient. Now, I could have posted my feedback to Gataga, which ordinarily I would have done, but instead I just added the tag “Gataga” to my posting and waited….

….sure enough, the “codemonkeys” at Gataga eventually picked it up in the feeds and - even better and totally cool - they went and fixed the mobile interface and then told me in a comment to the original post.

That’s customer service, that’s tagging, that’s speed, that’s cool!
Thanks Gataga.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my “100 Mobile Product Ideas” free e-book

In the world of massively complicated and expensive-to-run mobile operator networks, it is difficult to develop and deliver new services. An operator network, just like any other, is lots of computers and databases. These might be configured as switches, as text messaging centres (passing your message from your phone to another), as radio controllers, and all kinds of disparate functions. Most of these computers and databases have their own way of describing the information they contain and their own way of conveying it (i.e. protocols).

Most interesting services, such as some of the ones I have blogged about here in my 100-ideas series of postings, require a bit of this and a bit of that from the various disparate systems in the mobile network. This problem is not unique to mobile networks. Many networks in all kinds of businesses have similar problems.

Now it is inconceivable to write a software program that is going to run “across” the network on the various systems in order to achieve the service being sought, such as a push-to-taxi-air-tagging-cellular-socks service with cream on it!

However, what if we could write a “program” sitting somewhere in a network that asks all these disparate systems to do a bit of this (service A) and a bit of that (service B) and pass me back the results to co-ordinate (Orchestrate) a meaningful user service on behalf of a user. This “new” approach is called Service Orientated Architecture (SOA).

“Ah-ha!” I hear you say. “Isn’t that obvious?”…..
“Hasn’t that been done already?”…”Surely, that’s been done before!”….
“Wait a minute…isn’t that what happens already?”

The answer is……

“YES!”

However, the way it is now being done is new and there is also a very important and strategic move within the operator world to develop the “platform” bit that glues all the services (bit of this, bit of that) together. These are called Service Delivery Platforms (SDP). They are important because it means there’s potentially a single unified approach to developing and delivering new services, with greater speed and lower cost.

However, as with all these things, we have to cut through the usual barrage of buzzwords and separate out the chaff from the wheat, or the reality from the marketing hype. I found this comment on this blog about SOA very amusing…

I’ve decided that saying “Service-Oriented Architecture” is like saying “Food-Oriented Lunch” — it sure sounds good when you’re hungry, but you still have to decide how much you can afford to spend on it, which restaurant you’re going to, and what you’re going to order. And you still have to wonder whether or not you’re going to have a massive case of food-poisoning afterwards. Show me an actual menu — then I’ll tell you if I’m impressed.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my “100 Mobile Product Ideas” free e-book

Beware RIM! Despite being king of the mobile email world with Blackberry, your mobile email solution is going to be toppled soon unless you improve it.

Why?

Someone who understands email is going to come up with a better solution. RIM doesn’t understand email in the “information organisation” sense. They understand email in the transport sense, i.e. mechanisms that makes sure things are secure and makes sure things get delivered on the move. They also understand sychronisation, especially with all those “dirty” low-level Exchange protocols. Granted, they also understand device design.

But why do I think that this apparently elegant mobile email solution, well liked by a few million, is in danger of becoming out-moded?

In case you haven’t noticed, folders are out, searching is in. With the ability to search and retrieve information with powerful searching engines, the need to sort data into hierarchical folders is apparently in decline. This trend is well described by Jon Hiller.

Google are the exemplars of the search ethos and they have taken this a step further with Gmail, an online email service that does away with folders to organise email and uses labels (”tags”, “keywords”) instead.

Tagging is an important concept because it still allows user-intervention in information organisation processes, but doesn’t impose a structure. For example, I can tag an email from a client with the tag “client”, which means that it is now retrievable as a message from a “client” without the need to stuff it into a folder called “client”. If I have a powerful search engine that can quickly retrieve messages tagged with “client”, then this does away with the need for a folder called “client”. Moreover, I can tag “client” messages with other tags, like “vip”, or “chicago”, or “nanotechnology”, to indicate status, location and business activity respectively, and then search on these tags. I can use any tag I like and I don’t have to worry about having sub-folders called “Chicago” etc.

However, I can also use rules to create tags. Just as we can use the Rules Wizard in Outlook to manipulate folder storage (i.e. routing to folders), there’s no reason why we can’t use the wizard to add tags. For example, I could create a rule that for all messages from “cool_client@cool…” add the tag “cool” and “client”.

Also, we can use heuristics to generate tags automatically. For example, by looking at the percentage of emails I open from a sender and weighting this with the time interval between received (or accessed) and opened, I can automatically add tags like “vip” to the types of messages I open often and quickly, no matter the sender or the content.

Currently with my Blackberry, ALL of my email flows via the device. It is the single-user “Internet Edition”, aimed at consumers (or prosumers). If ever there was a need to deviate from the standard “inbox” metaphor used by email for donkey’s years (i.e. since the 70’s), then it’s mobile access. Innovation is required.

With tags, I could do things like open a current view on messages that are “vip”, “cool”, “project X” and “family”. Only messages with these tags would be visible and cause an alert. However, with powerful search and fast wireless connections, all my other emails are only a click away! And, with better client implementation techniques, AJAX-like and with merged Web/local-data search, email providers will be able to offer slick, fast and usable interfaces. Also at our disposal will be generic push capabilities (unlike the Blackberry proprietary solution) that can also be used with thin-client implementations.

My instincts are that the emerging trend towards tagging and search-based approaches to email will enable a new approach to mobile email. Those that understand these trends, or drive them - like Google - will be well placed to deliver us highly usable mobile email solutions, well integrated with our Web-based email services, like Gmail or Oddpost.

I haven’t gone into any implementation details, as I realised half-way through this posting that I would need a much lengthier article than my usual blog postings. Therefore, I might document these possibilities in more detail elsewhere.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my “100 Mobile Product Ideas” free e-book

Gataga is a new search engine that searches items according to their tags (keywords), such as tagged URLs (e.g. del.icio.us) and tagged photos (e.g. flickr). It also includes RSS feeds on the tag searches, so you can keep an eye on your favourite search terms without having to go back to the engine each time.

Interestingly, it has a mobile interface (XHTML), which you can view here in your regular browser. Note the apparently pointless step of asking whether you want to search photos or blogs, before giving you the text box. This seemingly small step could be a big block for mobile users who aren’t going to hang around for a new page to download each time they use the service.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my “100 Mobile Product Ideas” free e-book