2-way iSMS

The iSMS is a patented^[1] next generation interactive version of the traditional SMS text message and a trademark, which enables iSMS–powered solutions to perform interactive iSMS-dialogues between sender and receiver, for example between organizations and their customers or employees. For the customer, it’s very easy to reply to iSMS messages by selecting among predefined choices, which can be answered by using the “single button” principle.

In these iSMS powered solutions and applications the iSMS technology establishes a session with the user and manages the flow of SMS messages between the application and users so that right responses are linked to the right application even if several simultaneous sessions are established. The authentication of users is secured so customers do not need to remember user names, passwords or special authentication procedures.

The iSMS powered solutions also work on all mobile phones and all networks without installing software or configurations to the phone because the iSMS messages are delivered as standard SMS messages.

The iSMS technology has been developed and patented by a Finnish high tech company called BookIT. The iSMS has become very popular in BookIT’s home country Finland, where people are using the iSMS for different types of easy to use bookings.

For example, in 2004 Finnair was the first airline in the world to enable passengers to check-in in advance for flights with iSMS text messages. In 2008 more than half of the Finnair’s airline passengers do their check-in with iSMS. The service is very easy to use since the user automatically receives a check-in request from the iSMS service and can then do the check-in simply by one-button-reply with his/her mobile phone. The passengers are extremely satisfied since they avoid queuing and can proceed directly to the gate because the iSMS service completes the dialogue by sending an iSMS boarding pass directly to the screen of a mobile phone. This Finnair's service is called Check-in via text message -service .

iSMS Technology

The iSMS technology is based on patented BookIT DDM (Dynamic Dialogue Matrix) -method, which enhances the global standard SMS infrastructure with a unique iSMS business transaction capability. It includes session management and automatic secure authentication to enable easy-to-use and secure transactions between applications and mobile phones.

Application-to-person (A2P) dialogues and transactions and asynchronous iSMS sessions are managed by a unique and patented BookIT DDM method. The BookIT DDM technology is implemented on industry standard application server platforms and protocols for internet. This together with the open and universal SMS connectivity enables it’s rapid deployment.

Matti Makkonen and SMS

Matti Makkonen, a pioneer in the development of SMS text messaging says that iSMS is delivering his vision of mobile phone based booking transactions. Makkonen says, that this interactive version of SMS is quickly gaining popularity because it works on any mobile phone and on any mobile network without installing any software on the phone.

Mr Matti Makkonen says Bookit’s innovation is very clever because it uses the benefits of an already existing SMS standard but manages SMS transactions intelligently by adding “fingerprints” to each message. The network does not notice these secret fingerprints and as a result the iSMS service can be used by any of the existing 5 billion SMS users internationally and on any phone.

Jukka Salonen and iSMS

Jukka Salonen worked with Mr. Matti Makkonen at Telecom Finland, and after leaving Telecom Finland sought means to extend the functionality of SMS without changing the protocol which had already been widely adopted globally. Salonen's innovations are entirely separate from the network protocol stack or infrastructure and instead focus on building intelligence in the cloud that sits on-top of SMS and other messaging channels. Multi-factor authentication, anti-spoofing, and session management are key features available in iSMS, but not provided for in the GSM specifications.

The Invention

Overcoming the usability problem

While doing research on commerce over the mobile Internet while at Telecom Finland, Jukka Salonen became convinced that reproducing the “browser” experience on a mobile device was the wrong approach. Salonen noticed that the browser experience, which worked over PC, failed on mobile due to differences in the form factor (e.g. small screen size and small keyboard) as well as differences in consumer behavior when they are mobile (e.g. the need for mobile transactions to be very quick and seamless so as not to interrupt the customer’s activities, and also the need for services to be proactive). Salonen also felt that resubmitting sensitive data such as passwords and credit card information with each new session created high security risk. And most importantly, Salonen had learned from his experience at MicroWarehouse that to achieve high response rates on direct marketing, the customer had to be able to reply within 20 seconds or less, preferably with a single click.

Permanent sessions controlled by the mediator

Salonen’s turn-around idea was that instead of the user re-establishing a session each time he/she uses a service, the session could be made to last indefinitely on the mediator, even across multiple service providers (e.g. airline, taxi, credit card processor). The mediator would be able to proactively engage the consumer with the “right offer at the right time” without the consumer needing to login with a username and password. Moreover, the mediator would only need to collect personal information such as credit card information once during initial registration so that subsequent transactions over a mobile device would be entirely secure.

Data privacy and security – overcoming the risks of storing data

In Salonen’s preferred embodiment, the mediator itself would not need to store sensitive data, but rather that stored personal data would be distributed across multiple service providers, each with their own trusted relationship with the customer. Hence, no single party would have access to all the customer’s data; the credit card issuer would maintain data on past purchases (e.g. for fraud identification), the airline would maintain flight preference data, and a hotel would maintain room preference information, but no party would have access to all this information. Instead, BookIT would be able to maintain session state information and use that state information to trigger dialogues, processes, and transactions with additional service providers (e.g. when the passenger lands at his destination, he/she may receive an offer for a limo or taxi).

In this preferred embodiment, Salonen envisioned that the mediator would store certain non-sensitive data such as preferences of the user so that it could also function as an effective “broker” of offers, and only communicate very relevant messages and offers to the customer in order to maintain trust and high customer responsiveness.

The Dynamic Dialogue Matrix: session management and authentication

Salonen realized that even with creating a permanent session that he would also need to provide a means of authenticating the end user (i.e. “how does the service provider know that you are you?). He had learned from previous experiences that static identifiers could easily be stolen or faked. For example, usernames and password pairs could be guessed or phished, and the customer's mobile phone number (while serving as a unique identifier of each end user) could be easily faked using readily available internet tools.

Salonen then envisioned using a dynamically changing session identifier that would be known by the mediator. The problem he encountered many times over in devising a solution is that if you changed the protocol you created a proprietary solution that only worked if you controlled the entire service end-to-end. For example, Nokia had tried to insert a dynamic identifier in the time-stamp field, but this approach worked only over certain networks where the infrastructure could be changed because this approach wasn't consistent with the existing SMS protocol and so was not backward compatible with existing infrastructure. This type of solution is very difficult to deploy at a large scale. An alternative suggestion by others at the time was to change the SMS protocol itself, but Salonen understood it would not be possible to convince everyone to adopt a new protocol and replace existing equipment. To address this hurdle, Salonen decided that he would need to devise a solution that worked with all existing network infrastructure and terminals and with any existing protocol, including the ubiquitous SMS text messaging protocol.

Salonen’s breakthrough solution for authentication was to reverse the problem from conventional thinking. Instead of a traditional solution in which the lock was public and the key was private, he reversed the system to make the key public and the lock private (e.g. you could find a key on the streets of NYC but if you don’t know to what door it belongs it would be useless). The key could be for example, the mobile user’s telephone number (or other fixed personal identifier) but only the owner of the actual device would know which door the key belonged to (the dynamically changing reply address for example). Salonen envisioned this lock as a multi-dimensional matrix in which some axes would consist of static elements and at least one axis would consist of a dynamically changing random element. In his preferred embodiments, the dynamic element would be one of the address fields and/or reply options contained in the message body. The advantage of the matrix is that you would have a nearly infinite supply of secret session identifiers (fingerprints). For example, if you relied only on using the reply address to authenticate the user, then you would not be able to provide enough real addresses capable of receiving the customer replies. And if you used artificial addresses, you could create an infinite supply, but you would not receive back the customer responses. However, by using a combination of the user address and sender address (and optionally the reply choice) the mediator could create a nearly infinite supply of session identifiers (e.g. 20 reply addresses and 1 million customer phone numbers, could create a pool of 20 million unique session identifiers (20 million unique locks with a pool of just 20 provisioned sender numbers).

Solving the "man-in-the-middle" problem

Because Salonen’s solution does NOT rely on transmitting sensitive data back and forth between the end user and the server, there is very little security risk. A “man-in-the-middle” would only see random, single-letter replies to unknown service providers, which are meaningless to anyone other than the true mediator.

Only the mediator understands the various customer replies and to which of multiple service providers these messages pertain. There are zero security risks of transmitting single letter replies since those replies only make a reference to previously provided personal data. For example, a customer can authorize a charge to a payment card with a one-letter reply without “transmitting” their entire credit card number.

Ability to combine offers

Salonen’s mediator has a built-in syntax for 7-session stages or phases, which allows various service providers to combine offers. For example, when a passenger of an airline (first service provider) has landed at the destination, a taxi company (second service provider) is able to send an offer for a taxi from the airport to the hotel. In this scenario, the taxi service does not to know the private information such as flight information, they simply need to know from the mediator when and where to pick you up and whether or not the fare has been paid in advance.

Semantic analysis

Occasionally a mobile user will reply with a message that is out of syntax. For example, if an airline offers the customer an upgrade and asks the customer to reply with a single letter “A” to accept, and instead the customer replies “Yes, but only if my wife also gets the upgrade”, then in some implementations, the mediator may apply semantic analysis in order to interpret the meaning of the reply.

References

External links

• Bookit.net Solutions
• Bookit.net
• Finnair.com