Where Are They Now

It is well known fact that the question "where are you" is one of the most often asked in the world of mobile communications. 600 billion text messages per year in the US ask "where are you?" – as per Location Business Summit 2010 data. No doubt, it is the most popular question in mobile networks. But location sharing over mobile phones still faces challenges. And privacy here is probably the biggest concern.

Actually our Geo Messages project solves problems with privacy. With Geo Messages users can share location info peer to peer as signatures for messages. But it is pure one-to-one relation. What if we need to monitor several people? Here is our new service WATN. It lets you monitor locations for several people, as well as share your own location to some group of people. Obviously, in this case we need some third party server that saves our social graph (who is sharing data to whom). But we can offer the safe solution that does not hurt your privacy.

WATN requires no sign-up. It combines anonymous server-side data with local personalized records.

What if we separate location info and identity data? Just three steps:

a) assign to any participant some unique ID (just an ID, without any links to the personality)
b) save location data on the server with links to the above-mentioned IDs
c) keep the legend (descriptions for IDs, who is behind that ID) locally

In this case any participant may request location data for other participants from third party server (as per sharing rules, of course), get data with IDs and replace IDs (locally) with legend’s data. With such replacement we can show location data in the "natural" form. For example: name (nick) plus location. And in the same time the server (third party server for our users) is not aware about names.

What does it mean technically.

Server keeps location info with IDs:

(a)
ID1 -> (latitude, longitude)
ID2 -> (latitude, longitude)
ID3 -> (latitude, longitude)
Etc.

And social graph – who is sharing location to whom:

(b)
ID1-> (ID2, ID3)
ID3 -> (ID1)
Etc.

Local client keeps legend:

(c)
ID1 -> (name or nick)
ID2 -> (name or nick)
Etc.

The algorithm. Client restores own ID (or obtains a new one). After that client saves location data on the server and obtains shared location data (by the social graph). Client modifies received data and replaces IDs with known names. So, after that our client side application is ready to show location data with names instead of IDs.

Naming. Where are the above-mentioned names (nicks) for IDs come from? WATN uses peer to peer sharing. It means that any user shares own location to another person directly. There are no circles, lists etc. As soon as some user is going to show own location info to another person he simply sends notification about this to another email address (phone number in case of SMS).

Such notification contains some text with explanation "what is it" and, what is obviously should be the main part of this process, a special link to WATN. This link contains an ID for the request originating party.

As soon as this link is fired, WATN application (client) becomes aware about two IDs: own ID1 for this client (see description above) and ID2 from the "shared with you" link (originated request ID). So, if notification is accepted, we can add social graph record (on the server) like

ID2 -> ID1

(client with ID2 shares own location info with the client with ID1. Or client with ID1 identity may read location info for ID2)

But because the notification link comes from email (or SMS) the receiver is aware about the context. He knows simply email headers ('From'), phone number or name in address book SMS comes from. It means the receiver can assign some nick (name) for ID in "shared with you" link. Actually it is a part of confirmation: set some name and confirm. And that name (nick) we can save locally. So, it is like "two phase commit" in databases – save a new social graph record on the server and create a new legend locally.

It is obviously, that in this schema each client has got own legends. We can have different names for one ID (each client technically can assign own name).

Implementation. WATN is mobile web application (HTML5). So, we can use localStorage as a persistent store for legends.

Additional options. As soon as you share your location info, you can leave messages attached to your location. WATN users that can read your location data will see your messages too.

And any time you can delete ID (as well as erase all the associated data) from the system.

You can load WATN application right to your mobile browser (iPhone, Android) with the following QR-code:



Direct link is http://watn.linkstore.ru (it is a mobile URL)

P.S. there is another service with the "similar" abbreviation: Where Are You Now.

What does CEO of Twitter read

What does @ev read (from Twitter Links) - Evan Williams circle (CEO of Twitter).

What does Google read

What does @marissamayer read (from Twitter Links) - Marissa Mayer's circle.

Geo Messages project

Our Geo messages project has been updated. Lets you share location info on the peer to peer basic as a signature to the standard messages (email, SMS).

Lets us repeat here the main idea. It is obvious, that the question "where are you" is one of the most often asked during the communications. 600 billion text messages per year in the US ask "where are you?" – as per Location Business Summit 2010 data. A huge amount of mobile services is actually being built around this question so their main feature is user’s location exchange. In the most cases it is implemented as the ability for the mobile user (mobile phone owner) write down own location info in the some special place (special mobile application). But it means of course, that user must be registered in location-sharing service (e.g. download some special application). And what is even more important – everyone who needs this information must use the same service too.

Typically we have now two models for location sharing in services. At the first hand it is passive location monitoring and future access to the accumulated data trough some API. It is Google Latitude for example.
Possible problems are privacy - some third party tool is constantly monitoring my location and what is more important – saves it on the some external server as well as the shorted life time for handset’s battery.

Another popular model for location sharing are check-in procedures in the various forms. Check-in could be an active (e.g. Foursquare), when user directly sets his/her current location or passive (e.g. Twitter) when location info could be added to the current message (status). But here we can see not only privacy issue - all my friends/followers can see my location but also a noise issue – my location info could be actually interested only for the physical friends. For the majority of followers my location info (e.g. Foursquare status in Twitter time line) is just a noise.

Our idea of the signed geo messages service (geo mail, geo sms) based on the adding user’s location info to the standard messages like SMS or email. Just as a signature. So with this service for telling somebody "where I am" it would be just enough to send him/her a message. And your partner does not need to use any additional service in order to get information about your location. He/she will simply read SMS or email.

It is obviously peer to peer sharing and does not require any social network. Our location signature has got a form of the link to some mobile map with the marker at the shared location. And what is important here – the map itself has no information about the sender and recipient. That information exists only in the message itself. The map (marker) has no information about the creator for example. That is all about privacy.

There are several implementations for this approach: mobile web mashups (HTML5), mobile web widgets, Java Card applets for legacy phones, JME midlet for mobile Java phones as well as solutions for web applications.

See more details on Geo Messages page.

For example, our Geo Message application for Android has been updated too.

Geo Messages

Our Geo messages project has been updated. Lets you share location info on the peer to peer basic as a signature to the standard messages (email, SMS).

Lets us highlight again the basic moments. It is well known fact that the question "where are you" is one of the most often asked in the world of mobile communications. 600 billion text messages per year in the US ask "where are you?" – as per Location Business Summit 2010 data. A huge amount of mobile services is actually being built around this question so their main feature is user’s locations exchange. In the most cases it is implemented as the ability for the mobile user (mobile phone owner) write down own location info in the some special place (special mobile application). But it means of course, that user must be registered in location-sharing service (e.g. download some special application). And what is even more important – everyone who needs this information must use the same service too.

Typically we have now two models for location sharing in services. At the first hand it is passive location monitoring and future access to the accumulated data trough some API. It is Google Latitude for example.
Possible problems are privacy - some third party tool is constantly monitoring my location and what is more important – saves it on the some external server as well as the shorted life time for handset’s battery.

Another popular model for location sharing is check-in procedure in the various forms. Check-in could be an active (e.g. Foursquare), when user directly sets his/her current location or passive (e.g. Twitter) when location info could be added to the current message (status). But here we can see not only privacy issue - all my friends/followers can see my location but also a noise issue – my location info could be actually interested only for the physical friends. For the majority of followers my location info (e.g. Foursquare status in Twitter time line) is just a noise.

Our idea of the signed geo messages service (geo mail, geo sms) based on the adding user’s location info to the standard messages like SMS or email. Just as a signature. So with this service for telling somebody "where I am" it would be just enough to send him/her a message. And your partner does not need to use any additional service in order to get information about your location. He/she will simply read SMS or email.

It is obviously peer to peer sharing and does not require any social network. Our location signature has got a form of the link to some mobile map with the marker at the shared location. And what is important here – the map itself has no information about the sender and recipient. That information exists only in the message itself. The map (marker) has no information about the creator for example. That is all about privacy.

There are several implementations for this approach: mobile web mashups (HTML5), mobile web widgets, Java Card applets for legacy phones, JME midlet for mobile Java phones as well as solutions for web applications.

See more details on Geo Messages page.

By the way, our Geo Message application for Android has been updated too.

P.S. here is a Twitter mashups that uses Geo Messages ideas: share location info via Twitter.

Computer Science basics

Finally - what is Induction and what does it mean big-O ?

About TV communication tools

As Google explained, TV no longer commands our undivided attention, with 77% of viewers watching TV with another device in hand. In many cases people search on their devices, inspired by what they see on TV. So, TV applications are opening up a new business frontier for the mobile industry.

For example, TV related Communications tools give users a way to engage with others in social networking conversations or activities related to a program while it is airing on the TV screen, are the most common types of companion products and the easiest to implement. The device and app complement the TV but do not interact with it.

Here is a model example for TV related Communication tool: Second Screen TV. It is a mobile web application that let organize discussions about TV programs. What is inside it? Discussion here is a collection of tweets around some selected hash-tag. Everything starts with TV Guide labeled with hash-tags:

As soon as some program is selected, we can see program related page:

It is a place for program related content, advertising, etc. And this page contains Discuss button. But how our potential user can remember our hash-tag? Here we can use an idea described in the model example for Twitter discussions. He does not need to remember has-tag. During the first visit to that page hash-tag could be printed right in his own timeline. Together with the explanation what is it and what this tag devoted for. It is an analogue of check-in. And for the each subsequent call our application will directly move user to the twitter search for an appropriate hash-tag.

Because tag’s description was published in user’s timeline he will be able find it and return back to that discussion any time later even without visiting our TV guide again.

It is a very simple and easy reproducible way to maintain discussions about TV content, sports events etc.

You can copy sample link to your mobile with the following QR-code:

How to share location info in Facebook

How to share your location info in Facebook. For example, set a meeting place, show your current location to your friends etc. Step by step guide via Mobile map mashup

1. Go from your mobile (iPhone, Android) browser to Mobile map



It is HTML5 web mashup. You can also scan this QR code



or type a short URL: http://bit.ly/7zu3iY

Red marker shows your current position. You can move this marker to some new place, of course. Now hit a marker:



See that fb link? Hit it and share link to this map with your Facebook social graph.

What your friends will see as soon as they open that link



The red marker is his/her own location, the blue one – is what was saved. Hit the blue marker:



You will see when it was saved as well as the links for getting routes to this location.

P.S. you can do absolutely the same from your desktop browser

P.P.S. Note again - the map itself does not keep links back to your facebook account. This map knows nothing about you. So this map actually does not hurt your privacy. Map itself just says: hey, there is a saved marker. Nothing more. And this map is again nothing more than just an ordinary link in your Facebook stream. There are no your ID's within the map.

It is actually a main idea behind Geo Messages project – how to share location without revealing your ID.

Geo Messages

Our Geo messages project has been updated. Lets you share location info on the peer to peer basic as a signature to the standard messages (email, SMS).

It is obvious, that the question "where are you" is one of the most often asked during the communications. 600 billion text messages per year in the US ask "where are you?" – as per Location Business Summit 2010 data. A huge amount of mobile services is actually being built around this question so their main feature is user’s location exchange. In the most cases it is implemented as the ability for the mobile user (mobile phone owner) write down own location info in the some special place (special mobile application). But it means of course, that user must be registered in this service (download some special application). And even more important – everyone who needs this information must use the same service too.

Typically we have now two models for location sharing in services. At the first hand is passive location monitoring and future access to the accumulated data trough some API. It is Google Latitude for example.
Possible problems are privacy - some third party tool is constantly monitoring my location and what is more important – saves it on the some external server as well as the shorted life for handset’s battery.

Another popular model for location sharing is check-in procedure in the various forms. It could be an active (e.g. Foursquare), when user directly sets his/her current location or passive (e.g. Twitter) when location info could be added to the current message (status). But here we can see not only privacy issue - all my friends/followers can see my location but also a noise issue – my location info could be actually interested only for the physical friends. For the majority of followers my location info (e.g. Foursquare status in Twitter time line) is just a noise.

Our idea of the signed geo messages service (geo mail, geo sms) based on the adding user’s location info to the standard messages like SMS or email. Just as a signature. So with this service for telling somebody "where I am" it would be just enough to send him/her a message. And your partner does not need to use any additional service in order to get information about your location. He/she will simply read SMS or email.

It is obviously peer to peer sharing and does not require any social network. Our location signature has got a form of the link to some mobile map with the marker at the shared location. And what is important here – the map itself has no information about the sender and recipient. That information exists only in the message itself. The map (marker) has no information about the creator for example. That is all about privacy.

There are several implementations for this approach: mobile web mashups (HTML5), mobile web widgets, Java Card applets for legacy phones, JME midlet for mobile Java phones as well as solutions for web applications.

And this update introduces Android application: Geo SMS. See more details on Geo Messages page.

Links from Twitter

Our mashup Links from Twitter has been updated. Lets you pickup links published within any given Twitter circle. Just provide a name for user in Twitter and see links, published by his/her friends.

You can also create a direct link for that mashup. E.g. what does CEO of Twitter @ev read - Evan Williams circle

Data science

"Tim O'Reilly said that "data is the next Intel Inside." But what does that statement mean? Why do we suddenly care about statistics and about data?" - a great read about the modern Data science

Something to read from Twitter

What does Twitter founder Jack Dorsey read: http://linkstore.ru/tlink/?u=jack

Weather info via Twitter

We wrote already about our Twitter mashup – Twitter 411 service. It is a web application lets you easily create your own Twitter bots. Bot here is an application that receives some requests via Twitter and responds with your own data. You define a form for the request as well as the content for the response. Here is an example for such a bot (stock market).

As a response for the bot within t411 service you can provide any CGI script (e.g. jsp, java servlet, php etc.) on your own site. See again here a complete example (JSP) for stock market bot.

And now let us see a yet another example. Now it is a weather bot.
How does it work? The source data provided by the site yr.no This site contains weather forecast around the world. And what is important, you can pickup weather data in XML or RSS format. So it is a quick deal to build some automation processing. We create a new bot for t411 service – code for the request is w

As a reaction for this bot we've set a JSP file that obtains RSS data from yr.no, presents them in mobile ready form and responds back with a link to the requested forecast. Here is a part of that file:

<div class="content">

<%@ taglib uri="/WEB-INF/taglib374.tld" prefix="w" %>

<w:setLocation url="http://www.yr.no/place/United_Kingdom/England/London/" ttl="36000" id="A"/>

<w:forEachDay feedId="A">

<strong><%=itemTitle%></strong><br/>
<img src="<%=itemImage%>" style="border:0;float:left;padding-right:5px" alt=''/>
<%=itemDescription%><br/><br/>
</w:forEachDay>

<br/>&copy; <w:getChannelCopyright feedId="A"/>
<w:getChannelLink feedId="A" id="url"/>
<br/><a href="<%=url%>">Original data</a><br/>

</div>

code uses the Weather taglib from Coldtags suite. Tag setLocation requests rss feed (and caches it for 10 hours. Tag forEachDay outputs data. And finally we prints a copyright information as well as the back link (as it is required by yr.no)

The rest of the deal is standard. Send to user @t411 a reply or direct message for the weather forecast you are interested in.

Here are examples (what the bot recognizes and what you have to send as reply or direct message to @t411):

w london  get forecast for London
w paris   get forecast for Paris
w msk     get forecast for Moscow
w spb     get forecast for Sankt-Petersburg

And the result (you will get a reply or direct message back) is a link to the mobile site with the forecast. Because it is a mobile site you will be able to open it right from your mobile phone.

The direct messages from Twitter could be delivered by SMS to user's mobile. And so – the mobile link will be delivered too. That was the original idea for t411 service – Twitter could be used as an alternative model for programming SMS services. Twitter is a new transport layer here.

Right from Google

What does Google CEO read on Twitter: http://tlink.linkstore.ru?u=ericschmidt
(via Twitter links)

Twitter bots

We wrote already about our Twitter mashup – Twitter 411 service. It is a web application lets you easily create your own Twitter bots. Bot here is an application that receives some requests via Twitter and responds with your own data. You define a form for the request as well as the content for the response. Here is an example for such a bot (stock market).

As a response for the bot within t411 service you can provide any CGI script (e.g. jsp, java servlet, php etc.) on your own site. See again here a complete example (JSP) for stock market bot.

And now let us see a yet another example. Now it is a weather bot.
How does it work? The source data provided by the site yr.no This site contains weather forecast around the world. And what is important, you can pickup weather data in XML or RSS format. So it is a quick deal to build some automation processing. We create a new bot for t411 service – code for the request is w

As a reaction for this bot we've set a JSP file that obtains RSS data from yr.no, presents them in mobile ready form and responds back with a link to the requested forecast. Here is a part of that file:

<div class="content">

<%@ taglib uri="/WEB-INF/taglib374.tld" prefix="w" %>

<w:setLocation url="http://www.yr.no/place/United_Kingdom/England/London/" ttl="36000" id="A"/>

<w:forEachDay feedId="A">

<strong><%=itemTitle%></strong><br/>
<img src="<%=itemImage%>" style="border:0;float:left;padding-right:5px" alt=''/>
<%=itemDescription%><br/><br/>
</w:forEachDay>

<br/>&copy; <w:getChannelCopyright feedId="A"/>
<w:getChannelLink feedId="A" id="url"/>
<br/><a href="<%=url%>">Original data</a><br/>

</div>

code uses the Weather taglib from Coldtags suite. Tag setLocation requests rss feed (and caches it for 10 hours. Tag forEachDay outputs data. And finally we prints a copyright information as well as the back link (as it is required by yr.no)

The rest of the deal is standard. Follow to user @t411 and send him a direct message for the weather forecast you are interested in.

Here are examples (what the bot recognizes and what you have to send as direct message to @t411):

w london  get forecast for London
w paris   get forecast for Paris
w msk     get forecast for Moscow
w spb     get forecast for Sankt-Petersburg

And the result (you will get a direct message back) is a link to the mobile site with the forecast. Because it is a mobile site you will be able to open it right from your mobile phone.

The direct messages from Twitter could be delivered by SMS to user's mobile. And so – the mobile link will be delivered too. That was the original idea for t411 service – Twitter could be used as an alternative model for SMS services programming. Twitter is a transport here.

Smart Card web server programming

This post summarizes a presentation of Web Gate project (Dmitry Namiot, Simagine 2009 Innovation Award).

Web gate for SCWS

Introduction

Web gate project presents a bridge for the mobile Internet and Smart Cards Web Server (SCWS). This bridge provides a "standard" (practically defined and implemented) way for the mobile internet developers (web developers) to deploy smart cards based features in the own projects. All in all, Web gate is a development tool targets web developers and provides for them a smooth access to smart cards features.

Project description

The main idea behind this project is how to mix SCWS and mobile Internet. No doubt, that the mobile internet word is much bigger, than the potential SCWS-alone based projects. So the aim of this project is to bring SCWS-based capabilities to the mobile internet developers. Let them deploy smart cards based projects via the familiar (well known) for them web tools.

As per above-declared goals we have to implement at least the following things:

- propose a set of the components (widgets), provided access to the smart cards features
- propose a smooth integration for the selected components into modern web development tools

As a result web developers will get a tool (it is a key point – we are providing project for SCWS, but our target is actually web development crowd), let them access to smart cards features without knowing any technical details about smart card programming. And even more – this access will be tied to the web development exclusively, so there is no need in the new development skills for the web developers at all.

From our understanding the ability to win developers is a key issue for any new computer platform, including smart cards. Such a win can provide a stream of the new applications from the development community and so make the platform successful. And on this way the web development is becoming the mainstream. At the first hand it is so due to its simplicity and the huge army of the developers. So we are expecting here, that adding for web developers some forms of the convenient access to the smart cards data will be more than simply requested feature. This feature will smoothly enhance the existing development tools without adding a new complexity for the developers. It is the main idea behind our Web gate project.

Main features

Web gate offers a set of web controls (widgets) for the mobile web pages. We’ve decided to provide these controls in the form of custom tag. It is a standard approach for the extending markup languages (e.g. HTML), supported nowadays in all the development frameworks (e.g. JSP, ASP, ASP.NET etc.) These tags, being rendered by the application server (servlets container like Tomcat) provides at the end some piece of HTML code. So the initial page could be loaded as usually into browser on the mobile phone.

HTML code, generated by the components contains links to the SCWS. So the user could activate these links and get access to the appropriate servlets on SCWS. And these servlets (also part of Web gate package) provide access to the smart card features (to the features available via smart cards). So for the user this smart card access is just a click away from the original (loaded) page.

There are two types of code chunks created by the Web gate components. The first type is just a "direct" access to card’s features. For example: make a call, send SMS etc. HTML code chunk created by the component is just a "normal" hyperlink pointing to some SCWS servlet, where the relevant attributes (e.g. phone number to call) could be provided as servlet’s parameters

The second type of the components lets developers personalize forms with the data stored on (provided by) the smart card. It is HTML form that should be submitted to some CGI server (as per mobile web page business processes) where some fields could be filled by the data from the smart card. E.g. read some data file from the smart card and use its data within the form or request a cell id and use it as a value for some hidden form’s field etc. So this chunk of HTML code is a form again but instead of the real CGI it could be passed to the SCWS servlet. This servlet will request data from the smart card and return back the initialized form pointed to the real CGI script again. The drawback here is an extra click (submit the form to the localhost). But the positive elements are prevailing in our opinion: high level of customization (substitute data from the smart card), improved usability (no manual typing), safety (do not memorize keys and id’s – they will be extracted from the smart card), high level of the personalization (telecom operators will be able to provide cards with own data for use them in mobile web). And all of this just for the price of one extra click.

High level architecture

Here is what we did (proposed) from the practical point of view. As per life cycle of the typical web application:

1. Web developers prepare a mobile site (page)
2. Web page may include components (controls) pointed to the smart cards. The word "pointed" here describes either the ability request some functionality from the card (via the card) or the ability to get some data, saved on the card and reuse them (data) across the page (within the web application)

3. Page is requested by the web-browser (as usually) from the mobile terminal. As it is stated above the loaded page may include SCWS related stuff. Due to nature of HTML we have the well defined abilities to present the potential actions. It either a hyperlink or a form. So in our case we could present either some hyperlink, pointed to SCWS resource or some form, where the action attribute pointed to SCWS resource (servlet).

4. User may activate SCWS related things (controls) right from the browser. As per the above-mentioned nature of the components it either simply click on the hyperlink or submitting the form.

5. The hyperlinks will be used for the direct actions: place a new call, send a new SMS.

6. The forms will be used for the access to the data, saved on the smart cards. The typical use case is the following. The original mobile web page contains HTML form, where some of the fields should be filled by the data saved on the smart card.

Smart card is a trusted source. So the operator raised the card could save, for example, some own data on the card. It could be for example client’s id (ids), some preferences, marketing related data (sex, age group etc.) And later, when the card owner surfs the Net with the own mobile, the above-mentioned data could be used within the web applications.

What does it mean "used" here? All the existing web applications at the end of the day do absolutely the same things regardless of their business area – perform HTTP requests. E.g. customer fills out some form and submits it to the server. And here the smart cards data goes to the scene. We can add the data from the card to the form. So, technically the target web application will get via HTTP request some parameters, filled (initialized) from the smart card.
How can we do that? We can do it through the followings steps:

- replace action attribute of the original form with our SCWS servlet
- submit the original form to our SWSC application first
- fill the parameters and return back a new page (with the original form again!) where action attribute will be pointed to the its original destination. And some the fields within the returned form could be filled (initialized) by card’s data

So it is an extra click from the user’s point of view (submit form to SCWS servlet first), but for such minimal usability discrimination we can get a huge advantages. This process let us automatically pickup within our form any data right from the smart card. You can see this process as an analogue of form auto-filling, where data comes right from smart card. So it is a practical way for the personalization in the mobile internet.

And by the way, by the same principles we can save some data right on the card for the future usage.

Also we can mark here, that the described approach is similar by the some manner to the well known approach in the web development called ‘url rewriting’. As you can see above, we also "rewrite urls", but do actually a much more than simply session id adding.

Usage scenario

Now let us see how to incorporate our "smart controls" into mobile web pages. In order to make the easy transition to new components for the web developers we are providing the components as custom tags. Tags are familiar for the web development crowd. And all the modern IDE support custom tags.

So in this project we propose components as custom JSP taglibs. They will work "as is" in JSP and/or Coldfusion projects. The similar approach could be moved practically "as is" to ASP.NET world for example.

As we stated above there are two types of components (controls) pointed (referred) to the SCWS:

1. Hyperlinks, actually requested some actions from Smart Cards. The typical use cases are: place a call, send a new SMS.
2. Forms. Actually will be used for the requesting the stored data right from the cards.

For the actions the JSP inclusion looks so (sc here is a prefix, assigned for the taglib):

<!-- make a call -->
<sc:MakeCall phone="1800976"/>

<!-- send a SMS -->

<sc:SendSMS phone="1800976">how are you</sc:SendSMS>

web developers places a links (of course, the attributes could be generated dynamically) and the actual action (place a call, send a SMS) is just an ordinary link activation.

Let us see how the new (smart) forms looks like.

the original form on the web page looks so:

<form action="your_real_action" method="post">
  <input type="hidden" name="id"/>
  Name: <input type="text">
  <input type="submit" value="Submit" />
</form>

our goal is to obtain a value for ID field (hidden field in the form) from user’s smart card. So we offer to the user submit the form to SCWS, our servlet will calculate ID (e.g. read its value from some file, preloaded by the telecom operator) and returns back the same form with the initialized fields. This “smart” form could be presented so:

<!-- submit form to SCWS servlet at the first hand -->

<sc:Form scws="your_scws_servlet" action="your_real_action" method="post">
  <input type="hidden" name="id"/>
  Name: <input type="text">
  <input type="submit" value="Submit"/>
</sc:Form>

this example illustrates the idea with the forms (see above about the components). Code generated by this tag is just a form too, but its action will be described by the attribute scws. So the form could be submitted to our servlet. Servlet will calculate "smart" data and return back the original (here is the trick!) form with the pre-filled data:

<form action="your_real_action" method="post">
  <input type="hidden" name="value_from_smart_card"/>
  Name: <input type="text">
  <input type="submit" value="Submit"/>
</form>

The technical implementation

For the actions (MakeCall, SendSMS) taglib simply generates a link to the appropriate SCWS servlet (the real link to http://127.0.0.1:3516/...)

For the forms taglib creates a form again, changes the action attribute (now it must be our SCWS servlet) and passes the whole original form (tag’s body) as a parameter. Servlet can read this parameter (the original form), replace (substitute) some data within it and return it back.

Conclusion

No doubt, that mobile web area is huge. Smart Card Web Server as per spec is somewhat isolated from the web. The proposed tools fill the gap, combining the best things from the both words: wide adoption of mobile web will meet the high level of personalization. And two tings are especially important here: the personalization comes from the trusted source (smart card) and uses the instruments the web developers are familiar with already.
And what is especially important, that the proposed add-on follows actually to the development model web programmers are already familiar with.

Web gate project suggests the practical approach for the mobile web developers – how to incorporate smart cards features into web projects. The biggest advantage of the suggested method is its smooth (natural) incorporation into the current web development practice. The gate does not introduce a new paradigm for the web developers and leverages their existing skills.
Another big advantage is the openness of the project (the ability to extend it). It is very easy to suggest (add) new components, where new stuff could be added any time without changing the already implemented things.

Signed geo messages

Introduction

It is obvious, that the question "where are you" is one of the most often asked during the communications. A huge amount of mobile services is actually being built around this question so their main feature is user’s location exchange. In the most cases it is implemented as the ability for the mobile user (mobile phone owner) write down own location info in the some special place (special mobile application). But it means of course, that user must be registered in this service (download some special application). And even more important – everyone who needs this information must use the same service too.

Our idea of the signed geo messages service (geo mail, geo sms) based on the adding user’s location info to the standard messages like SMS or email. Just as a signature. So with this service for telling somebody 'where I am' it would be just enough to send him/her a message. And your partner does not need to use any additional service in order to get information about your location. He/she will simply read SMS or email

Signed geo messages project presents a service for the mobile Internet and Smart Cards Web Server (SCWS). This service lets mobile users automatically add a special signature to the outgoing messages (email, SMS). And that special signature presents geo information for the current position of mobile terminal. So this service is probably the easiest way for sharing location information. It does not require any downloading or registration from the potential users and provides a smooth extension for the existing communication services.

Project description

The main idea behind this project is how to deliver location info via the standard messaging (SMS and Email). We are using the same approach all SMS delivery services are in. Typically, when the mobile users get some service via SMS it means he/she is getting actually some link within the text message. This link leads to the downloading service for pictures, ringtones etc. And this approach uses the simple fact that all native SMS clients nowadays are smart enough to discover links (just http://something_is_here text chunks) within the text and allow one click internet access (opening that link). So for our location related stuff we are using the same approach.
The location info will be presented as a link, leads to the appropriate map. So if the sender will be able to automatically add such a link to the message, the receiver will be able with one click open the map showing sender’s location (or open some mobile web page with the map – see below about the landing page).

Now we are ready to describe all the steps in our project.

1. The location info could be requested right from the sim-card (smart card) as Cell ID info. This information exists always and Java-card applet can read it (local info).

2. Cell ID information could be translated into "human"-readable form of (latitude, longitude) pair. There are several public services over the Net that let us do that. In our project we will use http://opencellid.org service. This service is free and provides a public HTTP based API.

3. Google static map. The Google Static Maps API lets you embed a Google Maps image on your webpage without requiring JavaScript or any dynamic page loading. The Google Static Map service creates your map based on URL parameters sent through a standard HTTP request and returns the map as an image you can display on your web page. In our case Google Static Maps API let us build a map (actually – an image for map) based on the latitude – longitude pair obtained through the step 2.

4. URL shortening service. In order to make sure our geo-related URL’s comply with SMS restrictions (simply – they are no more than 140 symbols) we can deploy URL shortening service and make our signature smaller. In our application we will use bit.ly shortening service. This service is also free and provides a public API.

5. In order to add our location aware URL to the message (to SMS or to email) we will deploy URI Scheme for GSM Short Message Service and The mailto URL scheme. So our final step included dynamical generation of the mobile web page with links for messaging:

sms:?body=our_geo_aware_URL

and

mailto:?body=our_geo_aware_URL

So as soon as the mobile user will hit one of the link the native (it is very important!) messaging client (e.g. the native SMS client) will be launched with the text (body) field pre-populated with the given URL. So it is enough just to select the target phone (address) from the address book, add some text (optionally, of course) and send the message.

So all in all this service presents a mobile mashup (mobile web mashup) that passes user through the series of screens where the last one offers for the user customized messages sending links (or one link if we keep SMS sending only for example). And all the process is
a) completely automated
b) does not require any authorization in external services
c) very portable and will work on any mobile phone


Main features

Signed geo message service offers a mobile web mashup lets users add a link with geo information to messages (SMS, email). So our signature is a text. And this text simply contains a dynamically generated link that leads either directly to the mobile map or to some landing page where mobile map is a part of it. And that mobile map (visible area) shows the current position of the sender. It is where the name of service is coming from – signed geo messages or geo signatures.

This service is actually a web application from the start to end. Service starts from SCWS code that requests local info from SIM card and ends with dynamically generated web page for sending messages.

Service converts Cell ID info obtained from the smart card to geo coordinates via the public service. Actually there is more than one public alternative for doing this job.

Upon getting the coordinates (latitude, longitude) for user’s location service creates a map as a visual form for the location info. For map generation service uses a public API from Google. It is important that service actually uses Google Static Map, where the map is actually presented as an image. So this map could be visible on any mobile phone (mobile browser), there are no JavaScript requirements etc.

For sending messages service deploys native clients from the mobile platform. It is actually a big plus because there is no need for users to study new application and all the existing address books will be available.

Usage scenario

Now let us see how our "geo signature" looks like.

1. Mobile user fires the browser and runs (opens) application web page. Web application for geo signature will be located on the SCWS, so it means just open some URL from http://localhost. As any URL it could be bookmarked in the mobile browser, so it is no more than just select some bookmark from the list

2. Opened web application requests smart card applet and gets local info (cell id at the first hand). Web application returns to the user a screen with information about the sharing locations (confirmation screen). This screen also contains a hyperlink points to the external web service. If user agreed to share contacts he/she hits the hyperlink and goes to the external mobile web site

3. Hyperlink contains an URL with parameters provided by the local info applet. So external web service gets a request with location parameters (cell is, mcc etc.)

4. Upon receiving the request external service creates own URL to the landing page, shortens this URL via public URL shortening service (e.g. http://bit.ly with public API) and responds with the "messaging" screen. This messaging screen contains in the general case just two links: for sending email and for sending SMS. Each link actually contains an appropriate URI scheme: mailto for email, and sms for SMS. In the both cases shortened URL is a parameter.

5. As soon as our user hits one of the messaging links the native client (for SMS or email) will be opened. And the body field will be pre-populated (pre-filled) with our short URL.

6. Now mobile user selects target address (phone) from the address book, probably adds more text and sends the message – everything is done in the native SMS client for example.

7. As soon as a message is received at the target party, the short URL in the text could be opened and our landing page (on the external service) gets a request. Landing service parses the parameters, request the OpenCellID service and gets the (latitude, longitude) pair. Service requests a map via static Google Map API (it is actually just an image) and dynamically composes the response. This response contains a map (just an image from the technical point of view) and (probably, optionally) an additional info. This additional info could be a geo-targeted advertising for example.
Such a response is actually a response the target party will get back after opening the "signature".

Here are some illustrations (step by step – from start to end):








What kind of variations could be implemented (proposed):

1. We can avoid the requests to the external service on the step 3. And immediately return (right from SCWS Servlet) the “messaging” screen with the landing page in the URI’s parameters. In this case URL shortening step will be skipped and our signature will have a true (long) link right to the landing page. But as a plus we will be able to serve signatures when the connection to the Internet is not available. The sender does not need the connection to the external web service. Only target party needs the connection for opening landing page
2. As an extension the previous option some kind of the emergency service could be created. We can send local info (cellID, mcc etc.) as a text (as is), leaving the interpretation of this info to the target party. If our target party is some application (application that will accept/proceed incoming SMS for example) the data could be easily extracted from the text and converted to the geo-friendly form. There is no landing page at all.
3. As an another extension to the “no Internet case” we can try to implement some kind of pseudo-shortening service right in SWCS Servlet (e.g. base 36 encoding) and shorten the URL to the landing page right on the mobile. So the landing page will be used in the short form.
4. If the browser on the phone supports Javascript we can skip the confirmation screen. SCWS Servlet will return Javascript code that redirects user directly to the "messaging" screen on the external server.
5. The messaging screen may have just one link (for SMS or email communications). E.g. in Russia the mobile email is not popular actually, so the SMS option is quite enough.
6. Many blog platforms (e.g. Posterous, Blogger, Friendfeed, Wordpress etc.) could be actually updated right from email – you have just to send email to some service address for posting new data. So this service could be pre-configured for posting data to some blogging platforms.

The technical implementation

The first step in the above described chain is SCWS Servlet that requests local info. We mean here proactive command Provide Local Information, with Command qualifier '00' (as per GSM 11.14 standard). This command lets us obtain Location Information (MCC, MNC, LAC and Cell Identity). So it is up to our servlet requests this info and use its data for the output.

The next step: SCWS Servlet returns an information screen:

You are about to share your location
Click here

in HTML it is some like that:

<p>You are about to share your location.
<a href="http://geosign.linkstore.ru?cellid=...&mcc&...">Click here</a>


Link here points to the external service passing Cell ID as parameters:

http://geosign.linkstore.ru?cellid=...&mcc&...

In other words this link lets us pass the data obtained from proactive command Provide Local Information to the external site.

JSP page on http://geosign.linkstore.ru requests parameters from the query string and obtains latitude and longitude for them via OpenCellID.org API: http://opencellid.org/api

Actually JSP uses the following custom JSP tags from Coldtags suite (it just simplify the process): http://www.servletsuite.com/servlets/cellidtag.htm
Taglib performs the request to Open CellID API and parses the response. Technically it is a synchronous HTTP request from JSP code

Now, as soon as we get latitude and longitude we can compose the link to the map using Google Static Maps API. It is some like that:

http://maps.google.com/staticmap?center=lat,lng&size=300x300&maptype=satellite&zoom=16&key=DEVELOPER_KEY


where lat is our latitude, lng is longitude, DEVELOPER_KEY is a free key (ID) provided by Google and other parameters describe map’s type (here we are using satellite image to simulate bird’s eye view)

As soon as our URL is composed we can shorten it via http://bit.ly service. This service also provides a public HTTP based API. It is again just a synchronous HTTP request so we are performing it in the same cycle. This API is described here: http://code.google.com/p/bitly-api/wiki/ApiDocumentation

So our long Google Static Map URL will be converted into some like this (just an example of the short URL):

http://bit.ly/11ba14

And now our JSP code is ready to respond with the messaging screen. JSP file simply composes some like this HTML (we do not publish here headers for the mobile web page, just a body):

<a href="mailto:?body=http://bit.ly/11ba14">Email</a> <br/>
<a href="sms:?body=http://bit.ly/11ba14">SMS</a>

So here is just two links (or one if we need SMS only for example). And each link contains an appropriate message URI with our packed map URL. As soon as some hyperlink is clicked an appropriate native client (e.g. SMS client) will be fired. And text (body) field in our message will be pre-filled with our short URL. So we can select target phone (email address) from the address book and send the message.

This schema works absolutely similar when we drop URL shortening. URI for messages will simply use the real URL.

In case of the landing page (see above) the schema includes one step more. As soon as Google Maps URL is composed our JSP page writes a personal location information page for this request. Mashup just creates an unique public accessible file on our server and URL for this file is exactly the same URL we will use in messaging. We can make that URL shorten with bit.ly service or use as is, but anyway it will be used in our messaging URI.

As per content for the landing page. Landing page is a mobile web page that contains a link to the map and (optionally) some additional info. So, skipping the headers, it is some like this:

<img src='http://maps.google.com/staticmap?center =lat,lng&size=300x300&maptype=satellite&zoom=16&key=DEVELOPER_KEY'/>

<p>
Some advertising, targeted to (lat,lng) area
</p>

Here is simply an image tag that shows the map. Center of the map corresponds to the giving location and below that we place any geo-targeted info (e.g. advertising). It is a key point – this information is geo-targeted, because we know latitude and longitude when rendering that page.

In this case our JSP mashup simply creates that page during the request. JSP file physically writes the above-mentioned content to some new file with unique name. And URL for this new file is our new geo-signature. We can shorten it or keep it as is, but anyway this URL will be passed to the messaging link instead of the direct Google Maps link.

Marketing Appeal & User Benefits

Mobile messages are probably among of the oldest and most widely used mobile services. So there are no barriers to use it. It means that adding some new features (automated adding) could be adopted without the problems. And of course new features could add a new breath to the old services. The proposed service is really cross platform. And it could be attractive for the mobile operators too due to high profitability of SMS.

Conclusion

Service proposes a new way for the location info exchange. And what is important here that service does not introduce a yet another location sharing application. Service deploys existing and very popular channels (e.g. SMS) for sharing locations. So there is no need for end users to study something new. Because the geo signature has been added automatically this service could be easily extended. For example: some application that periodically sends SMS with user’s location to some service number etc. And we think that geo messaging service could increase mobile messaging traffic in the networks.

Mobile pages

A new mobile service Mobile pages. In some aspects it is very close to our existing mobilize tool – QR code generator. This service also prepares (automatically builds) mobile web pages. And solves actually the same tasks – how to quickly and easily build useful mobile web pages. But the key difference is the target area. Mobile pages service is oriented towards more specialized tasks.

Lets us see the first task solved by this service – how to simplify adding your contact info to partner’s address book.

Suppose I need to give somebody my mobile contact. What is a typical behavior (life hack)? I can just call. As soon as my call is accepted my partner can add phone to address book. But he/she is still need to type my name. How to simplify this task?

What if a special "contact share" page will be available on my phone? It could be a mobile web page just bookmarked in my browser. This page will have my name + phone on it and (that is the first key point) – a hyperlink for adding my data to address book. Just one click adding – after the confirmation of course.

For sharing contact I can open that "contact page" from bookmarks and send it to my partner by SMS. Here is the second key point – a link for page sharing over SMS will be on the page too.

So my partner will get a link to my contact page by SMS. It is just a plain old SMS with a link to web page inside. And now just one click is needed for address book updating. He/she does not need to type anything manually.

And Mobile pages service lets you prepare such a "contact page". Create it here, load to your mobile browser bookmarks (you can do that directly or via QR code) – and that is all. Now you can prevent your partners from manual typing. And by the way be also sure that your phone/name is saved correctly.

It is just a first application. In the nearest time a new set of useful mobile services will be available through Mobile pages.

In general our idea is to how to let users preload own phones with self made mobile services (services build by the users themselves).

Web Pair - share data between HTML5 browsers

Our web pairing for mobile phones has been updated. This basic service lets you connect two smart phones so you will be able to transfer data from one to another. More precisely – it links two browsers. Actually, you cal link mobile to desktop, desktop to desktop, mobile to smart TV, etc. The key idea is that internet connection should be enough for passing data from one browser to another (from any screen to another screen). There is no need to download applications. Everything should work in the browser.

How does it work? Point two browsers (two phones, for example) to the same URL: http://pair.linkstore.ru

You can use the following QR-code:

 

You can see the following:

There is an unique 4-digits code on the top. The picture will be the same in the second browser. Just a code should be different:

This random code will be used for pairing two devices. The schema for pairing is similar to Bluetooth pairing. On the screen (phone) that should display the data (be linked to another phone/show data in slave mode) type the code presented on the second browser. You do not need to type anything on the second (master) phone. It will recognize the connection from the slave device automatically.

As soon as you submit the code, slave screen is ready to accept data:

As soon as the code in entered, the second screen (master) will be updated automatically:

Type any text and press Push button on the master screen. You (your pal) will see data on the slave screen.

It is a basic example that transfers text data. Technically it is possible to pass any data available in the browser. What can you transfer right now:

- just type any text. All connected slaves phones will see that

- type any phone number. It will be presented as a clickable link on the slave screen (screens)

- type any URL. E.g. http://servletsuite.com Slave screen will show a clickable link

- type any email address. Slave screen will show a clickable link

- type the following command t:some_name_from_Twitter. E.g.:  t:t411. Slave screen (screens) will show the link to that account in Twitter (http://twitter.com/t411 in our example). So, your pals will be able to read your feed, follow it, etc.

- type the following command f:some_name_from_Facebook. The same as above but for Facebook. Slave screen (screens) will show the link to that profile in Facebook. So, your pals will be able to read your feed, subscribe, etc.

- type the following command v:some_name_from_Vkontakte. The same as above but for Vkontakte. Slave screen (screens) will show the link to that profile in Vkontakte. So, your pals will be able to read your feed, subscribe, etc.

In the latest version you can transfer image files (or pictures from the camera) too. E.g., get the file (camera picture) from mobile and show it on Smart TV, etc. As you can see (try to enlarge the pictures above) master screen contains a widget for images selection.

Note. File transfer is based on HTML5 File Read API. It is not 100% supported right now for mobie browsers (especially, with old operational systems). But it works fine for the desktop already. So, you can transfer images from your desktop browser (master) to mobile (slave), for example.

What are the prototypes? There are two componets in Coldtags suite. Both controls are pre-ajax and use frames but they work. They are Cobrowse and Slide.

Geo Messages - a new way for sharing location info

Coldbeans Software implements a set of mobile web mashups (HTML5 applications) that provide a new way for sharing location info sharing - Geo Messages.

Rather than let social network monitor your location (Google Latitude) or share your location info with some social circle (Foursquare check-in etc.) Geo Messages approach lets you share location data on the peer to peer basic. You can share your location info as a signature to the standard messaging (email, SMS). And what is important – shared location data (map) does not contain your identity. Your ID (name, phone) is in your email (SMS) only. The shared map does not reveal anything.

Sharing location info via the social network is not only a privacy issue. Very often it is signal vs. noise issue – most of the user’s circle in some social network is simply not interested in his/her location. And peer to peer sharing obviously solves this problem – your location data go to the interested party only.

600 billion text messages per year in the US ask "where are you?" - quote from Location Business Summit 2010. And Geo Messages offer a simple (one click) answer.

You can get mobile links right here: http://servletsuite.com/geomessage